ISC BIND DNSSEC Trusted Keys Configuration

DNSSEC uses shared secret keys to validate resource record and zone information. The trusted-keys statement block is used to define trust anchors or secure entry points within DNSSEC to which DNSSEC signed resolutions can be resolved as authenticated. The trusted-keys statement may be configured within the named.conf file and within a view statement block. The format of this statement block is:

trusted-keys {
key_name flags protocol algorithm key;
[ key_name flags protocol algorithm key;]
[ . . . ]
};

where:

  • key_name is the name of the key (zone) that is the trust anchor.
  • flags is the integer encoding of the scope of the key; generally this should be 257 indicating a secure entry point (SEP) trusted key key (public SKS of trusted zone).
  • protocol is the integer encoding of the associated protocol, in this case '3', which is currently the only valid value, which corresponds to DNSSEC.
  • algorithm is the integer encoding of the key generation algorithm for the key; valid algorithm values are
    • 1 - RSA/MD5, which is not recommended according to RFC 4034, one of the DNSSEC RFCs
    • 2 - Diffie-Hellamn
    • 3 - DSA/SHA-1
    • 4 - Elliptic Curve
    • 5 - RSA/SHA-1, which is mandatory according to RFC 4034.
    • 252 - Indirect
    • 253-254 - Private
    • 0, 255 - Reserved
    • Other values - unassigned
  • key is the public key value.

Typically the key_name is the domain name which is trusted, and the corresponding parameters amount to being a copy of the corresponding zone's KSK DNSKEY record.

ISC BIND Automated DNSSEC Key Management

BIND 9.7.0 introduced automated DNSSEC key and signature management. Part of this automation deals with updating resolvers with new and/or revoked trust anchor keys per RFC 5011. Without this automation, the trusted-keys statement must be updated manually for each trusted zone rolling over a KSK.

The managed-keys statement block defines an inital key which can be trusted when configured, but is then subsequently updated in accordance with RFC 5011.

managed-keys {
key_name initial-key flags protocol algorithm key;
[ key_name initial-key flags protocol algorithm key;]
[ . . . ]
};

where:

  • key_name is the name of the key (zone) that is the trust anchor.
  • initial-key is a keyword indicating that is the current version of the key to be trusted, upon initialization of the RFC 5011 key maintenance process.
  • flags is the integer encoding of the scope of the key, typically 257 for a secure entry point key (SEP) trusted key (public KSK of the trusted zone).
  • protocol is the integer encoding of the associated protocol, in this case '3', the only valid value, which corresponds to DNSSEC.
  • algorithm is the integer encoding of the key generation algorithm for the key; valid algorithm values are
    • 1 - RSA/MD5, which is not recommended according to RFC 4034, one of the DNSSEC RFCs
    • 2 - Diffie-Hellman
    • 3 - DSA/SHA-1
    • 4 - Elliptic Curve
    • 5 - RSA/SHA-1, which is mandatory according to RFC 4034.
    • 252 - Indirect
    • 253-254 - Private
    • 0, 255 - Reserved
    • Other values - unassigned
  • key is the current value of the trusted key.

Typically the key_name is the domain name which is trusted, and the corresponding parameters amount to being a copy of the corresponding zone's KSK DNSKEY record.