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", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP14 when, and only when, they appear in all
capitals, as shown here.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.Documents falling into this
category include:, ,
, , , , and 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, the '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 the initial set of names added to the
registry. If a public specification defines use of a TXT RRset and calls
for the use of an underscore-prefixed domain name, here is a
template of suggested text for registering the global underscored
name -- the one closest to the root -- through 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.} Documents falling into this
category include:, ,
, , , , , , , , , , , , , , , , , , , , Specification of 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 the initial set of names added to the registry. If a public specification defines use of a SRV RRset and calls
for the use of an underscore-prefixed domain name, here is a
template of suggested text for registering the global underscored
name -- the one closest to the root -- through 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 of 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, register the global
underscored names, and list them in the initial set of names
added to the registry. If a public specification defines use of a URI RRset and calls
for the use of an underscore-prefixed domain name, here is a
template of suggested text for registering the global underscored
name -- the one closest to the root -- through 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. Text of that existing specification is changed as follows:OLD:NEW: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.Text of that existing specification is changed as follows:OLD:NEW: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")."Signaling Trust Anchor Knowledge in DNS Security Extensions
(DNSSEC)" defines a use of DNS node
names that effectively consumes all names beginning with the
string "_ta-", when using the NULL RR
in the query.Text of Section 5.1, "Query Format", of that existing
specification, is changed as follows:OLD:NEW:For example, a validating DNS resolver ...
QNAME=_ta-4444.Under the NULL RR, an entry is registered in the IANA
DNS Underscore Global
Scoped Entry Registry for all node names
beginning with
"_ta-".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
RecordNetnodISOCSignaling Trust Anchor Knowledge in DNS Security
Extensions (DNSSEC)Domain
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]Using Extensible Markup Language-Remote Procedure Calling
(XML-RPC) in Blocks Extensible Exchange Protocol (BEEP) IBMThe TUNNEL ProfileRemote 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 AucklandMobile IPv6 Bootstrapping in Split ScenarioA Mobile IPv6 node requires a Home Agent address, a home
address, and IPsec security associations with its Home
Agent before it can start utilizing Mobile IPv6 service.
RFC 3775 requires that some or all of these are statically
configured. This document defines how a Mobile IPv6 node
can bootstrap this information from non-topological
information and security credentials pre-configured on the
Mobile Node. The solution defined in this document solves
the split scenario described in the Mobile IPv6
bootstrapping problem statement in RFC 4640. The split
scenario refers to the case where the Mobile Node's
mobility service is authorized by a different service
provider than basic network access. The solution described
in this document is also generically applicable to any
bootstrapping case, since other scenarios are more specific
realizations of the split scenario. [STANDARDS-TRACK]Internet Assigned Numbers Authority (IANA) Registration of
Instant Messaging and Presence DNS SRV RRs for the Session
Initiation Protocol (SIP)This document registers with IANA two new DNS SRV protocol
labels for resolving Instant Messaging and Presence
services with SIP. [STANDARDS TRACK]Diameter Base ProtocolThe Diameter base protocol is intended to provide an
Authentication, Authorization, and Accounting (AAA)
framework for applications such as network access or IP
mobility in both local and roaming situations. This
document specifies the message format, transport, error
reporting, accounting, and security services used by all
Diameter applications. The Diameter base protocol as
defined in this document obsoletes RFC 3588 and RFC 5719,
and it must be supported by all new Diameter
implementations. [STANDARDS-TRACK]Sender 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 NetworksRelay Extensions for the Message Session Relay Protocol
(MSRP)Cisco Systems, Inc.PlantronicsEstacado SystemsA 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
MechanismExtensible Messaging and Presence Protocol (XMPP):
CoreCiscoUse of SRV Records for Locating Email Submission/Access
ServicesApple Inc.DomainKeys Identified Mail (DKIM) SignaturesDomainKeys Identified Mail (DKIM) permits a person, role,
or organization that owns the signing domain to claim some
responsibility for a message by associating the domain with
the message. This can be an author's organization, an
operational relay, or one of their agents. DKIM separates
the question of the identity of the Signer of the message
from the purported author of the message. Assertion of
responsibility is validated through a cryptographic
signature and by querying the Signer's domain directly to
retrieve the appropriate public key. Message transit from
author to recipient is through relays that typically make
no substantive change to the message content and thus
preserve the DKIM signature.This memo obsoletes RFC 4871 and RFC 5672.
[STANDARDS-TRACK]DNS-Based Service DiscoveryThis document specifies how DNS resource records are named
and structured to facilitate service discovery. Given a
type of service that a client is looking for, and a domain
in which the client is looking for that service, this
mechanism allows clients to discover a list of named
instances of that desired service, using standard DNS
queries. This mechanism is referred to as DNS-based Service
Discovery, or DNS-SD.Domain-based Message Authentication, Reporting, and
Conformance (DMARC)The DNS-Based Authentication of Named Entities (DANE)
Protocol: Updates and Operational GuidanceThis document clarifies and updates the DNS-Based
Authentication of Named Entities (DANE) TLSA specification
(RFC 6698), based on subsequent implementation experience.
It also contains guidance for implementers, operators, and
protocol developers who want to use DANE records.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key
WordsRFC 2119 specifies common key words that may be used in
protocol specifications. This document aims to reduce the
ambiguity by clarifying that only UPPERCASE usage of the
key words have the defined special meanings.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.