Internet DRAFT - draft-bill-dnsop-handling-zone-cuts
draft-bill-dnsop-handling-zone-cuts
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]
