DNSSEC Working Group Brian Wellington (TISLabs) INTERNET-DRAFT November 1998 Updates: RFC 2065, RFC 2136, [TSIG] Replaces: RFC 2137, [update2] Simple Secure Domain Name System (DNS) Dynamic Update Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract This draft proposes an alternative method for performing secure Domain Name System (DNS) dynamic updates. The method described here is both simple and flexible enough to represent any policy decisions. Secure communication based on request/transaction signatures [TSIG] is used to provide authentication and authorization. Expires May 1999 [Page 1] INTERNET-DRAFT Simple Secure Dynamic Update November 1998 1 - Introduction Dynamic update operations for the Domain Name System are defined in [RFC2136], but no mechanisms for security have been defined. Request and transaction signatures are defined in [TSIG]. Familiarity with the DNS system [RFC1034, RFC1035] as well as the proposals mentioned above is assumed. Familiarity with DNS Security [RFC2065, secext2] is assumed in section (4). 1.1 - Overview of DNS Dynamic Update DNS dynamic update defines a new DNS opcode and a new interpretation of the DNS message if that opcode is used. An update can specify insertions or deletions of data, along with prerequisites necessary for the updates to occur. All tests and changes for a DNS update request are restricted to a single zone, and are performed at the primary server for the zone. The primary server for a dynamic zone must increment the zone SOA serial number when an update occurs or before the next retrieval of the SOA. 1.2 - Overview of DNS Transaction Security [TSIG] provides a means for two processes that share a secret key to authenticate DNS requests and responses sent between them. This is done by appending TSIG digital signature (keyed hash) RRs to those messages. Keyed hashes are simple to calculate and verify, and do not require caching of data. 2 - Authentication TSIG records are attached to all secure dynamic update messages. This allows the server to verifiably determine the originator of the message. It can then use this information in the decision of whether to accept the update. DNSSEC SIG records may be included in an update message, but MAY NOT be used for authentication purposes in the update protocol. Expires May 1999 [Page 2] INTERNET-DRAFT Simple Secure Dynamic Update November 1998 3 - Policy All policy is dictated by the server and is configurable by the zone administrator. The server's policy defines criteria which determine if the key used to sign the update is permitted to update the records requested. By default, a key cannot make any changes to the zone; the key's scope must be explicitly enabled. There are several reasons that this process is implemented in the server and not the protocol (as in [RFC2137, update2], where the signatory bits of KEY records define the policy). 3.1 - Flexibility Storing policy in the signatory fields of DNS keys is overly restrictive. Only a fixed number of bits are present, which means that only a fixed number of policy decisions are representable. There are many decisions that do not fit into the framework imposed by the signatory field; a zone administrator cannot effectively impose a policy not implemented in the draft defining the field. There may be any number of policies applied in the process of authorization, and there are no restrictions on the scope of these policies. Implementation of the policies is beyond the scope of this document. 3.2 - Simplicity Policy decisions in the server could be used as an adjunct to policy fields in the KEY records. This could lead to confusion if the policies are inconsistent. Furthermore, since there is no need to expose policies, a central configuration point is more logical. 3.3 - Extendibility If a policy is changed, there are no changes made to the DNS protocol or the data on the wire. This means that new policies can be defined at any point without adverse effects or interoperability concerns. Expires May 1999 [Page 3] INTERNET-DRAFT Simple Secure Dynamic Update November 1998 4 - Interaction with DNSSEC A successful update request may or may not include SIG records for each RRset. Since SIG records are not used for authentication in this protocol, they are not required. If the updated zone is signed, the server will generate SIG records for each incoming RRset with the Zone key (which MUST be online). If there are any DNSSEC SIG records present, they are dropped. If there are non-DNSSEC SIG records present, these are retained. In any case, SIG records associated with each RRset (that a resolver would use for verification) are generated by the Zone key. The server will also generate a new SOA record and possibly new NXT records, and sign these with the Zone key. 5 - Security considerations For a secure zone to support dynamic update, the Zone key MUST be online (unlike [RFC2137]). The server MUST update the SOA record and MAY generate new NXT records (the client is forbidden from updating these records); a Zone key must be available with which to sign these. No additional protection is offered by having the Zone key offline and an Update key online, since compromising any key that can sign the zone's data compromises the zone itself. 6 - References [RFC1034] P. Mockapetris, ``Domain Names - Concepts and Facilities,'' RFC 1034, ISI, November 1987. [RFC1035] P. Mockapetris, ``Domain Names - Implementation and Specification,'' RFC 1035, ISI, November 1987. [RFC2065] D. Eastlake, C. Kaufman, ``Domain Name System Security Extensions,'' RFC 2065, CyberCash & Iris, January 1997. [RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound ``Dynamic Updates in the Domain Name System,'' RFC 2136, ISC & Bellcore & Cisco & DEC, April 1997. [RFC2137] D. Eastlake ``Secure Domain Name System Dynamic Update,'' RFC 2137, CyberCash, April 1997. [secext2] D. Eastlake ``Domain Name System Security Extensions,'' draft-ietf-dnssec-secext2-05.txt, CyberCash, April 1998. [TSIG] P. Vixie (ed), O. Gudmundsson, D. Eastlake ``Secret Key Transaction Signatures for DNS (TSIG),'' draft-ietf-dnsind- tsig-06.txt, ISC & TIS & CyberCash, September 1998. Expires May 1999 [Page 4] INTERNET-DRAFT Simple Secure Dynamic Update November 1998 [update2] D. Eastlake ``Secure Domain Name System (DNS) Dynamic Update,'' draft-ietf-dnssec-update2-00.txt, Transfinite Systems Company, August 1998. 7 - Author's Address Brian Wellington TISLabs at Network Associates 3060 Washington Road, Route 97 Glenwood, MD 21738 +1 301 854 6889 Expires May 1999 [Page 5]