Bind 9 Administrator Reference Manual

Chapter 4. Advanced Concepts
Multiple keys may be present, but only the first is used. This directive does not contain any secrets, so it
may be in a world-readable file.
If host1 sends a message that is a request to that address, the message will be signed with the specified
key. host1 will expect any responses to signed messages to be signed with the same key.
A similar statement must be present in host2’s configuration file (with host1’s address) for host2 to sign
request messages to host1.
4.4.5. TSIG Key Based Access Control
BIND allows IP addresses and ranges to be specified in ACL definitions and allow-{ query | transfer |
update } directives. This has been extended to allow TSIG keys also. The above key would be denoted
key host1-host2.
An example of an allow-update directive would be:
allow-update { key host1-host2. ;};
This allows dynamic updates to succeed only if the request was signed by a key named "host1-host2.".
You may want to read about the more powerful update-policy statement in Section 6.2.22.4.
4.4.6. Errors
The processing of TSIG signed messages can result in several errors. If a signed message is sent to a
non-TSIG aware server, a FORMERR will be returned, since the server will not understand the record.
This is a result of misconfiguration, since the server must be explicitly configured to send a TSIG signed
message to a specific server.
If a TSIG aware server receives a message signed by an unknown key, the response will be unsigned with
the TSIG extended error code set to BADKEY. If a TSIG aware server receives a message with a
signature that does not validate, the response will be unsigned with the TSIG extended error code set to
BADSIG. If a TSIG aware server receives a message with a time outside of the allowed range, the
response will be signed with the TSIG extended error code set to BADTIME, and the time values will be
adjusted so that the response can be successfully verified. In any of these cases, the message’s rcode is
set to NOTAUTH.
32