1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
|
.\" Generated by Mmark Markdown Processer - mmark.miek.nl
.TH "COREDNS-TSIG" 7 "July 2022" "CoreDNS" "CoreDNS Plugins"
.SH "NAME"
.PP
\fItsig\fP - validate TSIG requests and sign responses.
.SH "DESCRIPTION"
.PP
With \fItsig\fP, you can define a set of TSIG secret keys for validating incoming TSIG requests and signing
responses. It can also require TSIG for certain query types, refusing requests that do not comply.
.SH "SYNTAX"
.PP
.RS
.nf
tsig [ZONE...] {
secret NAME KEY
secrets FILE
require [QTYPE...]
}
.fi
.RE
.IP \(bu 4
\fBZONE\fP - the zones \fItsig\fP will TSIG. By default, the zones from the server block are used.
.IP \(bu 4
\fB\fCsecret\fR \fBNAME\fP \fBKEY\fP - specifies a TSIG secret for \fBNAME\fP with \fBKEY\fP. Use this option more than once
to define multiple secrets. Secrets are global to the server instance, not just for the enclosing \fBZONE\fP.
.IP \(bu 4
\fB\fCsecrets\fR \fBFILE\fP - same as \fB\fCsecret\fR, but load the secrets from a file. The file may define any number
of unique keys, each in the following \fB\fCnamed.conf\fR format:
.PP
.RS
.nf
key "example." {
secret "X28hl0BOfAL5G0jsmJWSacrwn7YRm2f6U5brnzwWEus=";
};
.fi
.RE
Each key may also specify an \fB\fCalgorithm\fR e.g. \fB\fCalgorithm hmac-sha256;\fR, but this is currently ignored by the plugin.
.RS
.IP \(en 4
\fB\fCrequire\fR \fBQTYPE...\fP - the query types that must be TSIG'd. Requests of the specified types
will be \fB\fCREFUSED\fR if they are not signed.\fB\fCrequire all\fR will require requests of all types to be
signed. \fB\fCrequire none\fR will not require requests any types to be signed. Default behavior is to not require.
.RE
.SH "EXAMPLES"
.PP
Require TSIG signed transactions for transfer requests to \fB\fCexample.zone\fR.
.PP
.RS
.nf
example.zone {
tsig {
secret example.zone.key. NoTCJU+DMqFWywaPyxSijrDEA/eC3nK0xi3AMEZuPVk=
require AXFR IXFR
}
transfer {
to *
}
}
.fi
.RE
.PP
Require TSIG signed transactions for all requests to \fB\fCauth.zone\fR.
.PP
.RS
.nf
auth.zone {
tsig {
secret auth.zone.key. NoTCJU+DMqFWywaPyxSijrDEA/eC3nK0xi3AMEZuPVk=
require all
}
forward . 10.1.0.2
}
.fi
.RE
.SH "BUGS"
.SS "ZONE TRANSFER NOTIFIES"
.PP
With the transfer plugin, zone transfer notifications from CoreDNS are not TSIG signed.
.SS "SPECIAL CONSIDERATIONS FOR FORWARDING SERVERS (RFC 8945 5.5)"
.PP
https://datatracker.ietf.org/doc/html/rfc8945#section-5.5
\[la]https://datatracker.ietf.org/doc/html/rfc8945#section-5.5\[ra]
.PP
CoreDNS does not implement this section as follows ...
.IP \(bu 4
RFC requirement:
> If the name on the TSIG is not
of a secret that the server shares with the originator, the server
MUST forward the message unchanged including the TSIG.
.PP
CoreDNS behavior:
If ths zone of the request matches the \fItsig\fP plugin zones, then the TSIG record
is always stripped. But even when the \fItsig\fP plugin is not involved, the \fIforward\fP plugin
may alter the message with compression, which would cause validation failure
at the destination.
.IP \(bu 4
RFC requirement:
> If the TSIG passes all checks, the forwarding
server MUST, if possible, include a TSIG of its own to the
destination or the next forwarder.
.PP
CoreDNS behavior:
If ths zone of the request matches the \fItsig\fP plugin zones, \fIforward\fP plugin will
proxy the request upstream without TSIG.
.IP \(bu 4
RFC requirement:
> If no transaction security is
available to the destination and the message is a query, and if the
corresponding response has the AD flag (see RFC4035) set, the
forwarder MUST clear the AD flag before adding the TSIG to the
response and returning the result to the system from which it
received the query.
.PP
CoreDNS behavior:
The AD flag is not cleared.
|
