NAME

tsig - validate TSIG requests and sign responses.

DESCRIPTION

With tsig, 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.

SYNTAX

tsig [ZONE...] {


  secret NAME KEY


  secrets FILE


  require [QTYPE...]
}

ZONE - the zones tsig will TSIG. By default, the zones from the server block are used.
secret NAME KEY - specifies a TSIG secret for NAME with KEY. Use this option more than once to define multiple secrets. Secrets are global to the server instance, not just for the enclosing ZONE.
secrets FILE - same as secret, but load the secrets from a file. The file may define any number
of unique keys, each in the following named.conf format:



 key "example." {


     secret "X28hl0BOfAL5G0jsmJWSacrwn7YRm2f6U5brnzwWEus=";


 };

Each key may also specify an algorithm e.g. algorithm hmac-sha256;, but this is currently ignored by the plugin.

–: require QTYPE... - the query types that must be TSIG'd. Requests of the specified types will be REFUSED if they are not signed.require all will require requests of all types to be signed. require none will not require requests any types to be signed. Default behavior is to not require.

EXAMPLES

Require TSIG signed transactions for transfer requests to example.zone.

example.zone {


  tsig {


    secret example.zone.key. NoTCJU+DMqFWywaPyxSijrDEA/eC3nK0xi3AMEZuPVk=


    require AXFR IXFR


  }


  transfer {


    to *


  }
}

Require TSIG signed transactions for all requests to auth.zone.

auth.zone {


  tsig {


    secret auth.zone.key. NoTCJU+DMqFWywaPyxSijrDEA/eC3nK0xi3AMEZuPVk=


    require all


  }


  forward . 10.1.0.2
}

BUGS

ZONE TRANSFER NOTIFIES

With the transfer plugin, zone transfer notifications from CoreDNS are not TSIG signed.

SPECIAL CONSIDERATIONS FOR FORWARDING SERVERS (RFC 8945 5.5)

https://datatracker.ietf.org/doc/html/rfc8945#section-5.5 ⟨https://datatracker.ietf.org/doc/html/rfc8945#section-5.5⟩

CoreDNS does not implement this section as follows ...

•

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.

CoreDNS behavior: If ths zone of the request matches the tsig plugin zones, then the TSIG record is always stripped. But even when the tsig plugin is not involved, the forward plugin may alter the message with compression, which would cause validation failure at the destination.

•

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.

CoreDNS behavior: If ths zone of the request matches the tsig plugin zones, forward plugin will proxy the request upstream without TSIG.

•

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.

CoreDNS behavior: The AD flag is not cleared.