One document matched: draft-crocker-dns-attrleaf-06.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" [ ]>
<?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-06"
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> -->
<!-- <workgroup>DNSOP</workgroup> -->
<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. 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 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 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 the underscore "attribute" 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 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 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, different uses have developed largely
without coordination. One side-effect is that there is no
consistently distinguishable internal syntax for the record; even
internal inspection might not be a reliable means of distinguishing
among the different uses. 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 distinguishing among different types of
use was part of the design. <xref
target="RFC2782" /> The SRV specification serves as a template,
defining an RR that may 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.</t>
</section>
<section
anchor="underfun"
title="Underscore DNS Registry Function">
<t>This specification defines a registry for DNS nodes names, 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.
This does not constrain the use of other resource records that are
not specified. The purpose of the registry 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 name might be multi-part, as a sequence of names.
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 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>_service1</c>
<c>_service2._protoB</c>
<c>_service3._protoC</c>
<c>_service3._protoC</c>
<c>_service4._protoD._useX</c>
<c>_protoE._region._authority</c>
</texttable>
<t>The flat registry design: <list
style="symbols">
<t>provides significantly simpler administration than is needed
for hierarchical tables, simples, and</t>
<t>is significantly simpler for readers to understand and is
likely to produce fewer programming or administration
errors.</t>
</list>
</t>
<t />
</section>
<section
anchor="regdef"
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> Per <xref
target="RFC2434" />, 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="regdef" />.</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>SRV TCP</c>
<c>_srv._tcp</c>
<c />
<c>SRV</c>
<c>
<xref
target="RFC2782" />
</c>
<c> SRV template </c>
<!-- -->
<c>SRV UDP</c>
<c>_srv._udp</c>
<c />
<c>SRV</c>
<c>
<xref
target="RFC2782" />
</c>
<c> SRV template </c>
<!-- -->
<c>LDAP SRV</c>
<c>_ldap._tcp</c>
<c />
<c>SRV</c>
<c>
<xref
target="RFC2782" />
</c>
<c> LDAP server </c>
<!-- -->
<c>SIP TCP</c>
<c>_sip._tcp</c>
<c />
<c>NAPTR</c>
<c><xref
target="RFC3263" />, <xref
target="RFC6011" />
</c>
<c>Locating SIP Servers and UA configuration</c>
<!---->
<c>SIPS TCP</c>
<c>_sips._tcp</c>
<c />
<c>NAPTR</c>
<c><xref
target="RFC3263" />, <xref
target="RFC6011" />
</c>
<c>Locating SIP Servers and UA configuration</c>
<!---->
<c>SIP UDP</c>
<c>_sip._udp</c>
<c />
<c>SRV</c>
<c>
<xref
target="RFC3263" />, <xref
target="RFC6011" />
</c>
<c>Locating SIP servers and UA configuration</c>
<!---->
<c>SPF</c>
<c>_spf</c>
<c />
<c>TXT</c>
<c>
<xref
target="RFC4408" />
</c>
<c>Authorized IP addresses for sending mail</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>Published DKIM usage practices</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>
<!-- -->
<c>VBR</c>
<c>_vouch</c>
<c> </c>
<c>TXT</c>
<c>
<xref
target="RFC5518" />
</c>
<c>Vouch-by-refererence domain assertion</c>
<!-- -->
<c>DDDS</c>
<c>--unknown!--</c>
<c />
<c>SRV</c>
<c>
<xref
target="RFC3404" />
</c>
<c>Mapping DDDS query to DNS records</c>
<!-- -->
<c>SOAP BEEP</c>
<c>_soap-beep._tcp</c>
<c />
<c>SRV</c>
<c>
<xref
target="RFC4227" />
</c>
<c>SOAP over BEEP lookup, when no port specified</c>
<!-- -->
<c>XMLRPC BEEP</c>
<c>_xmlrpc-beep._tcp</c>
<c />
<c>SRV</c>
<c>
<xref
target="RFC3529" />
</c>
<c>Resolve url for XML-RPC using BEEP</c>
<!-- -->
<c>Diameter SCTP</c>
<c>_diameter._sctp</c>
<c />
<c>SRV</c>
<c>
<xref
target="RFC3588" />
</c>
<c>Diameter rendezvous over SCTP</c>
<!-- -->
<c>Diameter TCP</c>
<c>_diameter._tcp</c>
<c />
<c>SRV</c>
<c>
<xref
target="RFC3588" />
</c>
<c>Diameter rendezvous over TCP</c>
<!-- -->
<c>Tunnel</c>
<c>_tunnel._tcp</c>
<c />
<c>SRV</c>
<c>
<xref
target="RFC3620" />
</c>
<c>Finding the appropriate address for tunneling into a particular
domain</c>
<!-- -->
<c>SLP TCP</c>
<c>_slpda._tcp</c>
<c />
<c>SRV</c>
<c>
<xref
target="RFC3832" />
</c>
<c>Discovering desired services in given DNS domains</c>
<!-- -->
<c>SLP UDP</c>
<c>_slpda._udp</c>
<c />
<c>SRV</c>
<c>
<xref
target="RFC3832" />
</c>
<c>Discovering desired services in given DNS domains</c>
<!-- -->
<c>IM</c>
<c>_im</c>
<c />
<c>SRV</c>
<c>
<xref
target="RFC3861" />
</c>
<c>Instant Messaging address resolution</c>
<!-- -->
<c>Pres</c>
<c>_pres</c>
<c />
<c>SRV</c>
<c>
<xref
target="RFC3861" />
</c>
<c>Presence address resolution</c>
<!-- -->
<c>Msg Track</c>
<c>_mtqp._tcp</c>
<c />
<c>SRV</c>
<c>
<xref
target="RFC3887" />
</c>
<c>Assist in determining the path that a particular message has
taken through a messaging system</c>
<!-- -->
<c>XMPP Client</c>
<c>_xmpp-client._tcp</c>
<c />
<c>SRV</c>
<c>
<xref
target="RFC6120" />
</c>
<c>XMPP client lookup of server</c>
<!-- -->
<c>XMPP Server</c>
<c>_xmpp-server._tcp</c>
<c />
<c>SRV</c>
<c>
<xref
target="RFC6120" />
</c>
<c>XMPP server-server lookup</c>
<!-- -->
<c>DDDS SRV</c>
<c>_???</c>
<c>(unable to discern details. /dcrocker)</c>
<c>SRV (and NAPTR?)</c>
<c>
<xref
target="RFC3958" />
</c>
<c>Map domain name, application service name, and application
protocol dynamically to target server and port</c>
<!-- -->
<c>Kerberos TCP</c>
<c>_kerberos._tcp</c>
<c />
<c>SRV</c>
<c>
<xref
target="RFC4120" />
</c>
<c>purpose</c>
<!-- -->
<c>Kerberos UDP</c>
<c>_kerberos._udp</c>
<c />
<c>SRV</c>
<c>
<xref
target="RFC4120" />
</c>
<c>purpose</c>
<!-- -->
<c>PKI LDAP</c>
<c>_pkixrep._ldap</c>
<c />
<c>SRV</c>
<c>
<xref
target="RFC4386" />
</c>
<c>Enables certificate-using systems to locate PKI repositories</c>
<!-- -->
<c>PKI HTTP</c>
<c>_pkixrep._http</c>
<c />
<c>SRV</c>
<c>
<xref
target="RFC4386" />
</c>
<c>Enables certificate-using systems to locate PKI repositories</c>
<!-- -->
<c>PKI OCSP</c>
<c>_pkixrep._ocsp</c>
<c />
<c>SRV</c>
<c>
<xref
target="RFC4386" />
</c>
<c>Enables certificate-using systems to locate PKI repositories</c>
<!-- -->
<c>Cert Store</c>
<c>_certificates._tcp</c>
<c />
<c>SRV</c>
<c>
<xref
target="RFC4387" />
</c>
<c>Obtain certificates and certificate revocation lists (CRLs) from
PKI repositories</c>
<!-- -->
<c>Cert Revocation Store</c>
<c>_crls._tcp</c>
<c />
<c>SRV</c>
<c>
<xref
target="RFC4387" />
</c>
<c>Obtain certificates and certificate revocation lists (CRLs) from
PKI repositories</c>
<!-- -->
<c>PGP Key Store</c>
<c>pgpkeys._tcp</c>
<c />
<c>SRV</c>
<c>
<xref
target="RFC4387" />
</c>
<c>Obtain certificates and certificate revocation lists (CRLs) from
PKI repositories</c>
<!-- -->
<c>MSRP Relay Locator</c>
<c>_msrp._tcp</c>
<c />
<c>SRV</c>
<c>
<xref
target="RFC4976" />
</c>
<c>purpose</c>
<!-- -->
<c>Mobile IPv6 Bootstrap</c>
<c>_mip6._ipv6</c>
<c />
<c>SRV</c>
<c><xref
target="RFC5026" />, <xref
target="RFC5555" /></c>
<c>Bootstrap Mobile IPv6 Home Agent information from non-topological
information</c>
<!-- -->
<c>Digital Video Broadcasting TCP</c>
<c>_dvbservdsc._tcp</c>
<c />
<c>SRV</c>
<c>
<xref
target="RFC5328" />
</c>
<c>Discover non-default DVB entry points addresses</c>
<!-- -->
<c>Digital Video Broadcasting UDP</c>
<c>_dvbservdsc._udp</c>
<c />
<c>SRV</c>
<c>
<xref
target="RFC5328" />
</c>
<c>Discover non-default DVB entry points addresses</c>
<!-- -->
<c>CAPWAP AC</c>
<c>_capwap-control._udp</c>
<c />
<c>rrs</c>
<c>
<xref
target="RFC5415" />
</c>
<c>Discover the CAPWAP AC address(es)</c>
<!-- -->
<c>IM SIP</c>
<c>_im._sip</c>
<c />
<c>SRV</c>
<c>
<xref
target="RFC5509" />
</c>
<c>For resolving Instant Messaging and Presence services with
SIP</c>
<!-- -->
<c>Pres SIP</c>
<c>_pres._sip</c>
<c />
<c>SRV</c>
<c>
<xref
target="RFC5509" />
</c>
<c>For resolving Instant Messaging and Presence services with
SIP</c>
<!-- -->
<c>IEEE 802.21 Mobility TCP</c>
<c>_mihis._tcp</c>
<c />
<c>NAPTR, SRV</c>
<c>
<xref
target="RFC5679" />
</c>
<c>Discovering servers that provide IEEE 802.21-defined Mobility
Services</c>
<!-- -->
<c>IEEE 802.21 Mobility UDP</c>
<c>_mihis._udp</c>
<c />
<c>NAPTR, SRV</c>
<c>
<xref
target="RFC5679" />
</c>
<c>Discovering servers that provide IEEE 802.21-defined Mobility
Services</c>
<!-- -->
<c>STUN Client/Server TCP</c>
<c>_stun._.tcp</c>
<c />
<c>SRV</c>
<c>
<xref
target="RFC5389" />
</c>
<c>Find a STUN server</c>
<!-- -->
<c>STUN Client/Server UDP</c>
<c>_stun._.udp</c>
<c />
<c>SRV</c>
<c>
<xref
target="RFC5389" />
</c>
<c>Find a STUN server</c>
<!-- -->
<c>STUN Client/Server TLS</c>
<c>_stuns._.tcp</c>
<c />
<c>SRV</c>
<c>
<xref
target="RFC5389" />
</c>
<c>Find a STUN server</c>
<!-- -->
<c>TURN TCP</c>
<c>_turn._tcp</c>
<c />
<c>SRV</c>
<c><xref
target="RFC5766" />, <xref
target="RFC5928" /></c>
<c>Control the operation of a relay to bypass NAT</c>
<!-- -->
<c>TURN UDP</c>
<c>_turn._udp</c>
<c />
<c>SRV</c>
<c><xref
target="RFC5766" />, <xref
target="RFC5928" /></c>
<c>Control the operation of a relay to bypass NAT</c>
<!-- -->
<c>TURN TLS</c>
<c>_turns._tcp</c>
<c />
<c>SRV</c>
<c><xref
target="RFC5766" />, <xref
target="RFC5928" /></c>
<c>Control the operation of a relay to bypass NAT</c>
<!-- -->
<c>STUN NAT Behavior Discovery TCP</c>
<c>_stun-behavior._tcp</c>
<c />
<c>SRV</c>
<c>
<xref
target="RFC5780" />
</c>
<c>Discover the presence and current behavior of NATs and firewalls
between the STUN client and the STUN server</c>
<!-- -->
<c>STUN NAT Behavior Discovery UDP</c>
<c>_stun-behavior._udp</c>
<c />
<c>SRV</c>
<c>
<xref
target="RFC5780" />
</c>
<c>Discover the presence and current behavior of NATs and firewalls
between the STUN client and the STUN server</c>
<!-- -->
<c>STUN NAT Behavior Discovery TLS</c>
<c>_stun-behaviors._tcp</c>
<c />
<c>SRV</c>
<c>
<xref
target="RFC5780" />
</c>
<c>Discover the presence and current behavior of NATs and firewalls
between the STUN client and the STUN server</c>
<!-- -->
<c>Sieve Management</c>
<c>_sieve._tcp</c>
<c />
<c>SRV</c>
<c>
<xref
target="RFC5804" />
</c>
<c>Manage Sieve scripts on a remote server</c>
<!-- -->
<c>AFS VLDB</c>
<c>_afs3-vlserver._udp</c>
<c />
<c>SRV</c>
<c>
<xref
target="RFC5864" />
</c>
<c>Locate services for the AFS distributed file system</c>
<!-- -->
<c>AFS PTS</c>
<c>_afs3-prserver._udp</c>
<c />
<c>SRV</c>
<c>
<xref
target="RFC5864" />
</c>
<c>Locate services for the AFS distributed file system</c>
<!-- -->
<c>Mail MSA Submission</c>
<c>_submission._tcp</c>
<c />
<c>SRV</c>
<c>
<xref
target="RFC6186" />
</c>
<c>Locate email services</c>
<!-- -->
<c>IMAP</c>
<c>_imap._tcp</c>
<c />
<c>SRV</c>
<c>
<xref
target="RFC6186" />
</c>
<c>Locate email services</c>
<!-- -->
<c>IMAP TLS</c>
<c>_imaps._tcp</c>
<c />
<c>SRV</c>
<c>
<xref
target="RFC6186" />
</c>
<c>Locate email services</c>
<!-- -->
<c>POP</c>
<c>_pop3._tcp</c>
<c />
<c>SRV</c>
<c>
<xref
target="RFC6186" />
</c>
<c>Locate email services</c>
<!-- -->
<c>POP TLS</c>
<c>_pop3s._tcp</c>
<c />
<c>SRV</c>
<c>
<xref
target="RFC6186" />
</c>
<c>Locate email services</c>
<!-- -->
<!-- Table entry template
<c>name</c>
<c>_label</c>
<c>constraints</c>
<c>_</c>
<c><xref
target="" /></c>
<c>purpose</c>
<!-\- -\->
-->
</texttable>
</section>
<section
title="Related Registries">
<t>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</t>
<t>Registries that are candidates for replacement include: <list>
<t>Instant Messaging SRV Protocol Label Registry</t>
<t>Public Key Infrastructure using X.509 (PKIX) Parameters</t>
<t>Presence SRV Protocol Label Registry</t>
</list>
</t>
</section>
<section
title="Security Considerations">
<t>This memo raises no security issues.</t>
</section>
</middle>
<back>
<references
title="Normative References">
<reference
anchor="RFC2434">
<front>
<title>Guidelines for Writing an IANA Considerations Section in
RFCs</title>
<author
fullname="T. Narten"
initials="T."
surname="Narten">
<organization>IBM</organization>
</author>
<author
fullname="H. Alvestrand"
initials="H."
surname="Alvestrand">
<organization>Maxware</organization>
</author>
<date
month="October"
year="1998" />
</front>
<seriesInfo
name="RFC"
value="2434" />
</reference>
</references>
<references
title="References -- Informative">
<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>
<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="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>
<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>
<reference
anchor="RFC3404">
<front>
<title>Dynamic Delegation Discovery System (DDDS) Part Four: The
Uniform Resource Identifiers (URI) Resolution
Application</title>
<author
fullname="M. Mealling"
initials="M."
surname="MMealling" />
<date
month="October"
year="2002" />
</front>
<seriesInfo
name="RFC"
value="3404" />
</reference>
<reference
anchor="RFC3529">
<front>
<title>Using Extensible Markup Language-Remote Procedure Calling
(XML-RPC) in Blocks Extensible Exchange Protocol (BEEP) </title>
<author
fullname="W. Harold"
initials="W"
surname="Harold">
<organization>IBM</organization>
</author>
<date
month="April"
year="2003" />
</front>
<seriesInfo
name="RFC"
value="3529" />
</reference>
<reference
anchor="RFC3588">
<front>
<title>Diameter Base Protocol </title>
<author
fullname="P. Calhoun"
initials="P."
surname="Calhoun">
<organization>Airespace, Inc.</organization>
</author>
<author
fullname="J. Loughney"
initials="J."
surname="Loughney">
<organization>Nokia</organization>
</author>
<author
fullname="E. Guttman"
initials="E."
surname="Guttman">
<organization>Sun Microsystems, Inc.</organization>
</author>
<author
fullname="G. Zorn"
initials="G."
surname="Zorn">
<organization>Cisco Systems, Inc</organization>
</author>
<author
fullname="J. Arkko"
initials="J."
surname="Arkko">
<organization>Ericsson</organization>
</author>
<date
month="September"
year="2003" />
</front>
</reference>
<reference
anchor="RFC3620">
<front>
<title>The TUNNEL Profile</title>
<author
fullname="D. New"
initials="D."
surname="New" />
<date
month="October"
year="2003" />
</front>
<seriesInfo
name="RFC"
value="3620" />
</reference>
<reference
anchor="RFC3861">
<front>
<title>Address Resolution for Instant Messaging and
Presence</title>
<author
fullname="J. Peterson"
initials="J."
surname="Peterson">
<organization>Neustar</organization>
</author>
<date
month="August"
year="2004" />
</front>
<seriesInfo
name="RFC"
value="3861" />
</reference>
<reference
anchor="RFC3832">
<front>
<title>Remote Service Discovery in the Service Location Protocol
(SLP) via DNS SRV</title>
<author
fullname="W. Zhao"
initials=""
surname="">
<organization>Columbia University</organization>
</author>
<author
fullname="H. Schulzrinne"
initials=""
surname="">
<organization>Columbia University</organization>
</author>
<author
fullname="E. Guttman"
initials=""
surname="">
<organization>Sun Microsystems</organization>
</author>
<author
fullname="C. Bisdikian"
initials=""
surname="">
<organization>IBM</organization>
</author>
<author
fullname="W. Jerome"
initials=""
surname="">
<organization>IBM</organization>
</author>
<date
month="July"
year="2004" />
</front>
</reference>
<reference
anchor="RFC3887">
<front>
<title>Message Tracking Query Protocol</title>
<author />
<date
month="September"
year="2007" />
</front>
</reference>
<reference
anchor="RFC3958">
<front>
<title>Domain-Based Application Service Location Using SRV RRs
and the Dynamic Delegation Discovery Service (DDDS)</title>
<author
fullname="L. Daigle"
initials="L."
surname="Daigle">
<organization>VeriSign, Inc.</organization>
</author>
<author
fullname="A. Newton"
initials="A."
surname="Newton">
<organization>VeriSign, Inc.</organization>
</author>
<date
month="January"
year="2005" />
</front>
<seriesInfo
name="RFC"
value="3958" />
</reference>
<reference
anchor="RFC4120">
<front>
<title>The Kerberos Network Authentication Service (V5)</title>
<author
fullname="C. Neuman"
initials=""
surname="">
<organization>USC-ISI</organization>
</author>
<author
fullname="T. Yu"
initials=""
surname="">
<organization>MIT</organization>
</author>
<author
fullname="S. Hartman"
initials=""
surname="">
<organization>MIT</organization>
</author>
<author
fullname="K. Raeburn"
initials=""
surname="">
<organization>MIT</organization>
</author>
<date
month="July"
year="2005" />
</front>
<seriesInfo
name="RFC"
value="4120" />
</reference>
<reference
anchor="RFC4227">
<front>
<title>Using the Simple Object Access Protocol (SOAP) in Blocks
Extensible Exchange Protocol (BEEP)</title>
<author
fullname="E. O'Tuathail"
initials="E."
surname="O'Tuathail">
<organization>Clipcode.com</organization>
</author>
<author
fullname="M. Rose"
initials="M."
surname="Rose">
<organization>Dover Beach Consulting, Inc.</organization>
</author>
<date
month="January"
year="2006" />
</front>
<seriesInfo
name="RFC"
value="4227" />
</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="RFC4387">
<front>
<title>Internet X.509 Public Key Infrastructure Operational
Protocols: Certificate Store Access via HTTP</title>
<author
fullname="P. Gutmann"
initials="P."
role="editor"
surname="Gutmann">
<organization>University of Auckland</organization>
</author>
<date
month="February"
year="2006" />
</front>
<seriesInfo
name="RFC"
value="4387" />
</reference>
<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>
<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>
<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>
<reference
anchor="RFC4976">
<front>
<title>Relay Extensions for the Message Session Relay Protocol
(MSRP)</title>
<author
fullname="C. Jennings"
initials="C."
surname="Jennings">
<organization>Cisco Systems, Inc.</organization>
</author>
<author
fullname="R. Mahy"
initials="R."
surname="Mahy">
<organization>Plantronics</organization>
</author>
<author
fullname="A. B. Roach"
initials=""
surname="Roach">
<organization>Estacado Systems</organization>
</author>
<date
month="September"
year="2007" />
</front>
<seriesInfo
name="RFC"
value="4976" />
</reference>
<reference
anchor="RFC5026">
<front>
<title>Mobile IPv6 Bootstrapping in Split Scenario</title>
<author
fullname="G. Giaretta"
initials="G."
role="editor"
surname="Giaretta">
<organization>Qualcomm</organization>
</author>
<author
fullname="J. Kempf"
initials="J."
surname="Kempf">
<organization>DoCoMo Labs USA</organization>
</author>
<author
fullname="V. Devarapalli"
initials="V."
role="editor"
surname="Devarapalli">
<organization>Azaire Networks</organization>
</author>
<date
month="October"
year="2007" />
</front>
<seriesInfo
name="RFC"
value="5026" />
</reference>
<reference
anchor="RFC5328">
<front>
<title>A Uniform Resource Name (URN) Namespace for the Digital
Video Broadcasting Project (DVB)</title>
<author
fullname="A. Adolf"
initials="A."
surname="Adolf">
<organization>Micronas GmbH</organization>
</author>
<author
fullname="P. MacAvock"
initials="P."
surname="MacAvock">
<organization>DVB Project</organization>
</author>
<date
month="September"
year="2008" />
</front>
<seriesInfo
name="RFC"
value="5328" />
</reference>
<reference
anchor="RFC5389">
<front>
<title>Session Traversal Utilities for NAT (STUN)</title>
<author
fullname="J. Rosenberg"
initials=""
surname="Rosenberg">
<organization>Cisco</organization>
</author>
<author
fullname="R. Mahy"
initials=""
surname="Mahy">
<organization>Cisco</organization>
</author>
<author
fullname="P. Matthews"
initials=""
surname="Matthews" />
<author
fullname="D. Wing"
initials=""
surname="Wing">
<organization>Cisco</organization>
</author>
<date
month="October"
year="2008" />
</front>
<seriesInfo
name="RFC"
value="5389" />
</reference>
<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="RFC5415">
<front>
<title>Control And Provisioning of Wireless Access Points
(CAPWAP) Protocol Specification</title>
<author
fullname="P. Calhoun"
initials="P."
role="editor"
surname="Calhoun">
<organization>Cisco Systems, Inc.</organization>
</author>
<author
fullname="M. Montemurro"
initials="M."
role="editor"
surname="Montemurro">
<organization>Research In Motion</organization>
</author>
<author
fullname="D. Stanley"
initials="D."
role="editor"
surname="Stanley">
<organization>Aruba Networks</organization>
</author>
<date
month="March"
year="2009" />
</front>
<seriesInfo
name="RFC"
value="5415" />
</reference>
<reference
anchor="RFC5509">
<front>
<title>Internet Assigned Numbers Authority (IANA) Registration of
Instant Messaging and Presence DNS SRV RRs for the Session
Initiation Protocol (SIP)</title>
<author
fullname="S. Loreto"
initials="S."
surname="Loreto">
<organization>Ericsson</organization>
</author>
<date
month="April"
year="2009" />
</front>
<seriesInfo
name="RFC"
value="5509" />
</reference>
<reference
anchor="RFC5518">
<front>
<title>Vouch By Reference</title>
<author
fullname="P. Hoffman"
initials="P."
surname="Hoffman">
<organization>Domain Assurance Council</organization>
</author>
<author
fullname="J. Levine"
initials="J."
surname="Levine">
<organization>Domain Assurance Council</organization>
</author>
<author
fullname="A. Hathcock"
initials="A."
surname="Hathcock">
<organization>Alt-N Technologies</organization>
</author>
<date
month="April"
year="2009" />
</front>
<seriesInfo
name="RFC5"
value="5518" />
</reference>
<reference
anchor="RFC5555">
<front>
<title>Mobile IPv6 Support for Dual Stack Hosts and
Routers</title>
<author
fullname="H. Soliman"
initials="H."
role="editor"
surname="Soliman">
<organization>Elevate Technologies</organization>
</author>
<date
month="June"
year="2009" />
</front>
<seriesInfo
name="RFC"
value="5555" />
</reference>
<reference
anchor="RFC5679">
<front>
<title>Locating IEEE 802.21 Mobility Services Using DNS</title>
<author
fullname="G. Bajko"
initials="G."
surname="Bajko" />
<date
month="December"
year="2009" />
</front>
<seriesInfo
name="RFC"
value="5679" />
</reference>
<reference
anchor="RFC5766">
<front>
<title>Traversal Using Relays around NAT (TURN): Relay Extensions
to Session Traversal Utilities for NAT (STUN)</title>
<author
fullname="R. Mahy"
initials="R."
surname="Mahy" />
<author
fullname="P. Matthews"
initials="P."
surname="Matthews">
<organization>Alcatel-Lucent</organization>
</author>
<author
fullname="J. Rosenberg"
initials="J."
surname="Rosenberg">
<organization>jdrosen.net</organization>
</author>
<date
month="April"
year="2010" />
</front>
<seriesInfo
name="RFC"
value="5766" />
</reference>
<reference
anchor="RFC5780">
<front>
<title>NAT Behavior Discovery Using Session Traversal Utilities
for NAT (STUN)</title>
<author
fullname="D. MacDonald"
initials="D."
surname="MacDonald">
<organization>Skype</organization>
</author>
<author
fullname="B. Lowekamp"
initials="B."
surname="Lowekamp">
<organization>Skype</organization>
</author>
<date
month="May"
year="2010" />
</front>
<seriesInfo
name="RFC"
value="5780" />
</reference>
<reference
anchor="RFC5804">
<front>
<title>A Protocol for Remotely Managing Sieve Scripts</title>
<author
fullname="A. Melnikov"
initials="A."
role="editor"
surname="Melnikov">
<organization>Isode Limited</organization>
</author>
<author
fullname="T. Martin"
initials="T."
surname="Martin">
<organization>BeThereBeSquare, Inc.</organization>
</author>
<date
month="July"
year="2010" />
</front>
<seriesInfo
name="RFC"
value="5804" />
</reference>
<reference
anchor="RFC5864">
<front>
<title>NS SRV Resource Records for AFS</title>
<author
fullname="R. Allbery"
initials="R."
surname="Allbery">
<organization>Stanford University</organization>
</author>
<date
month="April"
year="2010" />
</front>
<seriesInfo
name="RFC"
value="5864" />
</reference>
<reference
anchor="RFC5928">
<front>
<title>Traversal Using Relays around NAT (TURN) Resolution
Mechanism</title>
<author
fullname="M. Petit-Huguenin"
initials="M."
surname="Petit-Huguenin" />
<date
month="August"
year="2010" />
</front>
<seriesInfo
name="RFC"
value="5928" />
</reference>
<reference
anchor="RFC6011">
<front>
<title>Session Initiation Protocol (SIP) User Agent
Configuration</title>
<author
fullname="S. Lawrence"
initials="S."
role="editor"
surname="Lawrence">
<organization>Linden Research, Inc.</organization>
</author>
<author
fullname="J. Elwell"
initials="J."
surname="Elwell">
<organization>Siemens Enterprise Communications</organization>
</author>
<date
month="October"
year="2010" />
</front>
<seriesInfo
name="RFC"
value="6011" />
</reference>
<reference
anchor="RFC6120">
<front>
<title>Extensible Messaging and Presence Protocol (XMPP):
Core</title>
<author
fullname="P. Saint-Andre"
initials="P."
surname="Saint-Andre">
<organization>Cisco</organization>
</author>
<date
month="March"
year="2011" />
</front>
<seriesInfo
name="RFC"
value="6120" />
</reference>
<reference
anchor="RFC6186">
<front>
<title>Use of SRV Records for Locating Email Submission/Access
Services</title>
<author
fullname="C. Daboo"
initials="C."
surname="Daboo">
<organization>Apple Inc.</organization>
</author>
<date
month="March"
year="2011" />
</front>
<seriesInfo
name="RFC"
value="6186" />
</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:22:29 |