DNS Scoped Data Through '_Underscore' Attribute Leaves
Brandenburg InternetWorking
675 Spruce Dr.
Sunnyvale CA 94086
USA
+1.408.246.8253
dcrocker@bbiw.net
http://bbiw.net/
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 DNS records that are
associated with the parent domain. This specification explores the nature of this DNS
usage and defines the "underscore names" registry with IANA.
The core 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. Data semantics have been limited to the
specification of particular resource records, on the expectation that new ones would be
added as needed.
As an alternative to defining new RRs, some DNS service enhancements have specified a
restricted scope for the occurrence of particular resource records. That scope is a leaf
node, within which the uses of specific resource records can be formally defined and
constrained. The leaf has a distinguished naming convention: It uses a reserved DNS node
name that begins with an underscore ("_"). Because a "host" domain
name is not allowed to use the underscore character, this distinguishes the name from
all legal host names. Effectively, this convention creates a
space for attributes that are associated with the parent domain, one level up.
An established example is the SRV record which generalizes
concepts long-used for email routing by the MX record . The use of special DNS names has significant benefits and
detriments. Some of these are explored in .
The terms "resolution context" and "scoping rules" have
been suggested, in place of "semantic scope". In order to avoid concern for
matters of semantics, this specification uses the term "scoping rules", to create
a focus on the mechanics being defined, rather than nuances of interpretation for
the mechanism.
The scoping feature is particularly useful when generalized resource records are used --
notably TXT and SRV. It provides efficient separation of one use of them from another.
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; 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.
This specification discusses the underscore "attribute" enhancement, provides an
explicit definition of it, and establishes an IANA registry for the reserved names that
begin with underscore. It updates the many existing specifications that have defined
underscore names, in order to aggregate the references to a single IANA table.
Discussion about this draft is directed to the
apps-discuss@ietf.org mailing
list.
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 and SRV records are the notable examples.
Used freely, some of these approaches 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, uses an underscore-based name, at a defined
place in the DNS tree, so as to constrain to particular uses for particular RRs farther
down the branch using that name. This means that a direct lookup produces only the
desired records, at no greater cost than a typical DNS lookup.
In the case of TXT records, different uses have developed largely without coordination.
One side-effect is that there is no consistently distinguishable internal syntax for the
record; even the inefficiencies of internal inspection might not provide a reliable
means of distinguishing among the different uses. Underscore-based names therefore
define an administrative way of separating TXT records that might have different uses,
but otherwise would have no syntactic markers for distinguishing among them.
In the case of the SRV RR distinguishing among different types of use was part of the
design. The SRV specification serves as a template, defining an
RR that might only be used for specific applications when there is an additional
specification. The template definition includes reference to tables of names from which
underscore-names should be drawn. The set of <service> names is defined in terms
of other IANA tables, namely any table with symbolic names. The other SRV naming field
is <proto>, although its pool of names is not explicitly defined.
This specification creates a registry for DNS nodes names that begin with an underscore
and are used to define scope of use for specific resource records (RR). A given name
defines a specific, constrained context for the use of such records. Within this scope,
use of other resource records that are not specified is permitted. The purpose of the
Underscore registry is to avoid collisions resulting from the use of the same
underscore-based name, for different applications.
Structurally, the registry is defined as a single, flat table of names that begin with
underscore. In some cases, such as for SRV, an underscore name might be multi-part, as a
sequence of underscore names. Semantically, this is a hierarchical model and it is
theoretically reasonable to allow re-use of an underscore name in different underscore
contexts. That is, a subordinate name is meaningful only within the scope of the first
(parent) underscore name. As such, they can be ignored by this global Underscore
registry. That is, the registry is for the definition of highest-level underscore node
name used.
NAME
_service1
._protoB._service2
_protoB._service3
_protoC._service3
_useX._protoD._service4
_protoE._region._authority
Only the right-most names are registered in the IANA table. Definition and registration
of the subordinate names is the responsibility of the specification that creates the
highest-level (right-most) registry entry.
A registry entry contains:
Specifies a textual name for a scoped portion of the DNS.
The name will usually be taken from the specification cited in the "Purpose"
column and is intended for use in discussions about the entry.
Specifies a single underscore name that defines a
name reservation; this name is the "global" entry name for the scoped
resource records that are associated with that name.
Specifies any restrictions on use of the name.
Lists the RRs that are defined for use within this
scope.
Lists specifications that define the records and their
use under this Name.
Specifies the particular purpose/use for specific
RR(s), defined for use within the scope of the registered underscore
name.
Per , IANA is requested to establish a DNS Underscore Name
Registry, for DNS node names that begin with the underscore character (_) and have been
specified in any published RFC, or are documented by a specification published by
another standards organization. The contents of each entry are defined in .
Initial entriess in the registry are:
{ Enhancement of this table to include all underscore name reservations in effect
at the time this document is published is left as an exercise to the readers... /d
}
NAME
LABEL
RR
REFERENCE
PURPOSE
SRV
_srv
SRV
SRV template -- pro forma entry, not directly usable
SRV TCP
_tcp
SRV
Use of SRV for a TCP service
SRV UDP
_udp
SRV
Use of SRV for a UDB service
LDAP
_ldap
SRV
LDAP server
SIP
_sip
NAPTR
Locating SIP Servers and UA configuration
SPF
_spf
TXT
Authorized IP addresses for sending mail
DKIM
_domainkey
TXT
Public key for verifying DKIM signature.
PKI LDAP
_PKIXREP
SRV
PKI Repository
VBR
_vouch
TXT
Vouch-by-refererence domain assertion
DDDS
--???!--
SRV
Mapping DDDS query to DNS records
SOAP BEEP
_soap-beep
SRV
SOAP over BEEP lookup, when no port specified
XMLRPC BEEP
_xmlrpc-beep
SRV
Resolve url for XML-RPC using BEEP
Diameter
_diameter
SRV
Diameter rendezvous
Tunnel
_tunnel
SRV
Finding the appropriate address for tunneling into a particular domain
SLP
_slpda
SRV
Discovering desired services in given DNS domains
IM
_im
SRV
Instant Messaging address resolution
Pres
_pres
SRV
Presence address resolution
Msg Track
_mtqp
SRV
Assist in determining the path that a particular message has taken through a
messaging system
XMPP Client
_xmpp-client
SRV
XMPP client lookup of server
XMPP Server
_xmpp-server
SRV
XMPP server-server lookup
DDDS SRV
_???
SRV (and NAPTR?)
Map domain name, application service name, and application protocol dynamically to
target server and port
Kerberos
_kerberos
SRV
purpose
PKI
_pkixrep
SRV
Enables certificate-using systems to locate PKI repositories
Certificates
_certificates
SRV
Obtain certificates and certificate revocation lists (CRLs) from PKI repositories
PGP Key Store
pgpkeys
SRV
Obtain certificates and certificate revocation lists (CRLs) from PKI repositories
MSRP Relay Locator
_msrp
SRV
purpose
Mobile IPv6 Bootstrap
_mip6
SRV
Bootstrap Mobile IPv6 Home Agent information from non-topological information
Digital Video Broadcasting
_dvbservdsc
SRV
Discover non-default DVB entry points addresses
CAPWAP AC
_capwap-control
rrs
Discover the CAPWAP AC address(es)
IM
_im
SRV
For resolving Instant Messaging and Presence services with SIP
Presence
_pres
SRV
For resolving Instant Messaging and Presence services with SIP
IEEE 802.21 Mobility
_mihis
NAPTR, SRV
Discovering servers that provide IEEE 802.21-defined Mobility Services
STUN Client/Server
_stun
SRV
Find a STUN server
TURN
_turn
SRV
Control the operation of a relay to bypass NAT
STUN NAT Behavior Discovery
_stun-behavior
SRV
Discover the presence and current behavior of NATs and firewalls between the STUN
client and the STUN server
Sieve Management
_sieve
SRV
Manage Sieve scripts on a remote server
AFS VLDB
_afs3-vlserver
SRV
Locate services for the AFS distributed file system
AFS PTS
_afs3-prserver
SRV
Locate services for the AFS distributed file system
Mail MSA Submission
_submission
SRV
Locate email services
IMAP
_imap
SRV
Locate email services
POP
_pop3
SRV
Locate email services
POP TLS
_pop3s
SRV
Locate email services
This section needs to contained details specification of the updates to existing
underscore "registries", in order to have those specifcations point to this new
registry.
Numerous specifications have defined their own, independent registries for use of
underscore names. It is likely that adoption of the proposed, integrated registry should
render these piecemeal registries obsolete
Registries that are candidates for replacement include:
Instant Messaging SRV Protocol Label Registry
Public Key Infrastructure using X.509 (PKIX) Parameters
Presence SRV Protocol Label Registry
This memo raises no security issues.
Guidelines for Writing an IANA Considerations Section in RFCs
IBM
Maxware
Domain names - implementation
and specification
USC/ISI
4676 Admiralty Way
Marina del Rey
CA
90291
US
+1 213 822 1511
Simple Mail Transfer Protocol
This document is a self-contained specification of the basic protocol for the
Internet electronic mail transport. [STANDARDS-TRACK]
Mail routing and the domain system
Bolt Baranek and Newman (BBN) Laboratories Inc., CSNET
CIC
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.
Session Initiation Protocol (SIP): Locating SIP Servers
The Session Initiation Protocol (SIP) uses DNS procedures to allow a client to
resolve a SIP Uniform Resource Identifier (URI) into the IP address, port, and
transport protocol of the next hop to contact. It also uses DNS to allow a
server to send a response to a backup client if the primary client has failed.
This document describes those DNS procedures in detail. [STANDARDS-TRACK]
Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource
Identifiers (URI) Resolution Application
Using Extensible Markup Language-Remote Procedure Calling (XML-RPC) in Blocks
Extensible Exchange Protocol (BEEP)
IBM
Diameter Base Protocol
Airespace, Inc.
Nokia
Sun Microsystems, Inc.
Cisco Systems, Inc
Ericsson
The TUNNEL Profile
Address Resolution for Instant Messaging and Presence
Neustar
Remote Service Discovery in the Service Location Protocol (SLP) via DNS
SRV
Columbia University
Columbia University
Sun Microsystems
IBM
IBM
Message Tracking Query Protocol
Domain-Based Application Service Location Using SRV RRs and the Dynamic
Delegation Discovery Service (DDDS)
VeriSign, Inc.
VeriSign, Inc.
The Kerberos Network Authentication Service (V5)
USC-ISI
MIT
MIT
MIT
Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange
Protocol (BEEP)
Clipcode.com
Dover Beach Consulting, Inc.
Internet X.509 Public Key Infrastructure: Repository Locator Service
Entrust Inc.
VeriSign Inc.
Internet X.509 Public Key Infrastructure Operational Protocols: Certificate
Store Access via HTTP
University of Auckland
Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail,
Version 1
E-mail on the Internet can be forged in a number of ways. In particular,
existing protocols place no restriction on what a sending host can use as the
reverse-path of a message or the domain given on the SMTP HELO/EHLO commands.
This document describes version 1 of the ender Policy Framework (SPF) protocol,
whereby a domain may explicitly authorize the hosts that are allowed to use its
domain name, and a receiving host may check such authorization. This memo
defines an Experimental Protocol for the Internet community.
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]
Relay Extensions for the Message Session Relay Protocol (MSRP)
Cisco Systems, Inc.
Plantronics
Estacado Systems
Mobile IPv6 Bootstrapping in Split Scenario
Qualcomm
DoCoMo Labs USA
Azaire Networks
A Uniform Resource Name (URN) Namespace for the Digital Video Broadcasting
Project (DVB)
Micronas GmbH
DVB Project
Session Traversal Utilities for NAT (STUN)
Cisco
Cisco
Cisco
IAB
IAB
Control And Provisioning of Wireless Access Points (CAPWAP) Protocol
Specification
Cisco Systems, Inc.
Research In Motion
Aruba Networks
Internet Assigned Numbers Authority (IANA) Registration of Instant Messaging
and Presence DNS SRV RRs for the Session Initiation Protocol (SIP)
Ericsson
Vouch By Reference
Domain Assurance Council
Domain Assurance Council
Alt-N Technologies
Mobile IPv6 Support for Dual Stack Hosts and Routers
Elevate Technologies
Locating IEEE 802.21 Mobility Services Using DNS
Traversal Using Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)
Alcatel-Lucent
jdrosen.net
NAT Behavior Discovery Using Session Traversal Utilities for NAT
(STUN)
Skype
Skype
A Protocol for Remotely Managing Sieve Scripts
Isode Limited
BeThereBeSquare, Inc.
NS SRV Resource Records for AFS
Stanford University
Traversal Using Relays around NAT (TURN) Resolution Mechanism
Session Initiation Protocol (SIP) User Agent Configuration
Linden Research, Inc.
Siemens Enterprise Communications
Extensible Messaging and Presence Protocol (XMPP): Core
Cisco
Use of SRV Records for Locating Email Submission/Access Services
Apple Inc.
Thanks go to Bill Fenner, Tony Hansen, Peter Koch, Olaf Kolkman, and Andrew Sullivan for
diligent review of the earlier drafts. Special thanks to Ray Bellis for nearly 10 years
of persistent encouragement to pursue this document.