DNS Scoped Data Through '_Underscore' Naming
of Attribute Leaves
Brandenburg InternetWorking
675 Spruce Dr.
Sunnyvale
CA
94086
USA
+1.408.246.8253
dcrocker@bbiw.net
http://bbiw.net/
dnsop
DNS
Domain Name System>
Formally, any DNS resource record may occur for any domain name.
However some services have defined an operational convention, which
applies to DNS leaf nodes that are under a DNS branch having one or
more reserved node names, each beginning with an underscore. The
underscore naming construct defines a semantic scope for DNS records
that are associated with the parent domain, above the underscored
branch. This specification explores the nature of this DNS usage and
defines the "DNS Global Underscore Scoped Entry Registry" with IANA.
The purpose of the Underscore registry is to avoid collisions
resulting from the use of the same underscore-based name, for
different services.
The core Domain Name System (DNS) technical specifications assign no
semantics to domain names or their parts, and no constraints upon
which resource records (RRs) are permitted to be associated with
particular names. 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 records, on the expectation that new ones would be added as
needed. Unfortunately, the addition of new resource records has
proved extremely challenging, over the life of the DNS, with
significant adoption and use barriers.
As an alternative to defining new RRs, some DNS service
enhancements call for using an existing resource record, but
specify a restricted scope for its occurrence. That scope is a
leaf node, within which the uses of specific resource records can
be formally defined and constrained. The leaf occurs in a branch
having a distinguished naming convention: At the top of the
branch -- beneath the parent domain name to which the scope
applies -- one or more reserved DNS node names begin with an
underscore ("_"). Because the DNS rules for a
"host" (host name) are not allowed to use the
underscore character, this distinguishes the underscore name from
all legal host names . Effectively, this
convention for leaf node naming creates a space for the listing
of 'attributes' -- in the form of resource records -- that are
associated with the parent domain, above the underscore
sub-branch.
The scoping feature is particularly useful when generalized
resource records are used -- notably
TXT, SRV,
and URI
,,, . It provides
efficient separation of one use of them from others. Absent this
separation, an undifferentiated mass of these
RRs is returned to the DNS client,
which then must parse through the internals of the records in the
hope of finding ones that are relevant. Worse, in some cases the
results are ambiguous because the records do not adequately
self-identify. With underscore-based scoping, only the relevant
RRs are returned.
A simple example is DKIM , which
uses "_domainkeys" for defining a place to hold a
TXT record containing signing
information for the parent domain.
This specification formally defines how underscore labels are
used as "attribute" enhancements for their parent domain names.
For example, domain name "_domainkey.example." acts as attribute
of parent domain name "example." To avoid collisions resulting
from the use of the same underscore-based labels for different
applications, this document establishes DNS Underscore Global
Scoped Entry IANA Registry for the highest-level reserved names
that begin with _underscore; _underscore-based names that are
farther down the hierarchy are handled within the scope of the
highest-level _underscore name.
Discussion about this draft
should be directed to the dnsop@ietf.org
mailing list.
Please remove
"Discussion Venue" paragraph prior to
publication.
Some resource records are generic and support a variety of uses.
Each additional use defines its own rules and, possibly, its own
internal syntax and node-naming conventions to distinguish among
particular types. The TXT,
SRV, and
URI records are notable examples.
Their use can scale poorly, particularly when the same
RR can be present in the same leaf
node, but with different uses.
An increasingly-popular approach, with excellent scaling
properties, place the RR under a node with an underscore-based
name, at a defined place in the DNS tree, so as to constrain the
use of particular RRs farther down
the branch with that name. This means that a direct lookup
produces only the desired records, at no greater cost than a
typical DNS lookup.
The definition of a underscore global registry, provided in this
specification, primarily attends to the top-most names used for
RRs; that is the _underscore "global" names.
A global registry for DNS nodes names that begin with an _underscore
is defined here.
The 'global' (right-most) node name that uses an _underscore
prefix MUST be entered into this registry.
The names define scope of use for specific resource records,
which are associated with the domain name that is the "parent" to
the branch defined by the _underscore naming.
A given name defines a specific, constrained context for one
or more RR records, in which use of such records MUST conform
to the defined constraints. Within this scope, other resource
records that are not specified MAY be used.
The purpose of the Underscore Global Registry is to avoid
collisions resulting from the use of the same _underscore-based
name, for different applications.
The DNS Global Underscore Registry MUST have entries that are
unique with respect to the combination of the listed resource
record and the listed, global underscore node name (RR, _Node
Name).
Structurally, the registry is defined as a single, flat table of
names that begin with _underscore. In some cases, such as for use of
an SRV record, the full scoping name
might be multi-part, as a sequence of underscore names.
Semantically, that sequence represents a hierarchical model and it
is theoretically reasonable to allow re-use of a subordinate
underscore name in different underscore context; that is, a
subordinate name is meaningful only within the scope of the first
(top-level) underscore name. Therefore they are ignored by this DNS
Underscore Global Scoped Entry Registry. This registry is for the
definition of highest-level -- ie, global -- underscore node name
used.
NAME
_service1
._protoB._service2
_protoB._service3
_protoC._service3
_useX._protoD._service4
_protoE._region._authority
Only the right-most _underscore names are registered in the IANA
Underscore Global table.
Definition and registration of the subordinate underscore node
names is the responsibility of the specification that creates
the highest-level (right-most) global registry entry.
That is, if a scheme using a global underscore node name also
has one or more subordinate levels of underscore node naming,
the namespaces from which names for those lower levels is
chosen is controlled by the parent underscore node name. Each
globally-registered underscore name owns a distinct,
subordinate name space.
A registry entry contains:
Lists the RR that are defined for use
within this scope.
Specifies a single _underscore
name that defines a reserved name; this name is the
"global" entry name for the scoped resource records that
are associated with that name
Lists specification that define the
records and their use under this Name. The organization
producing the specification retains control over the
registry entry for the _Node Name.
Each RR that is to be used MUST have a separate registry
entry.
Per , IANA is requested to establish the:
DNS Underscore Global Scoped Entry Registry
This section describes actions requested of IANA. The
guidance in is used.
The DNS Global Underscore Scoped Entry Registry is for DNS node
names that begin with the underscore character (_) and are the
first occurrence of any names in a domain name sequence having
that form; that is they are the "top" of a DNS branch and are
shown as the right-most _underscore name -- under a "parent"
domain name.
This registry is to operate under the IANA rules for
"Expert Review" registration; see .
The contents of each entry in the Global registry are
defined in .
The table is to be maintained with entries sorted by the
first column (RR) 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
Initial entries in the registry are:
RR
_NODE NAME
REFERENCE
OPENPGPKEY
_openpgpkey
SMIMEA
_smimecert
SRV
_dccp
SRV
_sctp
SRV
_tcp
SRV
_udp
TLSA
_sctp
TLSA
_tcp
TLSA
_udp
TXT
_acme-challenge
TXT
_domainkey
TXT
_dmarc
TXT
_spf
TXT
_vouch
URI
_???
This section provides guidance for expert review of registration
requests in the of DNS Underscore Global Scoped Entry
Registry.
This review is solely to determine adequacy of a requested
entry in this Registry, and 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 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 _underscore name, under which the
listed resource record is used, and the resource record, 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.
This memo raises no security issues.
Guidelines for Writing an IANA Considerations Section in
RFCs
PTI
Huawei Technologies
IBM Corporation
A DNS RR for specifying the location
of services (DNS SRV)
Troll Tech
Waldemar Thranes gate 98B
Oslo
N-0175
NO
+47 22 806390
+47 22 806380
arnt@troll.no
Internet Software Consortium
950 Charter Street
Redwood City
CA
94063
US
+1 650 779 7001
Microsoft Corporation
One Microsoft Way
Redmond
WA
98052
US
levone@microsoft.com
This document describes a DNS
RR which specifies the location
of the server(s) for a specific protocol and domain.
Vouch By Reference
Domain Assurance Council
Domain Assurance Council
Alt-N Technologies
DomainKeys Identified Mail (DKIM) Signatures
DomainKeys Identified Mail (DKIM) defines a domain-level
authentication framework for email using public-key
cryptography and key server technology to permit
verification of the source and contents of messages by
either Mail Transfer Agents (MTAs) or Mail User Agents
(MUAs). The ultimate goal of this framework is to permit a
signing domain to assert responsibility for a message, thus
protecting message signer identity and the integrity of the
messages they convey while retaining the functionality of
Internet email as it is known today. Protection of email
identity may assist in the global control of "spam" and
"phishing". [STANDARDS TRACK]
The DNS-Based Authentication of Named Entities (DANE)
Transport Layer Security (TLS) Protocol: TLSA
Sender Policy Framework (SPF) for Authorizing Use of
Domains in E-Mail, Version 1
Domain-based Message Authentication, Reporting, and
Conformance (DMARC)
Using Secure DNS to Associate Certificates with Domain
Names for S/MIME
Automatic Certificate Management Environment
(ACME)
Domain
names - implementation and specification
USC/ISI
4676 Admiralty Way
Marina del Rey
CA
90291
US
+1 213 822 1511
nternet Assigned Numbers Authority (IANA) Procedures for
the Management of the Service Name and Transport Protocol Port
Number Registry
The Uniform Resource Identifier (URI) DNS Resource
Record
Netnod
ISOC
Guidelines for Writing an IANA Considerations Section in
RFCs
Thanks go to Bill Fenner, Tony Hansen, Peter Koch, Olaf Kolkman, and
Andrew Sullivan for diligent review of the (much) earlier drafts.
For the later enhancements, thanks to: Stephane Bortzmeyer, Bob
Harold, John Levine, Joel Jaeggli, Petr Špaček, OndÅ™ej
Surř, Tim Wicinski, and Paul Wouters.
Special thanks to Ray Bellis for more than 12 years of persistent
encouragement to continue this effort, as well as the suggestion for
an essential simplification to the registration model.