RFC 8552

Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves

📅 published March 2019, from ietf

Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves 🎀

  • Series: Request for Comments 8552, BCP 222 🌸
  • Stream: Internet Engineering Task Force (IETF) 🦋
  • Author: D. Crocker, Brandenburg InternetWorking 💅
  • Category: Best Current Practice ✨
  • Date: March 2019 📅
  • ISSN: 2070-1721 🔥
  • Obsoletes / Updates: nothing listed in the header, so this one stands on its own 🫶

Abstract ✨

Okay so, technically any DNS Resource Record (RR) can sit under any domain name 💅. But some services have a little unwritten rule: they park records in a branch under the parent domain the RRset actually belongs to 🧚. The top of that branch is a reserved node name that starts with an underscore (like "_name") 🦋. That underscored name basically creates a semantic scope for the record types attached to the parent domain above it 💖. This spec digs into how that DNS usage works and sets up the "Underscored and Globally Scoped DNS Node Names" registry with IANA 👑. The whole point of the registry is to stop two services from accidentally grabbing the same underscored name 😭.

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 went through public review and got approved for publication by the Internet Engineering Steering Group (IESG) ✨. If you want more info on BCPs, check Section 2 of RFC 7841 💜.

For the current status of this document, any errata, and how to send feedback, head to https://www.rfc-editor.org/info/rfc8552 🔗.

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), as they stand on the date this document was published 📜. Please read those carefully, because they spell out your rights and restrictions for this document 🙈. Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions 🔥. They also come 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 🌸

Okay, so the core DNS specs ([RFC1035] and [RFC2181]) don't give meaning to domain names or their parts 🧠. They also don't limit which RR types can live under which names [RFC1035] [RFC2181] 💅. Over time, leaf names like "www" and "ftp" picked up a vibe of "this runs a certain service" 🌈. But that's just operational convention, not defined protocol semantics 🙈. That freedom is why so many different admin and semantic policies can run side by side 🦋. DNS data meaning has mostly been limited to specific RR types, with the assumption that new types would show up when needed 🍓. The problem? Adding new RR types has been super hard, with big adoption barriers over the whole life of the DNS 😭.

1.1. Underscore-Based Scoping

Instead of inventing a brand-new RR TYPE, some DNS service upgrades reuse an existing record type and then restrict where it's allowed to appear ✨. Scope here is a static property, not something that changes based on the query 💖. It's just part of the DNS name itself 🎀. The scope is a leaf node holding specific resource record sets that are formally defined and constrained 💅. Here's how it works:

The leaf sits in a branch with a distinguished naming convention. There's a parent domain name the scoped data applies to, and the branch lives under that name. The sub-branch is marked by one or more reserved DNS node names, and at least the first (highest) one begins with an underscore (e.g., "_name").

Since DNS rules for a "host" (host name) don't allow underscores, an underscored name can always be told apart from any legal host name [RFC0952] 🔥. Basically, this naming trick creates a spot for "attributes" 🧚, in the form of resource record types, that belong to the parent domain above the underscored sub-branch 🫶.

Scoping is especially handy with generalized RR types, like "TXT", "SRV", and "URI" [RFC1035] [RFC2782] [RFC6335] [RFC7553] 💜. It cleanly separates one use of them from all the others ✨. Without it, you get a messy pile of these RRsets sent back to the DNS client, which then has to dig through the records and hope it finds the relevant ones 😭. Even worse, sometimes the results are ambiguous, because a record type might not clearly say what it's for 🙈. With underscore-based scoping, only the relevant RRsets come back 👑.

A classic example is DomainKeys Identified Mail (DKIM) [RFC6376], which uses "_domainkey" as a place to hold a TXT record with signing info for the parent domain 🌈.

This spec officially defines how underscored names act as "attribute" add-ons for their parent domain names 💅. For example, the domain name "_domainkey.example." is an attribute of the parent domain name "example." 🦋. To stop collisions when different apps use the same underscored names with the same RR type, this document sets up the "Underscored and Globally Scoped DNS Node Names" registry with IANA 🎀. Using these underscored node names is reserved when they're the underscored name closest to the DNS root, because then they count as "global" 👑. Underscored names farther down the hierarchy get handled inside the scope of that global underscored node name 🧚.

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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🫶.

1.2. Scaling Benefits

Some RR types can cause scaling problems if the whole RRset for a domain name gets crammed into that name's leaf node 😭. A popular and honestly iconic approach, with excellent scaling properties, puts the RRset under a specially named branch 💅. That branch then sits under the node name that would have held the RRset anyway 🌸. The naming rules for that branch set the context for reading the RRset 🧠. So instead of this:

                            domain-name.example
                              /
                             RRset

you get this:

                        _branch.domain-name.example
                          /
                         RRset

