One document matched: draft-faltstrom-uri-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc3761 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3761.xml'>
<!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc3958 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3958.xml'>
<!ENTITY rfc3401 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3401.xml'>
<!ENTITY rfc3404 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3404.xml'>
<!ENTITY rfc1035 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml'>
<!ENTITY rfc4592 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4592.xml'>
<!ENTITY I-D.iab-dns-choices PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.iab-dns-choices.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc compact="yes"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<!-- Expand crefs and put them inline -->
<?rfc comments='yes' ?>
<?rfc inline='yes' ?>
<rfc docName="draft-faltstrom-uri-00.txt" ipr="full3978" category="std">
<front>
<title abbrev="URI Resource Record">
The Uniform Resource Identifier (URI) DNS Resource Record
</title>
<author fullname="Patrik Faltstrom" initials="P." surname="Faltstrom">
<organization abbrev="Cisco">Cisco Systems</organization>
<address>
<email>paf@cisco.com</email>
</address>
</author>
<author fullname="Olaf Kolkman" initials="O." surname="Kolkman">
<organization abbrev="NLNet">NLnet Labs</organization>
<address>
<email>olaf@NLnetLabs.nl</email>
</address>
</author>
<date month="February" year="2008"/>
<area>Operations</area>
<keyword>DNS</keyword>
<keyword>RFC</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<abstract>
<t>
This document defines a new DNS resource record, called the Uniform
Resource Identifier (URI) RR, for publishing mappings from hostnames
to URIs.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
This document explains the use of the Domain Name System (DNS) for
storage of URIs, and how to resolve hostnames to such URIs that can be
used by various applications. For resolution the application need to
know both the hostname and the protocol that the URI is to be used
for. The protocol is registered by IANA.
</t>
<t>
Currently, looking up URIs given a hostname uses the <xref
target="RFC3401">DDDS</xref> application framework with the DNS as a
database as specified in <xref target="RFC3404">RFC 3404</xref>. This
have a number of implications as described in <xref
target="I-D.iab-dns-choices">draft-iab-dns-choices</xref> such as the
inability to select what NAPTR records that match the query is
interesting. The RRSet returned will always consist of all URIs
"connected" with the domain in question.
</t>
<t>
The URI resource record specified in this document create an ability
for the querying party to select which ones of the NAPTR records one
is interested in. This because data in the service field of the NAPTR
record is included in the owner part of the URI resource record type.
</t>
<t>
Querying for the URI resource record type is not replacing querying
for the NAPTR (or <xref target="RFC3958">S-NAPTR</xref>) resource
record type. Instead it is a complementary mechanism to use when one
know already what service field is interesting. One can with the URI
resource record type directly query for the specific subset of the
otherwise possibly large RRSet given back when querying for NAPTR
resource records.
</t>
<t>
This document updates RFC 3958 and RFC 3404 by adding the flag "D" to
the list of defined terminal flags in section 2.2.3 of RFC 3958 and
4.3 of RFC 3404.
</t>
<t>
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 BCP 14, <xref
target="RFC2119">RFC 2119</xref>.
</t>
</section>
<section title="Applicability Statement">
<t>
In general, it is expected that URI records will be used by clients
for applications where the relevant protocol to be used is known, but
for example extra abstraction given by separating a hostname from a
point of service (as address by the URI) is needed. Example of such a
situation is when an organisation have many domain names, but only one
official web page.
</t>
<t>
Applications MUST know the specific service fields to prepend the
hostname with. Using repetitive queries for URI records MUST NOT be a
replacement for querying for NAPTR or S-NAPTR records. NAPTR and
S-NAPTR records are for discovery of the various services and URI for
looking up access point for a given service. Those are two very
different kinds of needs.
</t>
</section>
<section title="DNS considerations">
<t>
Using prefix labels, such as underscored service tags, prevents the
use of <xref target="I-D.iab-dns-choices">wildcards</xref>, as
constructs as _s2._s1.*.example.net. are not possible in the DNS,
see <xref target="RFC4592">RFC 4592</xref>. Besides, underscored
service tags used for the URI RR (based on the NAPTR service
descriptions) may have slightly different semantics than service tags
used for underscored prefix labels that are used in combination with
other (yet unspecified) RR types. This may cause subtle management
problems when delegation structure that has developed within the
context of URI RRs is also to be used for other RR types. Since the
service labels might be overloaded applications should carefully check
that the application level protocol is indeed the protocol they
expect.
</t>
<t>
Subtle management issues may also arise when the delegations from
service to sub service label involves several parties and different
stake holders.
</t>
</section>
<section title="The format of the URI RR">
<t>
This is the format of the URI RR, whose DNS type code is NNNN (to be
assigned by IANA).
</t>
<figure>
<artwork>
<![CDATA[
Ownername TTL Class URI Priority Weight Target
]]>
</artwork>
</figure>
<section title="Ownername, class and type">
<t>
The URI ownername is subject to special conventions.
</t>
<t>
Just like the SRV RR [ref] the URI RR has service information
encoded in its ownername. In order to encode the service for a
specific owner name one use service parameters. Valid service
parameters used are those as registered by IANA for NAPTR Records of
any kind [ref to IANA registry name]. The service parameters are
reversed, prepended with an underscore (_) and prepended to the
owner name in separate labels. 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).
</t>
<t>
For example, suppose we are looking for the URI for a service
with Service Parameter "A:B:C" for host example.com.. Then we
would query for (QNAME,QTYPE)=("_C._B._A.example.com","URI")
</t>
<t>
The type number for the URI record is NNNN (to be assigned by IANA).
</t>
<t>
The URI resource record is class independent.
</t>
<t>
The URI RR has no special TTL requirements.
</t>
</section>
<section title="Priority">
<t>
The priority of this target URI. A client MUST attempt to contact
the URI with the lowest-numbered priority it can reach; URIs with
the same priority SHOULD be tried in an order defined by the weight
field. The range is 0-65535. This is a 16 bit unsigned integer in
network byte order.
</t>
</section>
<section title="Weight">
<t>
A server selection mechanism. The weight field specifies a
relative weight for entries with the same priority. Larger weights
SHOULD be given a proportionately higher probability of being
selected. The range of this number is 0-65535. This is a 16 bit
unsigned integer in network byte order.
</t>
</section>
<section title="Target">
<t>
The URI of the target. Resolution of the URI is according to
the definitions for the URI Scheme the URI consists of.
</t>
<t>
The URI is encoded as one or more <character-string> <xref
target="RFC1035">RFC1035 section 3.3</xref>.
</t>
</section>
<section title="URI RDATA Wire Format">
<t>
The RDATA for a URI RR consists of a 2 octet Priority field,
a two octet Weight field, and a variable length target field.
</t>
<figure>
<artwork>
<![CDATA[
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Priority | Weight |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ Target /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
</section>
<section title="The URI RR Presentation Format">
<t>
The presentation format of the RDATA portion is as follows:
</t>
<t>
Priority field MUST be represented as an unsigned decimal integer.
</t>
<t>
The Weight Type field MUST be represented as an unsigned decimal
integer.
</t>
<t>
The target URI is enclosed in double-quotes ("). If the total length
of the URI exceeds 255 characters the URI will be encoded in
multiple <character-strings>.
</t>
</section>
</section>
<section title="Definition of the flag 'D' for NAPTR records">
<t>
This document specifies the flag "D" for use as a flag in NAPTR
records. The flag indicate a terminal NAPTR record because it denotes
the end of the DDDS/NAPTR processing rules. In the case of a "D" flag,
the Replacement field in the NAPTR record is used as the Owner of a
DNS query for URI records, and normal URI processing as defined in
this document is applied.
</t>
<t>
The Regexp field in the NAPTR record MUST be empty when the 'D' flag
is in use.
</t>
</section>
<section title="Examples">
<section title="Homepage at one domain, but two domains in use">
<t>
An organisation have the domain names example.com and example.net,
but the official URI http://www.example.com/. Given the Service Tag
"web" for the imagined "homepage" application service, the following
URI Resource Records could be made available in the respective
zones (example.com and example.net):
</t>
<figure>
<artwork>
<![CDATA[
$ORIGIN example.com.
IN NAPTR 1 1 "D" "http" ( ; service
"" ; regexp
_http ) ; replacement
_http IN URI 10 1 "http://www.example.com/"
$ORIGIN example.net.
IN NAPTR 1 1 "D" "http" ( ; service
"" ; regexp
_http ) ; replacement
_http IN URI 10 1 "http://www.example.com/"
]]>
</artwork>
</figure>
</section>
</section>
<section title="IANA Considerations">
</section>
<section title="Security Considerations">
</section>
<section title="Acknowledgements">
<t>
Ideas on how to split the two different kind of queries "What services
exists for this domain name" and "What is the URI for this service"
came from Scott Bradner and Lawrence Conroy. Other people that have
contributed to this document include Olafur Gudmundsson, Maria Hall,
Peter Koch and Penn Pfautz.
</t>
</section>
</middle>
<back>
<references title='Normative References'>
&rfc2119;
&rfc3404;
&rfc3958;
&rfc1035;
<reference anchor="E164">
<front>
<title>The International Public Telecommunication Number Plan</title>
<author>
<organization>ITU-T</organization>
</author>
<date month="May" year="1997"/>
</front>
<seriesInfo name="Recommendation" value="E.164"/>
</reference>
</references>
<references title='Non-normative references'>
&rfc3401;
&rfc4592;
&I-D.iab-dns-choices;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 07:15:01 |