One document matched: draft-crocker-dns-attrleaf-04.xml
<?xml version="1.0" encoding="UTF-8"?><?rfc linefile="1:/var/tmp/CGItemp59640.xml"?>
<!-- automatically generated by xml2rfc v1.36 on 2011-03-30T07:45:31Z -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- xml2rfc-processed-entity enumuri -->
<!-- xml2rfc-processed-entity RFC2821 -->
<!-- xml2rfc-processed-entity RFC0974 -->
<!-- xml2rfc-processed-entity RFC3263 -->
<!-- xml2rfc-processed-entity RFC4408 -->
<!-- xml2rfc-processed-entity RFC2782 -->
]>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc toc="yes" ?>
<?rfc tocindent="yes" ?>
<?rfc tocdepth="2" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<rfc
category="bcp"
docName="draft-crocker-dns-attrleaf-04"
ipr="trust200902">
<front>
<title>DNS Scoped Data Through Attribute Leaves</title>
<author
fullname="Dave Crocker"
initials="D."
surname="Crocker">
<organization>Brandenburg InternetWorking</organization>
<address>
<postal>
<street>675 Spruce Dr.</street>
<city>Sunnyvale</city> <region>CA</region> <code>94086</code>
<country>USA</country>
</postal>
<phone>+1.408.246.8253</phone>
<email>dcrocker@bbiw.net</email>
<uri>http://bbiw.net/</uri>
</address>
</author>
<date
year="2011" />
<area>Operations</area>
<keyword>DNS</keyword>
<keyword>Domain Name System> </keyword>
<abstract>
<t>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 associated with the
parent domain. This note explores the nature of this DNS usage and
defines the "underscore names" registry with IANA. </t>
</abstract>
</front>
<middle>
<section
title="Introduction">
<t>The core DNS technical specifications assign no semantics to domain
names or their parts, and no constraints upon which resource records
(RRs) may 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<!-- and the conventions do not probhibit
having those services available under other name-->.
This freedom in the basic technology has permitted a wide range of
administrative and semantic policies to be used -- in parallel --
with the DNS. Data semantics have been limited to the specification
of particular resource records, on the expectation that new ones
would be added as needed. </t>
<t>Some recent service enhancements have defined define 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. This leaf has a
distinguished naming convention: It uses a reserved DNS node name
that begins with an underscore. Because host names are not allowed
to use the underscore character, this distinguishes the name from
all legal host name. Effectively, this convention creates a space
for attributes that are associated with the parent domain, one level
up.</t>
<t>An established example is the SRV record <xref
target="RFC2782" /> which generalizes concepts long-used for
email routing by the MX record <xref
target="RFC0974" /><xref
target="RFC2821" />. The use of special DNS names has significant
benefits and detriments. Some of these are explored in <xref
target="RFC5507" />.<list
style="hanging">
<t
hangText="[Comment]: ">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.</t>
</list>
</t>
<t>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 are returned to the client
which then must parse through the internals of the records in the
hope of finding ones that are relevant. With underscore-based
scoping, only the relevant RRs are returns.</t>
<t>This specification discusses this enhancement, provides an explicit
definition of it, and establishes an IANA registry for the reserved
names that begin with underscore. <list
style="hanging">
<t
hangText="Discussion Venue: ">Discussion about this draft is
directed to the <eref
target="mailto:dnsop@lists.uoregon.edu">dnsop@lists.uoregon.edu</eref>mailing
list of the <eref
target="http://ietf.org/html.charters/dnsop-charter.html">IETF
DNSOP Working Group</eref>.</t>
</list>
</t>
</section>
<section
title="Scaling Benefits and TXT and SRV Resource Records">
<t>Some resource records have a generic form, 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 concern
for this. 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 to a define place in the
DNS that is constrained to particular uses for particular RRs. This
means that a direct lookup produces only the desired records, at no
greater cost than a typical lookup.</t>
<t> In the case of TXT records, use for different scoping rules has
developed organically and largely without coordination. One
side-effect of this is no consistently distinguishable internal
syntax for the records; even internal inspection might not be a
reliable means of distinguishing among them. Underscore-based names
therefore provide an administrative way of separating TXT records
that might have different uses, but otherwise would have no
syntactic markers for distinguishing among them. </t>
<t>In the case of the SRV RR this method of distinguishing among uses
was part of the design. <xref
target="RFC2782" /> In reality, the SRV specification defines an
RR that may only be used for specific applications when there is an
additional specification. So the SRV specification is best thought
of as a template for future specifications. The template definition
includes reference to tables of names from which underscore-names
should be drawn. So, 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.</t>
</section>
<section
anchor="underfun"
title="Underscore DNS
Registry Function">
<t>This specification defines a registry for DNS nodes names, used to
specify scope of use for specific resource records (RR). That is, a
given names defines a specific, constrained context for the use of
such records. This does not constrain the use of other resource
records that are not specified. The purpose of the registries is to
avoid collisions resulting from the use of the same underscore name,
for different applications. </t>
<t>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 names might have further constraints, such as being valid
only "under" some other underscore name. Semantically, this is a
hierarchical model, thereby making a flat registry unexpected.</t>
<t>The registry requires such hierarchies to be registered as a
combinatorial case analysis set, with each entry being a full
sequence of underscore names. Given a naming scheme that is actually
structured, this flat design is inelegant. However it has the
benefit of being extremely simple, with the added advantage of being
easier for readers to understand, as long as these cases are small
and few.</t>
<texttable
title="Example of Underscore Names">
<ttcol
align="left">NAME</ttcol>
<c>_protoA</c>
<c>_service1._protoB</c>
<c>_service2._protoC</c>
<c>_service2._protoC</c>
<c>_service3._protoD._useX</c>
<c>_protoE._region._authority</c>
</texttable>
<t>The reasons for choosing a simplified registry design are: <list
style="symbols">
<t>the belief that listing multi-level schemes as complete
combinations will be simpler than formulating sub-tables,
simples, and</t>
<t>the view that requiring readers to parse through a possible
hierarchy of multiple registries -- one per level -- will
encourage errors.</t>
</list>
</t>
<t />
</section>
<section
title="DNS Underscore Registry Definition">
<t>A registry entry MUST contain: <list>
<t>
<list
style="hanging">
<t
hangText="Name: ">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.</t>
<t
hangText="DNS Label(s): ">Specifies a sequence of one
or more underscore names that define a single name
reservation. </t>
<t
hangText="Constraints: ">Specifies any restrictions on
use of the name.</t>
<t
hangText="RR(s): ">Lists the RRs that are defined for
use within this scope.</t>
<t
hangText="References">Lists specifications that define
the records and their use under this Name. </t>
<t
hangText="Purpose: ">Specifies the particular
purpose/use for specific RR(s), defined for use within
the scope of the registered underscore name.</t>
</list>
</t>
</list>
</t>
</section>
<section
title="IANA Considerations">
<t> 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 <xref
target="underfun" />.</t>
<texttable
align="left"
anchor="underscope"
title="DNS Underscore SCOPE Name Registry
(with initial values)">
<ttcol>NAME</ttcol>
<ttcol>DNS LABEL</ttcol>
<ttcol>CONSTRAINTS</ttcol>
<ttcol>RR(s)</ttcol>
<ttcol>REFERENCES</ttcol>
<ttcol>PURPOSE</ttcol>
<!---->
<c>SIP TCP</c>
<c>_sip._tcp</c>
<c />
<c>NAPTR</c>
<c><xref
target="RFC3263" />
</c>
<c>Locating SIP Servers </c>
<!---->
<c>SIPS TCP</c>
<c>_sips._tcp</c>
<c />
<c>NAPTR</c>
<c><xref
target="RFC3263" />
</c>
<c>Locating SIP Servers </c>
<!---->
<c>SIP UDP</c>
<c>_sip._udp</c>
<c />
<c>SRV</c>
<c>
<xref
target="RFC3263" />
</c>
<c>Locating SIP servers.</c>
<!---->
<c>SPF</c>
<c>_spf</c>
<c />
<c>TXT</c>
<c>
<xref
target="RFC4408" />
</c>
<c />
<!---->
<c>DKIM</c>
<c>_domainkey</c>
<c />
<c>TXT</c>
<c><xref
target="RFC4871" /></c>
<c>Public key for verifying DKIM signature.</c>
<c>ADSP</c>
<c>_adsp._domainkey</c>
<c> </c>
<c>TXT</c>
<c><xref
target="RFC5617" /></c>
<c />
<!-- -->
<!---->
<c>PKI LDAP</c>
<c>_PKIXREP._ldap</c>
<c />
<c>SRV</c>
<c><xref
target="RFC4386" /></c>
<c>LDAP PKI Repository</c>
<!-- -->
<c>PKI HTTP</c>
<c>_PKIXREP._http</c>
<c />
<c>SRV</c>
<c><xref
target="RFC4386" /></c>
<c>HTTP PKI Repository</c>
<!-- -->
<c>PKI OCSP</c>
<c>_PKIXREP._ocsp</c>
<c />
<c>SRV</c>
<c><xref
target="RFC4386" /></c>
<c>OCSP PKI Repository</c>
<!-- -->
<!-- Table entry template
<c></c>
<c>_</c>
<c> </c>
<c> </c>
<c><xref
target="" /></c>
<c></c>
<!-\- -\->
-->
</texttable>
</section>
<section
title="Security Considerations">
<t>This memo raises no security issues.</t>
</section>
</middle>
<back>
<references
title="References -- Normative">
<?rfc linefile="1:http://xml.resource.org/public/rfc/bibxml/reference.RFC.2782.xml"?>
<reference
anchor="RFC2782">
<front>
<title
abbrev="DNS SRV RR">A DNS RR for specifying the location of
services (DNS SRV)</title>
<author
fullname="Arnt Gulbrandsen"
initials="A."
surname="Gulbrandsen">
<organization>Troll Tech</organization>
<address>
<postal>
<street>Waldemar Thranes gate 98B</street>
<city>Oslo</city>
<region />
<code>N-0175</code>
<country>NO</country></postal>
<phone>+47 22 806390</phone>
<facsimile>+47 22 806380</facsimile>
<email>arnt@troll.no</email></address>
</author>
<author
fullname="Paul Vixie"
initials="P."
surname="Vixie">
<organization>Internet Software Consortium</organization>
<address>
<postal>
<street>950 Charter Street</street>
<city>Redwood City</city>
<region>CA</region>
<code>94063</code>
<country>US</country></postal>
<phone>+1 650 779 7001</phone></address>
</author>
<author
fullname="Levon Esibov"
initials="L."
surname="Esibov">
<organization>Microsoft Corporation</organization>
<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country></postal>
<email>levone@microsoft.com</email></address>
</author>
<date
month="February"
year="2000" />
<abstract>
<t>This document describes a DNS RR which specifies the
location of the server(s) for a specific protocol and
domain.</t>
</abstract>
</front>
<seriesInfo
name="RFC"
value="2782" />
<format
octets="24013"
target="http://www.rfc-editor.org/rfc/rfc2782.txt"
type="TXT" />
</reference>
<?rfc linefile="309:/var/tmp/CGItemp59640.xml"?>
<?rfc linefile="1:http://xml.resource.org/public/rfc/bibxml/reference.RFC.3263.xml"?>
<reference
anchor="RFC3263">
<front>
<title>Session Initiation Protocol (SIP): Locating SIP
Servers</title>
<author
fullname="J. Rosenberg"
initials="J."
surname="Rosenberg">
<organization />
</author>
<author
fullname="H. Schulzrinne"
initials="H."
surname="Schulzrinne">
<organization />
</author>
<date
month="June"
year="2002" />
<abstract>
<t>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]</t>
</abstract>
</front>
<seriesInfo
name="RFC"
value="3263" />
<format
octets="42310"
target="http://www.rfc-editor.org/rfc/rfc3263.txt"
type="TXT" />
</reference>
<?rfc linefile="309:/var/tmp/CGItemp59640.xml"?>
<?rfc linefile="1:http://xml.resource.org/public/rfc/bibxml/reference.RFC.4408.xml"?>
<reference
anchor="RFC4408">
<front>
<title>Sender Policy Framework (SPF) for Authorizing Use of
Domains in E-Mail, Version 1</title>
<author
fullname="M. Wong"
initials="M."
surname="Wong">
<organization />
</author>
<author
fullname="W. Schlitt"
initials="W."
surname="Schlitt">
<organization />
</author>
<date
month="April"
year="2006" />
<abstract>
<t>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.</t>
</abstract>
</front>
<seriesInfo
name="RFC"
value="4408" />
<format
octets="105009"
target="http://www.rfc-editor.org/rfc/rfc4408.txt"
type="TXT" />
</reference>
<?rfc linefile="309:/var/tmp/CGItemp59640.xml"?>
</references>
<references
title="References -- Informative">
<?rfc linefile="1:http://xml.resource.org/public/rfc/bibxml/reference.RFC.2821.xml"?>
<reference
anchor="RFC2821">
<front>
<title>Simple Mail Transfer Protocol</title>
<author
fullname="J. Klensin"
initials="J."
surname="Klensin">
<organization />
</author>
<date
month="April"
year="2001" />
<abstract>
<t>This document is a self-contained specification of the
basic protocol for the Internet electronic mail transport.
[STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo
name="RFC"
value="2821" />
<format
octets="192504"
target="http://www.rfc-editor.org/rfc/rfc2821.txt"
type="TXT" />
</reference>
<?rfc linefile="312:/var/tmp/CGItemp59640.xml"?>
<?rfc linefile="1:http://xml.resource.org/public/rfc/bibxml/reference.RFC.0974.xml"?>
<reference
anchor="RFC0974">
<front>
<title>Mail routing and the domain system</title>
<author
fullname="Craig Partridge"
initials="C."
surname="Partridge">
<organization>Bolt Baranek and Newman (BBN) Laboratories Inc.,
CSNET CIC</organization>
</author>
<date
day="1"
month="January"
year="1986" />
</front>
<seriesInfo
name="RFC"
value="974" />
<format
octets="18581"
target="http://www.rfc-editor.org/rfc/rfc974.txt"
type="TXT" />
</reference>
<reference
anchor="RFC4871">
<front>
<title>DomainKeys Identified Mail (DKIM) Signatures</title>
<author
fullname="E. Allman"
initials="E."
surname="Allman">
<organization />
</author>
<author
fullname="J. Callas"
initials="J."
surname="Callas">
<organization />
</author>
<author
fullname="M. Delany"
initials="M."
surname="Delany">
<organization />
</author>
<author
fullname="M. Libbey"
initials="M."
surname="Libbey">
<organization />
</author>
<author
fullname="J. Fenton"
initials="J."
surname="Fenton">
<organization />
</author>
<author
fullname="M. Thomas"
initials="M."
surname="Thomas">
<organization />
</author>
<date
month="May"
year="2007" />
<abstract>
<t>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]</t>
</abstract>
</front>
<seriesInfo
name="RFC"
value="4871" />
<format
octets="166054"
target="http://www.rfc-editor.org/rfc/rfc4871.txt"
type="TXT" />
</reference>
<?rfc linefile="312:/var/tmp/CGItemp59640.xml"?>
<reference
anchor="RFC5507">
<front>
<title />
<author
fullname="P. Faltstrom"
initials="P."
role="editor"
surname="Faltstrom">
<organization>IAB</organization>
</author>
<author
fullname="R. Austein"
initials="R."
role="editor"
surname="Austein">
<organization>IAB</organization>
</author>
<date
month="April"
year="2009" />
</front>
<seriesInfo
name="RFC"
value="5507" />
</reference>
<reference
anchor="RFC4386">
<front>
<title>Internet X.509 Public Key Infrastructure: Repository
Locator Service</title>
<author
fullname="S. Boeyen"
initials="S."
surname="Boeyen">
<organization>Entrust Inc.</organization>
</author>
<author
fullname="P. Hallam-Baker"
initials="P."
surname="Hallam-Baker">
<organization>VeriSign Inc.</organization>
</author>
<date
month="February"
year="2006" />
</front>
</reference>
<reference
anchor="RFC5617">
<front>
<title>DomainKeys Identified Mail (DKIM) Author Domain Signing
Practices (ADSP)</title>
<author
fullname="E. Allman"
initials=""
surname="">
<organization>Sendmail, Inc.</organization>
</author>
<author
fullname="J. Fenton"
initials=""
surname="">
<organization>Cisco Systems, Inc.</organization>
</author>
<author
fullname="M. Delany"
initials=""
surname="">
<organization>Yahoo! Inc.</organization>
</author>
<author
fullname="J. Levine"
initials=""
surname="">
<organization>Taughannock Networks</organization>
</author>
<date
month="August"
year="2009" />
</front>
</reference>
</references>
<section
title="Acknowledgements">
<t>Thanks go to Bill Fenner, Tony Hansen, Peter Koch, Olaf Kolkman, and
Andrew Sullivan for diligent review of the earlier drafts.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:24:43 |