Description

With tsig, you can define CoreDNS’s TSIG secret keys. Using those keys, tsig validates incoming TSIG requests and signs responses to those requests. It does not itself sign requests outgoing from CoreDNS; it is up to the respective plugins sending those requests to sign them using the keys defined by tsig.

The tsig plugin can also require that incoming requests be signed 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

Secondary

TSIG transfers are not yet implemented for the secondary plugin. The secondary plugin will not sign its zone transfer requests.

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

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.