Looking up the subordinate leaf node directly returns only the record types you want 🎀. And it costs no more than a typical DNS lookup ✨. Slay 💖.

1.3. Global Underscored Node Names

As defined in [RFC1034], the DNS organizes names in a tree-structured, hierarchical way 🌳. A domain name can have several node names that start with an underscore (e.g., "_name") 🦋. A global underscored node name is the one closest to the root of the DNS hierarchy, which is also called the highest level or topmost 👑. Using the presentation convention from Section 3.1 of [RFC1034], that's the rightmost name starting with an underscore 🧚.

Other presentation environments might position it differently 🙈. So to avoid worrying about those presentation variations, this document uses the qualifier "global" 💜.

1.4. Interaction with DNS Wildcards

DNS wildcards don't play nicely with underscored names, and there are two reasons why 😭.

First, wildcards only get interpreted as leaf names. So you can't make the equivalent of a wildcard name for prefixed names. A name like label.*.example.com is not a wildcard 💅.

Second, a wildcard like *.example.com can match any name, including an underscored one 👀. So a wildcard might match an underscored name and return a record of the type that the underscored name controls, even though that record isn't meant to be used in the underscored context and doesn't follow its rules 🙈.

1.5. History

Originally, different uses of underscored node names developed mostly without any coordination 🌈. For TXT records, there's no consistent internal syntax that lets you tell the different uses apart 🫠. The SRV RR and URI RR are different, because telling apart the types of use was part of their design (see [RFC2782] and [RFC7553]) 💖. The SRV and URI specs basically serve as templates, defining RRs that might only be used for specific applications when there's an additional specification ✨. The template includes a reference to two levels of name tables that underscored names should come from 📚. The lower-level (local scope) set of "_service" names is defined in terms of other IANA tables, specifically any table with symbolic names 🎀. The upper-level (global scope) SRV naming field is "_proto", although its pool of names isn't explicitly defined 🧚.

All these independent efforts added up to a long list of underscored names that got reserved without coordination 😭. That invites a name-assignment collision someday 💀. The fix is this base document, plus a companion document ([RFC8553]), which together define a registry for these names 🔥. They also try to register all the names already in use, and point changes toward the pre-registry specs that used global underscored node names 👑.

2. "Underscored and Globally Scoped DNS Node Names" Registry ✨

Okay so, this section makes a registry for global DNS node names that start with an underscore 🎀. The whole point is to stop collisions, which happen when two different apps use the same underscored name for totally different things 😭. Nobody wants that drama.

If a public specification calls for use of an underscored node name, the global underscored node name -- the underscored name that is closest to the DNS root -- MUST be entered into this registry. 🌸

An underscored name sets the scope for specific resource record types, and those record types are tied to the domain name that is the "parent" of the branch the underscored name creates. So a given name gives you a specific, constrained context for one or more RR TYPEs, and those record types have to follow the constraints that were defined for them 💅.

  • Within a leaf that is underscore scoped, other RRsets that are not specified as part of the scope MAY be used. 🦋

Structurally, the registry is one flat table of RR TYPEs, sitting under node names that begin with an underscore. Sometimes, like with an SRV record, the full scoping name has more than one part, a sequence of underscored names 🧚. That sequence is a hierarchy, and it's actually fine to reuse a lower-level underscored name in a different, global underscored context. The lower name only means something inside its global parent, so this registry ignores those lower names 🙈. The registry is only for defining the highest-level, meaning global, underscored node name that's being used.

                  +----------------------------+
                  |                       NAME |
                  +----------------------------+
                  |                  _service1 |
                  |          _protoB._service2 |
                  |          _protoB._service3 |
                  |          _protoC._service3 |
                  |    _useX._protoD._service4 |
                  | _protoE._region._authority |
                  +----------------------------+

              Table 1: Examples of Underscored Names

Only global underscored node names get registered in the "Underscored and Globally Scoped DNS Node Names" registry. Using the example above, that means _service1, _service2, _service3, _service 4, and _authority would go into the IANA registry 🍓.

  • The use of underscored node names is specific to each RR TYPE that is being scoped. Each name defines a place, but it doesn't define the rules for what goes underneath that place, whether that's more underscored naming or a leaf node with resource records. Those rules come from the specifications for the individual RR TYPEs. The sections below describe how the existing underscored names are used with the RR TYPEs they name. 🫶
  • Definition and registration of subordinate underscored node names are the responsibility of the specification that creates the global underscored node name registry entry. ✨

So basically, if a scheme uses a global underscored node name and it has one or more lower levels of underscored naming, the namespaces for those lower names are controlled by the parent underscored node name. Each registered global underscored node name owns its own distinct, subordinate namespace 👑.

3. Guidance for Registering RRset Use 🦋

