The RKEY DNS Resource Record

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC2119 .

The DNS protocol is defined in RFC1034 , RFC1035 and clarified in RFC2181 . The scope for using DNS KEY Resource Records was limited in RFC3445 to keys used by the Domain Name System Security Extensions (DNSSEC) which is defined in RFC4033 , RFC4034 and RFC4035 . The original KEY RR used sub-typing to store both DNSSEC keys and arbitrary application keys. Storing both DNSSEC and application keys with the same record type is a mistake so RFC3445 removed application keys from the KEY record by redefining the Protocol Octet field in the KEY RR Data. This means that any other uses of keying material in the DNS need to define a new RRtype and mnemonic. Although this document advocates the introduction of a new resource record specifically to provide this type of information for keys that encrypt NAPTR records , it can be used for more generalised encryption of DNS resource records. A scheme for encrypting NAPTR records is outlined in draft-timms-encrypt-naptr .

The RKEY RR uses an IANA-assigned type code and is used as resource record for storing keys which encrypt NAPTR records. The RDATA for an RKEY RR consists of flags, a protocol octet, the algorithm number octet, and the public key itself. The format is as follows:

RKEY RDATA format 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | flags | protocol | algorithm | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | / / public key / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ All bits of the flags field are reserved and MUST be zero. The protocol field MUST be set to 1. The algorithm and public key fields are identical to the definitions used in RFC4034 .

The format and correct usage of DNSSEC keys is not changed by this document and no new security considerations are introduced.

IANA is requested to issue a new type code and mnemonic for the proposed resource record. No other IANA services are required by this document.

The authors would like to thank Klaus Malorny, Lawrence Conroy and Roy Arends for their constructive suggestions to this document and for helping to identify potential uses for the proposed record type.