Summary

  • RFC 8552, a Best Current Practice published in March 2019, formalized the use of an underscored branch below a parent domain to give otherwise general DNS record types a narrower meaning. The label nearest the DNS root is the globally scoped one.
  • Its IANA registry guards the combination of record type and global underscored label. Expert review checks whether that combination is unique and sufficiently specified; lower labels belong to the scope of the global name's own specification.
  • RFC 8553 updated older specifications, including the templates for SRV and URI records, to point at the integrated registry while preserving existing software and operating practice. The register organizes the naming convention; an authoritative zone and a client lookup show what a particular service actually publishes and reads.

A type code could not carry every meaning

DNS was built to store records beneath names. Its core rules do not assign a meaning to every part of a domain name or dictate that one record type may appear only under one kind of name. That freedom let different applications publish data without waiting for a fresh DNS type code each time. It also meant that a general type such as TXT could accumulate unrelated instructions if everyone treated the parent name as the only shelf.

RFC 8552 describes the solution as a branch below the parent domain. Rather than placing every record set directly under example.org, a protocol can put its relevant records beneath _name.example.org. The branch name tells that protocol what the record set is for; the parent remains the domain to which the information applies. A query for the branch retrieves the intended data without forcing the client to sort through every other use of the same record type at the parent.

The underscore has a practical role in that design. Host-naming rules kept underscored labels separate from ordinary host labels. A name such as _name therefore signals a place for an attribute, rather than pretending to be another host named name. This is a naming convention within DNS, not a new DNS packet format. The records still use their ordinary types. Their location gives them a narrower interpretation.

Service location had already shown the appeal. RFC 2782, from February 2000, used _Service._Proto.Name for SRV records, prefixing service and protocol labels to avoid collisions with naturally occurring host labels. DNS-Based Service Discovery later used the same established convention. Those protocols explain how their own lookups work. RFC 8552 addressed a wider problem: many specifications were minting top-level underscored slots in the same namespace without a single collision check.

The highest shelf is the contested one

An underscored branch can have more than one label. The one closest to the DNS root is the globally scoped label. Everything farther down sits under its scope. That distinction matters because the global label is the first common claim made by otherwise unrelated specifications. A protocol can define subordinate labels inside its own branch, but it cannot quietly reuse the same global slot with the same record type for an incompatible purpose without risking confusion.

RFC 8552 created the IANA register called “Underscored and Globally Scoped DNS Node Names”. Its columns are RR Type, underscored node name, and reference. The key is a pair: the record type and the global label. Two services may use the same RR type under distinct labels; the same label may appear with distinct RR types. The collision the registry guards is a second claim to the same pair. This is more precise than a general ban on underscores or a list of every leaf name in every protocol.

The registration procedure is Expert Review. The reviewer checks that the entry is clear and that its record-type/name combination is unique. RFC 8552 explicitly keeps a general judgment on the protocol's technical quality outside that review. A clean assignment stops two authors fighting over one slot; it does not certify that the protocol occupying it is good or that a domain operator has published the intended data.

A reader can see the boundary in the current IANA DNS Parameters register. It supplies references for the global slots. To find what belongs under a slot, the client needs the referenced protocol specification. To know whether a named domain uses it, the client needs that domain's authoritative answer. Three sources, three different questions. The register cannot play the part of a live zone file.

A later rule had to catch old paperwork

The convention was older than its central list. Earlier RFCs had introduced underscored names without the new register because the register did not yet exist. RFC 8553, published alongside RFC 8552 in March 2019, handled the resulting paperwork. It updated prior specifications to signal the integrated registry and revised the SRV and URI meta-templates so new global names would use that one process.

That repair was deliberately narrow. RFC 8553 says it preserved existing software and operating practice while changing the technical specifications. The protocol did not gain a new wire format on publication day. Existing zones did not have to rename every record because an IANA table appeared. The coordination rule changed how future names were claimed and how readers of older documents found the current assignment authority.

This is why the 2000 SRV story and the 2019 registry story are different. The former explains how a client asks where a service runs and uses service and protocol labels to frame the lookup. The latter asks who may assign the outer label when multiple protocol designers need scoped data under a domain. One concerns locating a target; the other concerns preventing two meanings from occupying the same naming slot. The underscore survived both stories. Its custodian changed.

RFC 8552 also resisted turning the register into a universal taxonomy of DNS. Names below the global label belong to the defining specification. The record type continues to say what kind of DNS record is stored; the branch says how that protocol interprets it. The register coordinates only the globally scoped claim. That is enough to prevent the specific collision the document identified without pretending to govern every sub-branch invented by an application.

The official texts establish the naming rule, the pair used as a registry key, and the update to older specifications. To show that a named service ran through one of these slots, the missing proof is a dated authoritative zone capture and the client's lookup of that name and record type. A well-formed registry entry is a starting address for the investigation. The answer comes from the zone and the code that asks it.