This section is for spec writers. It gives them a basic template to register new entries in the "Underscored and Globally Scoped DNS Node Names" registry. The template can be added to specs that use RR TYPE / _NODE NAME combinations that aren't registered yet 💖:

Per RFC 8552, please add the following entry to the "Underscored and Globally Scoped DNS Node Names" registry:
+---------+-------------------+-------------------------------------+
| RR Type | _NODE NAME        | Reference                           |
+---------+-------------------+-------------------------------------+
| {RR     | _{DNS global node | {citation for the document making   |
| TYPE}   | name}             | the addition.}                      |
+---------+-------------------+-------------------------------------+

               Table 2: Template for Entries in the
     "Underscored and Globally Scoped DNS Node Names" Registry

4. IANA Considerations 🌈

IANA has set up the "Underscored and Globally Scoped DNS Node Names" registry. This section covers the registry, its definitions, the initial entries, the use of_ta and _example, and the use of [RFC8126] as guidance for expert review 🔥. IANA also updated the "Enumservices Registrations" registry with a pointer to this document 🌸.

4.1. "Underscored and Globally Scoped DNS Node Names" Registry 💅

The "Underscored and Globally Scoped DNS Node Names" registry includes any DNS node name that begins with the underscore character ("_", ASCII 0x5F) and is the underscored node name closest to the root. In other words, it defines the highest level of a DNS branch under a "parent" domain name ✨.

  • This registry operates under the IANA rules for "Expert Review" registration; see Section 4.1.5. 🎀
  • The contents of each entry in the registry are defined in Section 4.1.1. 📝
  • Each entry in the registry MUST contain values for all of the fields specified in Section 4.1.1. 💜
  • Within the registry, the combination of RR Type and _NODE NAME MUST be unique. 🦋
  • The table is maintained with entries sorted by the first column (RR Type) and, within that, the second column (_NODE NAME). 🧚
  • The required Reference for an entry MUST have a stable resolution to the organization controlling that registry entry. 🫶

4.1.1. Contents of an Entry in the "Underscored and Globally Scoped DNS Node Names" Registry 📋

Each registry entry contains:

  • RR Type: Lists an RR TYPE that is defined for use within this scope.
  • _NODE NAME: Specifies a single, underscored name that defines a reserved name. This name is the global entry name for the scoped resource record types that are associated with that name. For characters in the name that have an uppercase form and a lowercase form, the character MUST be recorded as lowercase to simplify name comparisons. 🍓
  • Reference: Lists the specification that defines a record type and its use under this _Node Name. The organization producing the specification retains control over the registry entry for the _Node Name. 🌷

Each RR TYPE that is to be used with a _Node Name MUST have a separate registry entry. 💖

4.1.2. Initial Node Names 🌟

Here are the initial entries in the registry, all lined up and ready to go 💅:

      +------------+-----------------------+---------------+
      | RR Type    | _NODE NAME            | Reference     |
      +------------+-----------------------+---------------+
      | *          | _example              | Section 4.1.4 |
      | NULL       | _ta-* {Section 4.1.3} | [RFC8145]     |
      | OPENPGPKEY | _openpgpkey           | [RFC7929]     |
      | SMIMEA     | _smimecert            | [RFC8162]     |
      | SRV        | _dccp                 | [RFC2782]     |
      | SRV        | _http                 | [RFC4386]     |
      | SRV        | _ipv6                 | [RFC5026]     |
      | SRV        | _ldap                 | [RFC4386]     |
      | SRV        | _ocsp                 | [RFC4386]     |
      | SRV        | _sctp                 | [RFC2782]     |
      | SRV        | _sip                  | [RFC5509]     |
      | SRV        | _tcp                  | [RFC2782]     |
      | SRV        | _udp                  | [RFC2782]     |
      | SRV        | _xmpp                 | [RFC3921]     |
      | TLSA       | _dane                 | [RFC7671]     |
      | TLSA       | _sctp                 | [RFC6698]     |
      | TLSA       | _tcp                  | [RFC6698]     |
      | TLSA       | _udp                  | [RFC6698]     |
      | TXT        | _acme-challenge       | [RFC8555]     |
      | TXT        | _dmarc                | [RFC7489]     |
      | TXT        | _domainkey            | [RFC6376]     |
      | TXT        | _mta-sts              | [RFC8461]     |
      | TXT        | _spf                  | [RFC7208]     |
      | TXT        | _sztp                 | [ZEROTOUCH]   |
      | TXT        | _tcp                  | [RFC6763]     |
      | TXT        | _udp                  | [RFC6763]     |
      | TXT        | _vouch                | [RFC5518]     |
      | URI        | _acct                 | [RFC6118]     |
      | URI        | _dccp                 | [RFC7566]     |
      | URI        | _email                | [RFC6118]     |
      | URI        | _ems                  | [RFC6118]     |
      | URI        | _fax                  | [RFC6118]     |
      | URI        | _ft                   | [RFC6118]     |
      | URI        | _h323                 | [RFC6118]     |
      | URI        | _iax                  | [RFC6118]     |
      | URI        | _ical-access          | [RFC6118]     |
      | URI        | _ical-sched           | [RFC6118]     |
      | URI        | _ifax                 | [RFC6118]     |
      | URI        | _im                   | [RFC6118]     |
      | URI        | _mms                  | [RFC6118]     |
      | URI        | _pres                 | [RFC6118]     |
      | URI        | _pstn                 | [RFC6118]     |
      | URI        | _sctp                 | [RFC6118]     |
      | URI        | _sip                  | [RFC6118]     |
      | URI        | _sms                  | [RFC6118]     |
      | URI        | _tcp                  | [RFC6118]     |
      | URI        | _udp                  | [RFC6118]     |
      | URI        | _unifmsg              | [RFC6118]     |
      | URI        | _vcard                | [RFC6118]     |
      | URI        | _videomsg             | [RFC6118]     |
      | URI        | _voice                | [RFC6118]     |
      | URI        | _voicemsg             | [RFC6118]     |
      | URI        | _vpim                 | [RFC6118]     |
      | URI        | _web                  | [RFC6118]     |
      | URI        | _xmpp                 | [RFC6118]     |
      +------------+-----------------------+---------------+

                 Table 3: Initial Contents of the
     "Underscored and Globally Scoped DNS Node Names" Registry

