Network Working Group B. Wellington Request for Comments: 3008 Nominum Updates: 2535 November 2000 Category: Standards Track Domain Name System Security (DNSSEC) Signing Authority Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved.
AbstractThis document proposes a revised model of Domain Name System Security (DNSSEC) Signing Authority. The revised model is designed to clarify earlier documents and add additional restrictions to simplify the secure resolution process. Specifically, this affects the authorization of keys to sign sets of records. 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 RFC 2119 [RFC2119]. RFC2535], updating section 2.3.6 of that document. The most significant change is that in a secure zone, zone data is required to be signed by the zone key. Familiarity with the DNS system [RFC1034, RFC1035] and the DNS security extensions [RFC2535] is assumed.
RFC2535, RFC2931]. The following sections define requirements for all of the fields of a SIG record. These requirements MUST be met in order for a DNSSEC capable resolver to process this signature. If any of these requirements are not met, the SIG cannot be further processed. Additionally, once a KEY has been identified as having generated this SIG, there are requirements that it MUST meet. RFC2535, section 4.1.3].
RFC2535, 3.1.2]. A DNSSEC resolver MUST only trust signatures generated by keys that are permitted to authenticate data. RFC2535, 3.1.2]. This updates RFC 2535, section 2.3.6. The DNSSEC validation process performed by a resolver MUST ignore all keys that are not zone keys unless local policy dictates otherwise. The primary reason that RFC 2535 allows host and user keys to generate material DNSSEC signatures is to allow dynamic update without online zone keys; that is, avoid storing private keys in an online server. The desire to avoid online signing keys cannot be achieved, though, because they are necessary to sign NXT and SOA sets [RFC3007]. These online zone keys can sign any incoming data. Removing the goal of having no online keys removes the reason to allow host and user keys to generate material signatures. Limiting material signatures to zone keys simplifies the validation process. The length of the verification chain is bounded by the name's label depth. The authority of a key is clearly defined; a resolver does not need to make a potentially complicated decision to determine whether a key has the proper authority to sign data. Finally, there is no additional flexibility granted by allowing host/user key generated material signatures. As long as users and hosts have the ability to authenticate update requests to the primary zone server, signatures by zone keys are sufficient to protect the integrity of the data to the world at large.
A client is either explicitly executed by a user or on behalf of a host, therefore the name type of a SIG(0) generated by a client SHOULD be either user or host. A nameserver is associated with a host, and its use of SIG(0) is not associated with a particular zone, so the name type of a SIG(0) generated by a nameserver SHOULD be host.
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2136] Vixie (Ed.), P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic Updates in the Domain Name System", RFC 2136, April 1997. [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (SIG(0)s )", RFC 2931, September 2000. [RFC3007] Wellington, B., "Simple Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.