]> Brandenburg InternetWorking

675 Spruce Dr. Sunnyvale CA 94086 USA +1.408.246.8253 dcrocker@bbiw.net http://bbiw.net/

Operations DNS Domain Name System> Historically, any DNS RR may occur for any domain name. Recent additions have defined DNS leaf nodes that contain a reserved node name, beginning with an underscore. The underscore construct is used to define a semantic scope for the name, within which the choice of valid RRs is limited to a defined set. Hence the underscore construct defines a basic paradigm modification to the DNS. This note explores the nature of this DNS usage and defines the procedures for registering new "underscore names" with IANA.

Historically, any DNS RR may occur for any domain name. The DNS technical specification assigns no semantics to domain names and no constraints upon which resource records may be associated with a particular name. 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 semantics. This freedom in the basic technology has permitted a wide range of administrative and semantic policies to be used -- in parallel -- with the DNS. In the DNS data semantics have been limited to specifications for specific resource records, on the expectation that new ones would be added as needed. Although there remains an expectation that this method of enhancement is preferred, alternative approaches have been explored. Recent additions have defined DNS leaves that contain a reserved leaf node name, beginning with an underscore. The underscore construct is used to define a semantic scope for the name, within which the choice of valid RRs is limited to a defined set. Hence the underscore construct defines a basic paradigm modification to the DNS. Within the scope of a defined underscore leaf, the specific uses of specific resource records can be formally defined and constrained. An established example is the SRV record, which generalizes concepts long-used for email routing in the MX record. The use of special DNS names has significant benefits and detriments. Some of these are explored in . One use that has perhaps not been noticed is that the underscore construct substantially changes possible concerns for scaling effects. For example, different uses for the same RR, such as the free-form TXT record, become manageable when those are defined to be within different, scoped leaf nodes. This note disusses this enhancement, provides an explicit definition of it, and establishes an IANA registry for the reserved names beginning with underscore.

This procedure is modeled after that specified in The author of a new DHCP option will follow these steps to obtain approval for the option and publication of the specification of the option as an RFC: The author devises the new option. The author documents the new option as an Internet Draft, choosing a node name that has not yet been registered. The author submits the Internet Draft for publication as an RFC, either as an independent submission or as an IETF-approved document. The specification of the new option is reviewed for publication by the appropriate bodies. At the time of publication as an RFC, IANA formally lists the node name.

This memo raises no security issues

IANA is requested to establish the DNS Underscore Name Registry, for DNS node names that begin with the underscore character and have been specified in any published RFC.

Initial entries in the registry comprise: rfc2782 _ rfc2782 ]]>

In the case of RFC2782, the set of <service> names is defined in terms of other IANA tables, namely any table with symbolic names. Even more problematic is that the set of <proto> names is not explicitly defined, except in vague terms. This makes it essentially impossible to guarantee that a new underscore name is unambiguous!

&RFC2821; &RFC0974; &RFC2782; &RFC2489; &iabdns;

Thanks go to Tony Hansen for diligent review.