INTERNET-DRAFT Declan Ma, Ed. Intended Status: Proposed Standard zDNS Ltd. Expires: 2015-10-15 2015-05-22 Handling DNS Zone Cuts draft-bill-dnsop-handling-zone-cuts-00 Abstract RFC 2181 collected eight independent considerations and created a single docuement to address each of them in turn. Over the following two decades it has become clear that each of these items should be considered and evovolve in its own right, as suggested in RFC 2181. This document extracts the exact text from RFC 2181 and places it into its own track. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Declan Ma, Ed. Expires 2015-10-15 [Page 1] INTERNET DRAFT Handling DNS Zone Cuts 2015-05-22 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3 Zone authority . . . . . . . . . . . . . . . . . . . . . . . . 3 4 DNSSEC issues . . . . . . . . . . . . . . . . . . . . . . . . . 3 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 4 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 5 Declan Ma, Ed. Expires 2015-10-15 [Page 2] INTERNET DRAFT Handling DNS Zone Cuts 2015-05-22 1 Introduction The DNS tree is divided into "zones", which are collections of domains that are treated as a unit for certain management purposes. Zones are delimited by "zone cuts". Each zone cut separates a "child" zone (below the cut) from a "parent" zone (above the cut). The domain name that appears at the top of a zone (just below the cut that separates the zone from its parent) is called the zone's "origin". The name of the zone is the same as the name of the domain at the zone's origin. Each zone comprises that subset of the DNS tree that is at or below the zone's origin, and that is above the cuts that separate the zone from its children (if any). The existence of a zone cut is indicated in the parent zone by the existence of NS records specifying the origin of the child zone. A child zone does not contain any explicit reference to its parent. This document is intended to present correct handling of DNS zone cuts. 2 Terminology 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]. 3 Zone authority The authoritative servers for a zone are enumerated in the NS records for the origin of the zone, which, along with a Start of Authority (SOA) record are the mandatory records in every zone. Such a server is authoritative for all resource records in a zone that are not in another zone. The NS records that indicate a zone cut are the property of the child zone created, as are any other records for the origin of that child zone, or any sub-domains of it. A server for a zone should not return authoritative answers for queries related to names in another zone, which includes the NS, and perhaps A, records at a zone cut, unless it also happens to be a server for the other zone. Other than the DNSSEC cases mentioned immediately below, servers should ignore data other than NS records, and necessary A records to locate the servers listed in the NS records, that may happen to be configured in a zone at a zone cut. 4 DNSSEC issues Declan Ma, Ed. Expires 2015-10-15 [Page 3] INTERNET DRAFT Handling DNS Zone Cuts 2015-05-22 The DNS security mechanisms [RFC2065] complicate this somewhat, as some of the new resource record types added are very unusual when compared with other DNS RRs. In particular the NXT ("next") RR type contains information about which names exist in a zone, and hence which do not, and thus must necessarily relate to the zone in which it exists. The same domain name may have different NXT records in the parent zone and the child zone, and both are valid, and are not an RRSet. Since NXT records are intended to be automatically generated, rather than configured by DNS operators, servers may, but are not required to, retain all differing NXT records they receive. For a secure parent zone to securely indicate that a subzone is insecure, DNSSEC requires that a KEY RR indicating that the subzone is insecure, and the parent zone's authenticating SIG RR(s) be present in the parent zone, as they by definition cannot be in the subzone. Where a subzone is secure, the KEY and SIG records will be present, and authoritative, in that zone, but should also always be present in the parent zone (if secure). Note that in none of these cases should a server for the parent zone, not also being a server for the subzone, set the AA bit in any response for a label at a zone cut. 5 Security Considerations It is not believed that anything in this document adds to any security issues that may exist with the DNS, nor does it do anything to that will necessarily lessen them. Correct implementation of the clarifications in this document might play some small part in limiting the spread of non-malicious bad data in the DNS, but only DNSSEC can help with deliberate attempts to subvert DNS data. 6 References [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. [RFC2065] Eastlake 3rd, D. and C. Kaufman, "Domain Name System Security Extensions", RFC 2065, January 1997. Declan Ma, Ed. Expires 2015-10-15 [Page 4] INTERNET DRAFT Handling DNS Zone Cuts 2015-05-22 [RFC2199] Ramos, A., "Request for Comments Summary RFC Numbers 2100- 2199", RFC 2199, January 1998. 7 Authors' Addresses Declan Ma, Ed. ZDNS Ltd. 4, South 4th Street, Zhongguancun, Haidian, Beijing 100190, China Declan Ma, Ed. Expires 2015-10-15 [Page 5]