]> Cloudflare

jabley@cloudflare.com

USC/ISI

ietf@hardakers.net

Google, Inc.

warren@kumari.net

Operations and Management Domain Name System Operations DNS DNSSEC zone cut delegation referral This document defines a standard means to signal that a zone cut exists in the DNS without specifying a set of nameservers to which a child zone is delegated. This is useful in situations where it is important to make it clear to clients that a zone cut exists, but when the child zone is only provisioned in a private namespace. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Domain Name System Operations Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The DNS protocol, as originally specified in and , describes a single, global, hierarchical namespace that is separated into zones. The boundary between a parent zone and a child zone is indicated using a zone cut. Zone cuts are specified using specific resource records which are published within the parent and child zones; the parent-side resource records are revealed during DNS resolution by way of referral responses from nameservers. Private DNS namespaces also exist. A user of a private network might be able to resolve names using local DNS infrastructure that are not visible to other users of other networks. This is often an intentional and deliberate configuration by network operators, for example to provide name resolution for internal, private services that are not available to users of other networks. When a device or application uses the DNS protocol to resolve both internal names and external names published in the global DNS namespace, ambiguity can result. For example, DNS responses from Internet-reachable nameservers might indicate that a particular name published in an internal namespace does not exist, while an internal nameserver might be configured to respond differently. Since mobile devices can attach to different networks and can cache DNS responses obtained from different namespaces, this ambiguity can cause headaches. A DNSSEC-aware resolver on a mobile device might cache a signed, negative response from an external nameserver for a particular name and might treat a subsequent, positive response from an internal nameserver for the same name as bogus, preventing the response from being used by an application. This document provides a means of signalling the existence of a zone cut in a namespace in circumstances where the child zone only exists in a different namespace from the parent. We refer to this type of zone cut as a "zone cut to nowhere" and introduce the corresponding terms "delegation to nowhere" and "referral to nowhere" in .

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document uses DNS terminology as described in . Familiarity with terms defined in that document is assumed. This document also uses the following new terms:

1. "Zone cut to nowhere" -- a zone cut where the parent zone and the child zone are provisioned in different namespaces. A zone cut to nowhere is a signal provided by the administrator of a parent zone that a child zone exists, but is not able to be used in the DNS namespace of the parent.
2. "Delegation to nowhere" -- a delegation from a parent to a child across a zone cut to nowhere.
3. "Referral to nowhere", "Referral response to nowhere" -- a DNS response received from a nameserver that reveals the existence of a delegation to nowhere.

Publishing a Delegation to Nowhere A zone cut to nowhere is implemented in a parent zone using a single NS resource record with an empty target (an empty NSDNAME, in the parlance of ). A zone cut to nowhere between the parent zone EXAMPLE.ORG and the child zone DUCKLING.EXAMPLE.ORG with a TTL of 3600 seconds would be described in zone file syntax as follows: A zone cut to nowhere may also be provisioned as a secure delegation. This allows a DNSSEC-aware consumer of a referral response to obtain and cache a DNSSEC trust anchor for the child zone, for use when it is able to receive a signed response from a nameserver that includes the child zone in its namespace. An NS RRSet in a parent zone which includes multiple NS resource records is not a delegation to nowhere, even if one of the NS resource records within the RRSet has an empty target. This NS RRSet does not encode a delegation to nowhere, since other NS resource records exist in addition to the record with the empty target (marked with a comment as "unusual"). This configuration may have some other meaning in a different context, however, and is specifically not addressed by this specification.

Interpreting a Referral to Nowhere No special processing is necessary in order to interpret a referral response to nowhere. Individual RRSets present in a referral response to nowhere can safely be interpreted and processed in an identical fashion to any other referral response where the authoritative servers for the child zone cannot themselves be resolved, and hence cannot be reached.

Applicability When a child zone is known to exist in another namespace, and when that other namespace is intended for use with the DNS, a delegation to nowhere MAY be provisioned in the parent zone to signal that the child zone exists in some other namespace. In such circumstances the parent zone MAY be the root zone, or any other zone. A secure delegation to nowhere MAY be provisioned if the keys used for signing in the child zone are known to the administrator of the parent zone. In the case where differently-signed (or unsigned) child zones are known to exist in different namespaces, a secure delegation SHOULD NOT be used. The use of a delegation to nowhere in this document is described for the IN class only. Use of this mechanism in other classes is not addressed by this specification. Name resolution protocols other than the DNS are also used by some systems, for names that are syntactically equivalent to domain names in the DNS. In some cases, names resolved by those non-DNS protocols are anchored in a specific domain that is consequently reserved for their use in the DNS, to avoid name collisions. Examples of such reservations in the DNS are the LOCAL top-level domain reserved for use by Multicast DNS and the ALT top-level domain reserved use in general for non-DNS resolution protocols . Domains that are not intended for use with the DNS as their resolution protocol SHOULD NOT be provisioned in the DNS as delegations to nowhere, since there is no DNS namespace ambiguity that such a configuration could help with.

Examples

Internal Namespace as a Subdomain of a Public Domain A company uses names within the EXAMPLE.COM domain both for internal services it provides to its employees and for public services that are made available to the general public over the Internet. The company also provides certain services that are only available to users of devices attached to its internal network. Those services are named within the subdomain CORP.EXAMPLE.COM. The company does not wish those internal services to be visible to external users. We say that the EXAMPLE.COM zone exists in the global DNS namespace and that the CORP.EXAMPLE.COM zone exists only in a private DNS namespace. The company publishes a CORP.EXAMPLE.COM zone on DNS nameservers attached to its internal network. The company configures the DNS resolvers used by devices attached to its internal network to be aware that the CORP.EXAMPLE.COM zone is served by those internal nameservers, such that queries sent from devices inside the company's network can resolve names in the CORP.EXAMPLE.COM domain. The company publishes an EXAMPLE.COM zone on nameservers that are general reachable over the Internet -- that is, the nameservers are reachable and the COM zone returns referrals for the EXAMPLE.COM zone to those nameservers. The EXAMPLE.COM zone includes names that the company wants clients to be able to resolve regardless of what network they are connected to.