4.1.3. _ta 🌙

Under the NULL RR Type, the entry "_ta-" denotes all node names beginning with the string "_ta-". It does NOT refer to a DNS wildcard specification 🙈.

4.1.4. _example 🧚

The node name "_example" is reserved across all RRsets 🎀.

4.1.5. Guidance for Expert Review ✨

okay bestie, this is the part where the expert reviewer gets their checklist 💅 and honestly it's so organized it's giving clean code review energy 🫶

This review is solely to determine adequacy of a requested entry in this registry, and it does not include review of other aspects of the document specifying that entry. For example, such a document might also contain a definition of the resource record type that is referenced by the requested entry. Any required review of that definition is separate from the expert review required here.

The review is for the purposes of ensuring that:

  • The details for creating the registry entry are sufficiently clear, precise, and complete
  • The combination of the underscored name, under which the listed resource record type is used, and the resource record type is unique in the table

For the purposes of this expert review, other matters of the specification's technical quality, adequacy, or the like are outside of scope. 🙈

4.2. Enumservices Registrations Registry 🎀

okay so there's a note that got added to the "Enumservice Registrations" registry, and it's lowkey a big deal 🦋

When adding an entry to this registry, strong consideration should be given to also adding an entry to the "Underscored and Globally Scoped DNS Node Names" registry.

5. Security Considerations 💀

This memo raises no security issues. 🌸

6. References 📚

6.1. Normative References

bestie, these are the references this doc needs to work, and I'm not cutting a single one 🫶

6.2. Informative References 🦋

  • [RFC8553] Crocker, D., "DNS Attrleaf Changes: Fixing Specifications That Use Underscored Node Names", RFC 8553, DOI 10.17487/RFC8553, March 2019, <https://www.rfc-editor.org/info/rfc8553>.
  • [ZEROTOUCH] Watsen, K., Abrahamsson, M., and I. Farrer, "Secure Zero Touch Provisioning (SZTP)", Work in Progress, draft-ietf-netconf-zerotouch-29, January 2019.

Acknowledgements 🫶

Thanks go to Bill Fenner, Dick Franks, Tony Hansen, Martin Hoffmann, Paul Hoffman, Peter Koch, Olaf Kolkman, Murray Kucherawy, John Levine, Benno Overeinder, and Andrew Sullivan for diligent review of the (much) earlier draft versions. For the later enhancements, thanks to Stephane Bortzmeyer, Alissa Cooper, Bob Harold, Joel Jaeggli, Benjamin Kaduk, Mirja Kuehlewind, Warren Kumari, John Levine, Benno Overeinder, Eric Rescorla, Adam Roach, Petr Spacek, Ondrej Sury, Paul Vixie, Tim Wicinski, and Paul Wouters.

Special thanks to Ray Bellis for his persistent encouragement to continue this effort, as well as the suggestion for an essential simplification to the registration model. 🌈

Author's Address 🧚

Dave Crocker Brandenburg InternetWorking 675 Spruce Dr. Sunnyvale, CA 94086 United States of America

Phone: +1.408.246.8253 Email: dcrocker@bbiw.net URI: http://bbiw.net/

📦 where this page comes from