INTERNET-DRAFT Roy Arends July 13, 2001 Nominum Expires Januari 2002 Unsigned RRsets in Secure Zones draft-arends-dnsext-rrsets-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on Januari 12, 2002. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract In order for DNSSEC to be deployed operationally, there needs to be a mechanism that allows for unsigned RRsets in a secure zone. In the current definition of DNSSEC [RFC 2535], it is allowed to have 2 types of unsigned records, i.e. glue address RRsets and delegation point NS RRsets. There exists several reasons to allow other unsigned RRsets, all related to the scalability and maintenance of a secure zone. This document describes the reasoning as well as a method to allow unsigned RRsets within a secure zone. The method consists of extending the use of the NXT record to deal with non-secure RRsets as well as for non-existence. This is done by allocating a bit in the type-bit-map of the NXT RDATA section. Table of Contents 1. Introduction 2. Rationale 3. The NOSIG pseudo RR 4. The NXT RR with NOSIG indication in creation of responses. 5. Security Considerations. 6. IANA Considerations. 7. Acknowledgements References Author's Address Full Copyright Statement 1. Introduction The current DNSSEC standards define that a secure zone is completely signed. There are cases where there is no need for a fully signed zone. In some cases it is just not possible to have or maintain every record signed. To allow administrators to gradually adopt DNSSEC, a scheme where unsigned resource records are allowed in secure zones eases deployment of DNSSEC. Section 2 provides the reasoning why it is be useful to have unsigned data in a secured zone. Section 3 discusses the NOSIG pseudo RR and use. Section 4 discusses the implications on the Overall Security. It describes what the implications are when the NOSIG RR is used. Section 5 discusses the possible query responses when NOSIG is used. Section 6 provides the overall security considerations Section 7 notes IANA considerations for allocation of the NOSIG RR 2. Rationale Critical versus Informational RR types. The DNS contains a wide variety of resource records types. Their usage range from critical to informational. DNSSEC was developed to allow verification of these resource records. Though the verification of critical resource records (A, MX, etc. ) is desired, for information records (TXT, HINFO, etc) it may be not. The current specification of DNSSEC imposes signatures on every authoritative resource record in a zone. It does not discriminate between critical and informational records. Aggregated Signing of dynamic updated RRsets When a secure zone allows for secure dynamic update [RFC 3090], the server needs to sign every addition to the zone, update the previous NXT, and add or update the NXT for that name including signatures for the altered or add NXT record, and the added resource record or Resource Record Set. In case of deleting a resource record, the NXT for that owner name has to be updated or deleted and the previous NXT might have to be update as well including all signatures for the altered NXT records. The proposed scheme allows for addition/deletion of resource records through secure dynamic update, while the data remains (temporarily) unsigned. The signing of these records can occur later, if at all. Of course, the SOA serial needs to be increased and thus resigned immediately. A workaround for this can be to have multiple SIG(SOA) records for future purposes, to avoid online storage of the private key. An alternative for no-key KEYs. A special case are large TLDs. In general, TLD-zones consist merely of delegation points. RFC 2535 demands that for every delegation, secure or not secure, there must be a KEY RR. When DNSSEC is deployed, it is expected that the vast majority of delegations are initially unsecured. To relief the TLD of the burdon of maintaining KEY material and its overhead (sig/nxt/sig) for unsecured subzones, a TLD can use the proposed method described in this draft. Maintaining the Chain of Trust. When a domain holder wants to have some subzone secured, it currently needs to sign every single RR in its zone as well if it wants to maintain the chain of trust from the superzone, through the zone, to the subzone. In this case, only the "chain of trust" to the subzone needs to be signed, i.e. the delegation at the superzone, the apex of the zone, the delegation point to the subzone, and the subzone's apex. 3. The NOSIG pseudo RR A NOSIG RR is called a pseudo RR because it exist only in the type-bit-map of a NXT RDATA section. A NOSIG RR does not have an explicit label nor a RDATA section. It is implied by the NXT label and the NXT next-domain part in its RDATA section. Its presence indicates that there exists no signed RRsets (there may be unsigned RRsets) within a NXT name interval. Its absence indicates that there exists no RRsets within a NXT name interval, and is exactly the same as the rfc2535 semantics of the NXT RR. The NOSIG RR has type code XX. Semantics of NXT The NXT resource record is used to securely indicate that RRs with an owner name in a certain name interval do not exist in a zone and to indicate what RR types are present for an existing name. The owner name of the NXT RR is an existing name in the zone. It's RDATA is a "next" name and a type bit map. Thus the NXT RRs in a zone create a chain of all of the literal owner names in that zone, including unexpanded wildcards but omitting the owner name of glue address records unless they would otherwise be included. The presence of the NXT RR means that no name between its owner name and the name in its RDATA area exists and that no other types exist under its owner name. Semantics of NXT + NOSIG When the NOSIG RR type is present in the type bit map of a NXT RR, the semantics of the NXT RR are slightly shifted. The NXT+NOSIG indicates that RRsets with an signed owner name (instead of any owner name) in a certain name interval does not exist in a zone. The type-bit-map indicates what RRsets are signed (instead of exist) for a name. Note that in general, only names which have some RRset signed will have a NXT RR, regardless whether the NOSIG type is present in the type bit map. This clarification is _no_ update of the NXT semantics of RFC 2535. In RFC 2535 this was implicated because a zone consists purely of signed RR sets, the NXT name always had a signed RR associated with it. When NXT + NOSIG is used, delegation point NS RRset MUST NOT appear in the type bit map as they will never be signed. Also SIG MUST NOT appear in the type bit map. SIG records contain signatures for RRsets, and are never signed. [******** discussion point: because of the behaviour of NXT+NOSIG wrt SIG records, a NXT has either SIG or NOSIG but NEVER both RR type (a SIG is never signed itself). This could of course mean that instead of defining a NOSIG RR type, NOSIG is implied by the absence of SIG in a type bit map. With rfc 2535 semantics, there will ALWAYS be an indication in the type bit map that a SIG exists, so absence of a SIG could imply NOSIG (as in NO SIG implies eh, NOSIG :-) ********] Usage in general When a NXT + NOSIG is present in a zone, it indicates that there might be unsigned RRsets in its name interval and that there might be unsigned RRsets for the NXT name. The type bit map indicates which signed RRsets are present for the NXT owner name Special usage for informational or non-critical RRs. A domain holder can choose not to have its non-critical RRs signed. These RRs might be for instance HINFO or TXT records, but also A records that have is not critical for the day to day operation of the infrastructure. Examples of NOSIG usage for informational or non-critical RRs. The following RRsets gives an example of the NXT+NOSIG usage versus the rfc2535 NXT usage. without NOSIG | with NOSIG a A rdata | a A rdata a SIG (A) | a SIG (A) a TXT "Our Mailserver" | a TXT "Our Webserver" a SIG (TXT) | a HINFO rdata | a HINFO rdata a SIG (HINFO) | a NXT b A TXT SIG NXT | a NXT c A NXT NOSIG a SIG (NXT) | a SIG NXT b A rdata | b A rdata b SIG (A) | b TXT "Test Server" | b TXT "Test Server" b SIG (TXT) | b NXT A TXT SIG NXT | b SIG (NXT) | c MX 10 a | c MX 10 a c MX 20 c | c MX 20 c c SIG (MX) | c SIG (MX) c A rdata | c A rdata c SIG (A) | c SIG (A) c NXT d A MX SIG NXT | c NXT @ A MX NXT NOSIG c SIG (NXT) | c SIG (NXT) d A rdata | d A rdata d SIG (A) d TXT "Bob's laptop" | d TXT "Bob's laptop" d TXT "DHCP assigned A" | d TXT "DHCP assigned A" d SIG(TXT) | d NXT @ A TXT SIG NXT | d SIG(NXT) | For name b and d, nothing is signed, for name c, everything is signed, for name a, there exist unsigned RR. Special usage at delegation points. Delegation point NS records are never signed in a secured zone. For a secure zone to indicate whether a subzone is considered secured or not, there must be a signed RRset present for that name other then the NS RRset. RFC 2535 states that for an unsecured subzone, there must be a "no-key" KEY RRset present. A "no-key" KEY is indicated by setting bit 0 and bit 1 in the flag field of the KEY's RDATA. The NOSIG RR type gives an alternative to this requirement. As said, the no-key's function is merely to have a verifiable substance at a delegation point to indicate a subzone is not secure. Because the NOSIG RR type allows for unsigned RRsets to exist within a name interval, delegation point NS with no other signed material (no-key's) can exist. This adds efficiency for some large delegation zones. In RFC 2535 there was the requirement of having a signed no-key KEY RR, a SIG(KEY), a NXT, and a SIG(NXT) for every unsecured subzone. With this scheme, multiple unsigned subzones can be covered with a single NXT. Examples of NOSIG at delegation points The following signed delegations gives an example of the NXT+NOSIG usage versus the rfc2535 NXT usage. without NOSIG | with NOSIG | a NS rdata | a NS rdata a KEY real-key | a KEY real-key a SIG(KEY) | a SIG(KEY) a NXT b NS KEY SIG NXT | a NXT e KEY NXT NOSIG a SIG(NXT) | a SIG(NXT) b NS rdata | b NS rdata b KEY no-key | b SIG(KEY) | b NXT c NS KEY SIG NXT | b SIG(NXT) | c NS rdata | c NS rdata c KEY no-key | c SIG(KEY) | c NXT d NS KEY SIG NXT | c SIG(NXT) | d NS rdata | d NS rdata d KEY no-key | d SIG(KEY) | d NXT c NS KEY SIG NXT | d SIG(NXT) | e NS rdata | e NS rdata e KEY real-key | e KEY real-key e SIG(KEY) | e SIG(KEY) e NXT @ NS KEY SIG NXT | e NXT @ NS KEY SIG NXT e SIG(NXT) | e SIG(NXT) Delegation points a and e are secure. points b, c and d are not. 4. The NXT RR with NOSIG indication in creation of responses. When a query-response contains usigned RRsets in the answer section, the NXT+NOSIG must appear in the authority section. When a query-response contains a referral to an unsecured zone, and there exists no no-key for the referral, the NXT+NOSIG must appear in the authority section Given the following records in a secure zone: a A rdata ; signed A record a SIG (A) ; a NXT c A NXT NOSIG ; NXT denies other signed RRsets a SIG (NXT) ; b A rdata ; unsigned A record c NS rdata ; Secured delegation point c DS rdata ; c SIG (DS) ; c NXT @ DS NXT NOSIG ; NXT denies other signed RRsets c SIG (NXT) ; d NS rdata ; Unsecure delegation point The current set of query-responses is extended with the following: 1 query: b.test. A query response: RCODE : NOERROR ANSWER : b.test. A rdata AUTHORITY: a.test. NXT c.test. A NXT NOSIG a.test. SIG (NXT) 2 query: d.test. A query response: RCODE : NOERROR ANSWER : ------- AUTHORITY: d.test. NS rdata c.test. NXT test. DS NXT NOSIG c.test. SIG (NXT) Query response 1 contains the unsigned b.test. A record. Query response 2 is a referral to an unsecured zone. 5. Security Considerations. Using NOSIG to allow for unsigned RRsets in a secure zone have the following implications on the overall security: 1. There is the possibility for a malicious user to let a secure resolver believe that a non-existent unsigned RRset exist. This is a very rare case. If that would be a problem for a domain, use NXT w/o NOSIG instead, as it does not allow for unsigned RRsets within a name interval. 2. There is the possibility for a malicious user to let a secure resolver believe that an existent unsigned RRset does not exist. If that would be a problem for a domain, sign the the RRset. 3. There is the possibility for a malicious user to let a secure resolver believe that a non-existent unsigned subzone exist. This is a very rare case. If that would be a problem for a domain, use no-key instead. 4. There is the possibility for a malicious user to let a secure resolver believe that an existent unsigned subzone does not exist. This is no different in the no-key scheme, because the NS RR itself are never signed, and might be forged to point to a non existent nameserver. Using NOSIG has no impact on signed RRsets and signed delegations. 6. IANA Considerations. The NOSIG RR type number should be selected by the IANA from the normal RR type space. 7. Acknowledgements The work in this draft is based on ideas stated in the [OPTIN] draft. The goals of these drafts are similar, though both use a different approach. The contributions, suggestions and remarks of the following persons (in alphabetic order) to this draft are acknowledged: Mats Dufberg Mark Kosters David Macka Dan Massey Scott Rose Jakob Schlyter Funding for the RFC Editor function is currently provided by the Internet Society. References [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [RFC3090] Wellington, B., "Secure Dynamic Update", RFC 3007, November 2000. [OPTIN] Kosters, M., "DNSSEC Opt-in for Large Zones", Internet- draft, June 2001. Author's Address Roy Arends 1e Atjehstraat 174-2 1094 KX Amsterdam The Netherlands Phone: +31-20-663-9306 EMail: Roy.Arends@nominum.com Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.