General Purpose Top-Level Domain for Internal Namespaces Suppose it has been decided that the top-level domain INTERNAL be reserved for use in private namespaces. The root zone of the global DNS is signed using DNSSEC ; that is, DNSSEC-specific RRSets are published in the root zone that allow DNSSEC-aware resolvers to be sure with cryptographic certainty whether particular top-level domains exist in the public namespace. A delegation to nowhere for the INTERNAL top-level domain in the root zone of the global DNS namespace would provide an unambiguous signal to resolvers that INTERNAL does exist in other namespaces. An insecure delegation to nowhere is appropriate in this example since there is no single trust anchor that could be used to provide a secure delegation to zones in multiple namespaces that have different, non-cooperating administrators.

Updates to RFC 1035 This document updates as follows:

• NSDNAME MAY be specified as a single, zero-length label. An NS RRSet that consists of a single NS resource record with empty NSDNAME is used to indicate that a zone cut exists without providing any authoritative nameservers for the child zone. The purpose of such an RRSet is to confirm that the child zone exists, but in a different namespace from the parent (e.g. in a private namespace).

Other Uses of the Empty Name in the DNS In an MX resource record with an empty target (called EXCHANGE in ) is specified to mean that the corresponding domain name does not accept e-mail. In effect, the empty field is used to indicate that there is no host available to use for e-mail delivery. In an SRV 'Target of "." means that the service is decidedly not available at this domain.' notes that 'For AliasMode SVCB RRs, a TargetName of "." indicates that the service is not available or does not exist.' These uses of the empty name are conceptually consistent with the meaning defined in this document: that using an empty name is to be interpreted as the corresponding function not being available.

Operational Considerations The empty name is not known to have been widely used as an NS target, although it has been used as an MX target, as described in . It is a reasonable concern that if delegations to nowhere became prevalent, or if names related to such zone cuts were associated with significant traffic, some operational problem might result. For example, DNS software that made incompatible assumptions about DNS responses might fail, or harmful traffic to root servers might result. Some experiments carried out by the authors to assess the likelihood of such problems are described in . The results of those experiments do not suggest that the widespread use of delegations to nowhere would lead to operational problems.

Security Considerations This document provides a means for both internal and global namespaces to be provisioned using DNSSEC, allowing a DNSSEC-aware, mobile resolver to maintain a consistent chain of trust regardless of whether a private, child namespace exists from it's particular vantage point. The ability to support this configuration cleanly has better security properties than configurations that are ambiguous.

IANA Considerations This document has no IANA actions. The example of the designated top-level domain INTERNAL being provisioned as a delegation of INTERNAL to nowhere from the root zone was intentionally chosen in order to make it clear that such a configuration is allowed, is consistent with this specification and facilitates the use of private namespaces named under such a top-level domain with less ambiguity than might otherwise occur. This document does not provide any operational direction to the IANA, however.

References Normative References This RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their used for host address look up and electronic mail forwarding. It discusses the clients and servers in the domain name system and the protocol used between them. This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document updates RFC 2308 by clarifying the definitions of "forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarifications. Comprehensive lists of changed and new definitions can be found in Appendices A and B. The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK] Informative References William Morrow & Company, ISBN 978-0380976539 Talking Heads from the album "Little Creatures", Sire Records As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server is useful. Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventional Unicast DNS server. In addition, Multicast DNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names. The primary benefits of Multicast DNS names are that (i) they require little or no administration or configuration to set them up, (ii) they work when no infrastructure is present, and (iii) they work during infrastructure failures. This document reserves a Top-Level Domain (TLD) label "alt" to be used in non-DNS contexts. It also provides advice and guidance to developers creating alternative namespaces. Internet mail determines the address of a receiving server through the DNS, first by looking for an MX record and then by looking for an A/AAAA record as a fallback. Unfortunately, this means that the A/AAAA record is taken to be mail server address even when that address does not accept mail. The No Service MX RR, informally called "null MX", formalizes the existing mechanism by which a domain announces that it accepts no mail, without having to provide a mail server; this permits significant operational efficiencies. This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain. [STANDARDS-TRACK] This document specifies the "SVCB" ("Service Binding") and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics"). By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy.

Experiments Wes has committed acts of science. He will describe them here.

Acknowledgments The authors stand ready to acknowledge all contributions from their friends and colleagues. The phrase "delegation to nowhere" was inspired by the misremebered title of a novel by Tim Powers entitled "Two Days to Nowhere", in which characters deal with ambiguous realities by way of supernatural sensitivity, time travel and alcohol. This seemed like a good metaphor for the problem of provisioning overlapping namespaces in the DNS. Unfortunately, it appears that Tim Powers wrote no such book, although he did publish the similarly-named novel "Three Days to Never" which is perhaps what I was thinking of. And it's certainly true that much of his writing features ambiguity, the supernatural and excessive drinking. Memory is a tricky thing. The song "Road to Nowhere" from the 1985 Talking Heads album "Little Creatures" would perhaps have been a better inspiration for the terminology. It's a shame that's not what happened.