DNS Attrleaf Changes: Fixing
Specifications with Underscored Node Name UseBrandenburg InternetWorking675 Spruce Dr.SunnyvaleCA94086USA+1.408.246.8253dcrocker@bbiw.nethttp://bbiw.net/dnsopDNSDomain Name System>Original uses of an underscore character as a domain node name
prefix, which creates a space for constrained interpretation of
resource records, were specified without the benefit of an IANA
registry. This produced an entirely uncoordinated set of
name-creation activities, all drawing from the same namespace. A
registry now has been defined. However the existing specifications
that use underscore naming need to be modified, to be in line with
the new registry. This document specifies those changes. The changes
preserve existing software and operational practice, while adapting
the specifications for those practices to the newer underscore
registry model.Original uses of an underscore character as a domain node name prefix, which creates a space for
constrained interpretation of resource records, were specified
without the benefit of an registry. This
produced an entirely uncoordinated set of name-creation activities,
all drawing from the same namespace. A registry has been now
defined, and that document discusses the background for underscored
domain name use .The basic model for underscored name registration, as specified in
, is to have each registry entry be
unique in terms of the combination of a resource record type and a
'global' (highest-level) underscored name; that is, the node name
beginning with an underscore, which is the closest to the DNS
root.The existing uses of underscored naming have specifications that do
not reflect the existence of this integrated registry. For the new
reader or the new editor of one of those documents, there is
currently nothing signaling that the underscore name(s) defined in
the document are now processed through an IANA registry. This
document remedies that, by marking such a published document with an
update, indicating the nature of the change. Further, the documents that define the SRV and URI DNS resource
records provide a meta-template for underscored name assignments,
partially based on separate registries . For
the portion that selects the global (highest-level) underscored
name, this perpetuates uncoordinated assignment activities by
separate technical specifications, out of the same name space. This
document remedies that by providing detail for revisions to the SRV
and URI specifications, to bring their use in line with the single,
integrated global underscore registry. The result of these changes preserves existing software and
operations practices, while adapting the technical specifications to
the newer underscore registry model.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in .The use of underscored node names is specific to each RRTYPE that is
being scoped. Each name defines a place, but does not define the
rules for what appears underneath that place, either as additional
underscored naming or as a leaf node with resource records. Details
for those rules are provided by specifications for individual
RRTYPEs. The sections below describe the way that existing
underscore labels are used with the RRTYPEs that they name.This section provides a generic approach for changes to existing
specifications that define straightforward use of underscored
node names, when scoping the use of a
TXT RRset. The approach provides the
information needed for adapting such specifications to the use of
the IANA DNS Underscore Global Scoped
Entry Registry. Hence the approach is meant both as an
update to these existing specifications, and as guidance for
changes when those documents are revised.For any document that specifies the use of a
TXT RRset under one or more
underscored names, that 'global' name is expected to be
registered in the IANA DNS Underscore
Global Scoped Entry Registry. An effort has been made
to locate existing drafts that do this, register the global
underscored names, and list them in this document.If a public specification that defines use of a
TXT calls for the use of an
underscore-prefixed domain name, the global underscored name --
the one closest to the root -- MUST be entered into this
registry, if it is not already registered. Here is a template of suggested text for this to appear in the
IANA Considerations section of the specification:Perplease add the following entry to the DNS
Underscore Global Scoped Entry Registry:RR Type_NODE NAME REFERENCETXT_{DNS node name} {citation for the document making the addition.} Specification for the SRV resource
record provides a template for use of underscored node names. The
global name is characterised as referencing the 'protocol' that
is associated with SRV RRset usage. This section provides a generic approach for changes to existing
specifications that define the use of an
SRV RRset. The approach provides the
information needed for adapting such specifications to the use of
the IANA DNS Underscore Global Scoped
Entry Registry. Hence the approach is meant both as an
update to these existing specifications, and as guidance for
changes when those documents are revised.For any document that specifies the use of an
SRV RRset, the global ('protocol')
underscored name is expected to be registered in the IANA DNS Underscore Global Scoped Entry
Registry. An effort has been made to locate existing
drafts that do this, register the global underscored names, and
list them in this document.If a public specification that defines use of a
SRV calls for the use of an
underscore-prefixed domain name, the global underscored name --
the one closest to the root -- MUST be entered into this
registry, if it is not already registered. Here is a template of suggested text for this to appear in the
IANA Considerations section of the specification:Perplease add the following entry to the DNS
Underscore Global Scoped Entry Registry:RR Type_NODE NAME REFERENCESRV_{DNS 'protocol' node name} {citation for the document making the addition.}Specification for the URI resource
record provides a template for use of underscored node names. The
global name is characterised as naming the 'protocol' that is
associated with URI RR usage or by
reversing an Enumservice sequence .This section provides a generic approach for changes to existing
specifications that define use of a
URI RRset. The approach provides the
information needed for adapting such specifications to the use of
the IANA DNS Underscore Global Scoped
Entry Registry. Hence the approach is meant both as an
update to these existing specifications, and as guidance for
changes when those documents are revised.For any document that specifies the use of a
URI RRset, the global ('protocol' or
highest-level enumservice) underscored name is expected to be
registered in the IANA DNS Underscore
Global Scoped Entry Registry. An effort has been made
to locate existing drafts that do this and register the
associated 'protocol' names. If a public specification that defines use of a
URI calls for the use of an
underscore-prefixed domain name, the global underscored name --
the one closest to the root -- MUST be entered into this
registry, if it is not already registered. Here is a template of suggested text for this to appear in the
IANA Considerations section of the specification:Perplease add the following entry to the DNS
Underscore Global Scoped Entry Registry:RR Type_NODE NAME REFERENCEURI_{DNS 'protocol' or Enumservice node name} {citation for the document making the addition.}The specification for a domain name under, which an SRV resource record appears, provides
a template for use of underscored node names. The global
underscored name, is characterised as indicating the 'protocol'
that is associated with SRV RR usage. The text of that existing specification is hereby updated from:And is to be updated to the new text:The format of the SRV RRHere is the format of the SRV RR, whose DNS type code
is 33:_Service._Proto.Name TTL Class SRV
Priority Weight Port Target...ProtoThe symbolic name of the desired protocol, with
an underscore (_) prepended to prevent
collisions with DNS labels that occur in
nature. _TCP and _UDP are at present the most
useful values for this field. The Proto is case
insensitive.The SRV RRset protocol (global) underscored
name SHOULD be registered in the IANA DNS Underscore Global
Scoped Entry Registry.Specification for the domain name under which a URI resource record occurs is similar
to that for the SRV resource
record, although the text refers only to 'service' name, rather
than distinguishing 'service' from 'protocol'. Further, the URI
RR specification permits alternative underscored naming schemes: One matches what is used for
SRV, with the global
underscored name called "protocol'. The other is based on a reversing of an Enumservice sequence.The text of the existing specification is hereby updated from:And is to be updated to the new text:4.1. Owner Name, Class, and TypeThe URI owner name is subject to special
conventions.As for the SRV RRset,
the URI RRset global (highest-level) underscored name
SHOULD be registered in the IANA DNS Underscore Global Scoped
Entry Registry.Just like the SRV RRset, the URI RRset has service
information encoded in its owner name. In order to
encode the service for a specific owner name, one
uses service parameters. Valid service parameters
are: Those registered by IANA in the "Service Name and Transport
Protocol Port Number Registry" The
underscore is prepended to the service
parameters to avoid collisions with DNS labels
that occur in nature, and the order is reversed
to make it possible to do delegations, if
needed, to different zones (and therefore
providers of DNS).Those listed in "Enumservice Registrations. The
Enumservice Registration parameters are
reversed (i.e., subtype(s) before type),
prepended with an underscore (_), and prepended
to the owner name in separate labels. The
highest-level (global) underscored Enumservice
name becomes the global Attrleaf name to
register. For example, suppose we are looking for the URI for a
service with ENUM Service Parameter "A:B:C" for host
example.com. Then we would query for
(QNAME,QTYPE)=("_C._B._A.example.com","URI").As another example, suppose we are looking for the
URI for a service with Service Name "A" and Transport
Protocol "B" for host example.com. Then we would
query for
(QNAME,QTYPE)=("_A._B.example.com","URI").Although this document makes reference to IANA registries, it
introduces no new IANA registries or procedures.This memo raises no security issues.DNS Scoped Data Through 'Underscore'
Naming of Attribute LeavesBrandenburg InternetWorking675 Spruce Dr.SunnyvaleCA94086USA+1.408.246.8253dcrocker@bbiw.nethttp://bbiw.net/DNSDomain Name System> Formally, any DNS "RR" may occur for any domain name.
However some services have defined an operational
convention that applies to DNS leaf nodes that are under a
DNS branch that has one or more reserved node names that
begin 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.IANA Registration of Enumservices: Guide, Template, and
IANA ConsiderationsInternet Assigned Numbers Authority (IANA) Procedures for
the Management of the Service Name and Transport Protocol Port
Number RegistryThe Uniform Resource Identifier (URI) DNS Resource
RecordNetnodISOCDomain
names - implementation and specificationUSC/ISI4676 Admiralty WayMarina del ReyCA90291US+1 213 822 1511Key words for use in RFCs to
Indicate Requirement LevelsHarvard University1350 Mass. Ave.CambridgeMA 02138- +1 617 495 3864sob@harvard.edu
General
keyword In many standards track documents several words are used
to signify the requirements in the specification. These
words are often capitalized. This document defines these
words as they should be interpreted in IETF documents.
Authors who follow these guidelines should incorporate this
phrase near the beginning of their document: The key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document
are to be interpreted as described in RFC 2119. Note that the force of these words is modified by the
requirement level of the document in which they are used.
A DNS RR for specifying the location
of services (DNS SRV)Troll TechWaldemar Thranes gate 98BOsloN-0175NO+47 22 806390+47 22 806380arnt@troll.noInternet Software Consortium950 Charter StreetRedwood CityCA94063US+1 650 779 7001Microsoft CorporationOne Microsoft WayRedmondWA98052USlevone@microsoft.comThis 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
ServersThe 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
ApplicationUsing Extensible Markup Language-Remote Procedure Calling
(XML-RPC) in Blocks Extensible Exchange Protocol (BEEP) IBMThe TUNNEL ProfileAddress Resolution for Instant Messaging and
PresenceNeustarRemote Service Discovery in the Service Location Protocol
(SLP) via DNS SRVColumbia UniversityColumbia UniversitySun MicrosystemsIBMIBMMessage Tracking Query ProtocolDomain-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-ISIMITMITMITUsing the Simple Object Access Protocol (SOAP) in Blocks
Extensible Exchange Protocol (BEEP)Clipcode.comDover Beach Consulting, Inc.Internet X.509 Public Key Infrastructure: Repository
Locator ServiceEntrust Inc.VeriSign Inc.Internet X.509 Public Key Infrastructure Operational
Protocols: Certificate Store Access via HTTPUniversity of AucklandSender Policy Framework (SPF) for Authorizing Use of
Domains in E-Mail, Version 1DomainKeys Identified Mail (DKIM) Author Domain Signing
Practices (ADSP)Sendmail, Inc.Cisco Systems, Inc.Yahoo! Inc.Taughannock NetworksDomainKeys Identified Mail (DKIM) SignaturesDomainKeys 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.PlantronicsEstacado SystemsMobile IPv6 Bootstrapping in Split ScenarioQualcommDoCoMo Labs USAAzaire NetworksA Uniform Resource Name (URN) Namespace for the Digital
Video Broadcasting Project (DVB)Micronas GmbHDVB ProjectSession Traversal Utilities for NAT (STUN)CiscoCiscoCiscoControl And Provisioning of Wireless Access Points
(CAPWAP) Protocol SpecificationCisco Systems, Inc.Research In MotionAruba NetworksVouch By ReferenceDomain Assurance CouncilDomain Assurance CouncilAlt-N TechnologiesMobile IPv6 Support for Dual Stack Hosts and
RoutersElevate TechnologiesLocating IEEE 802.21 Mobility Services Using DNSTraversal Using Relays around NAT (TURN): Relay Extensions
to Session Traversal Utilities for NAT (STUN)Alcatel-Lucentjdrosen.netNAT Behavior Discovery Using Session Traversal Utilities
for NAT (STUN)SkypeSkypeA Protocol for Remotely Managing Sieve ScriptsIsode LimitedBeThereBeSquare, Inc.NS SRV Resource Records for AFSStanford UniversityTraversal Using Relays around NAT (TURN) Resolution
MechanismSession Initiation Protocol (SIP) User Agent
ConfigurationLinden Research, Inc.Siemens Enterprise CommunicationsExtensible Messaging and Presence Protocol (XMPP):
CoreCiscoUse of SRV Records for Locating Email Submission/Access
ServicesApple Inc.Diameter Base Protocol Telcordia TechnologiesEricsson ResearchNokia Research CenterNetwork ZenDomain-based Message Authentication, Reporting, and
Conformance (DMARC)Protocol RegistriesThanks go to Bill Fenner, Dick Franks, Tony Hansen, Peter Koch, Olaf
Kolkman, and Andrew Sullivan for diligent review of the (much)
earlier drafts. For the later enhancements, thanks to: Tim Wicinski,
John Levine, Bob Harold, Joel Jaeggli, Ondřej Surý 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.