Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves
RFC 8552
Document | Type |
RFC - Best Current Practice
(March 2019; Errata)
Also known as BCP 222
|
|
---|---|---|---|
Author | Dave Crocker | ||
Last updated | 2019-03-22 | ||
Replaces | draft-crocker-dns-attrleaf | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Reviews | |||
Stream | WG state | Submitted to IESG for Publication | |
Document shepherd | Benno Overeinder | ||
Shepherd write-up | Show (last changed 2018-07-21) | ||
IESG | IESG state | RFC 8552 (Best Current Practice) | |
Consensus Boilerplate | Yes | ||
Telechat date | |||
Responsible AD | Warren Kumari | ||
Send notices to | "Tim Wicinski" <tjw.ietf@gmail.com>, Benno Overeinder <benno@NLnetLabs.nl> | ||
IANA | IANA review state | IANA OK - Actions Needed | |
IANA action state | RFC-Ed-Ack |
Internet Engineering Task Force (IETF) D. Crocker Request for Comments: 8552 Brandenburg InternetWorking BCP: 222 March 2019 Category: Best Current Practice ISSN: 2070-1721 Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves Abstract Formally, any DNS Resource Record (RR) may occur under any domain name. However, some services use an operational convention for defining specific interpretations of an RRset by locating the records in a DNS branch under the parent domain to which the RRset actually applies. The top of this subordinate branch is defined by a naming convention that uses a reserved node name, which begins with the underscore character (e.g., "_name"). The underscored naming construct defines a semantic scope for DNS record types that are associated with the parent domain above the underscored branch. This specification explores the nature of this DNS usage and defines the "Underscored and Globally Scoped DNS Node Names" registry with IANA. The purpose of this registry is to avoid collisions resulting from the use of the same underscored name for different services. Status of This Memo This memo documents an Internet Best Current Practice. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8552. Crocker Best Current Practice [Page 1] RFC 8552 DNS AttrLeaf March 2019 Copyright Notice Copyright (c) 2019 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 (https://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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Underscore-Based Scoping . . . . . . . . . . . . . . . . 3 1.2. Scaling Benefits . . . . . . . . . . . . . . . . . . . . 4 1.3. Global Underscored Node Names . . . . . . . . . . . . . . 4 1.4. Interaction with DNS Wildcards . . . . . . . . . . . . . 5 1.5. History . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. "Underscored and Globally Scoped DNS Node Names" Registry . . 6 3. Guidance for Registering RRset Use . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 4.1. "Underscored and Globally Scoped DNS Node Names" Registry 8 4.2. Enumservices Registrations Registry . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Normative References . . . . . . . . . . . . . . . . . . 12 6.2. Informative References . . . . . . . . . . . . . . . . . 15 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction The core Domain Name System (DNS) technical specifications ([RFC1035] and [RFC2181]) assign no semantics to domain names or their parts, and no constraints upon which resource record (RR) types are permitted to be stored under particular names [RFC1035] [RFC2181]. Over time, some leaf node names, such as "www" and "ftp", have come to imply support for particular services, but this is a matter of operational convention rather than defined protocol semantics. This freedom in the basic technology has permitted a wide range of administrative and semantic policies to be used -- in parallel. DNS data semantics have been limited to the specification of particular resource record types on the expectation that new resource record Crocker Best Current Practice [Page 2] RFC 8552 DNS AttrLeaf March 2019 types would be added as needed. Unfortunately, the addition of newShow full document text