ENUM P. Faltstrom
Internet-Draft Cisco
Intended status: Standards Track O. Kolkman
Expires: January 10, 2008 NLNet
July 9, 2007
The Uniform Resource Identifier (URI) DNS Resource Record
draft-ietf-enum-uri-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 10, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document defines a new DNS resource record, called the Uniform
Resource Identifier (URI) RR, for publishing mappings from hostnames
to URIs.
The next version of this draft should NOT be a work item of the ENUM
wg, but instead an individual submission of name
draft-faltstrom-rrtype-uri-00.txt.
Faltstrom & Kolkman Expires January 10, 2008 [Page 1]
Internet-Draft URI Resource Record July 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Applicability Statement . . . . . . . . . . . . . . . . . . . 3
3. DNS considerations . . . . . . . . . . . . . . . . . . . . . . 4
4. The format of the URI RR . . . . . . . . . . . . . . . . . . . 4
4.1. Ownername, class and type . . . . . . . . . . . . . . . . 4
4.2. Priority . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.3. Weight . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.4. Target . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.5. URI RDATA Wire Format . . . . . . . . . . . . . . . . . . 5
4.6. The URI RR Presentation Format . . . . . . . . . . . . . . 6
5. Definition of the flag 'D' for NAPTR records . . . . . . . . . 6
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Homepage at one domain, but two domains in use . . . . . . 6
6.2. Different providers for services for the same E.164 . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . . 9
10.2. Non-normative references . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 11
Faltstrom & Kolkman Expires January 10, 2008 [Page 2]
Internet-Draft URI Resource Record July 2007
1. Introduction
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.
Currently, looking up URIs given a hostname uses the DDDS [RFC3401]
application framework with the DNS as a database as specified in RFC
3404 [RFC3404]. This have a number of implications as described in
draft-iab-dns-choices [I-D.iab-dns-choices] 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.
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.
Querying for the URI resource record type is not replacing querying
for the NAPTR (or S-NAPTR [RFC3958]) 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.
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.
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, RFC 2119
[RFC2119].
2. Applicability Statement
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. Examples of such
are many scenarios where telephony routing with the help of E.164
[E164] numbers according to ENUM [RFC3761], or when an organisation
have many domain names, but only one official web page.
Faltstrom & Kolkman Expires January 10, 2008 [Page 3]
Internet-Draft URI Resource Record July 2007
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.
3. DNS considerations
Using prefix labels, such as underscored service tags, prevents the
use of wildcards [I-D.iab-dns-choices], as constructs as
_s2._s1.*.example.net. are not possible in the DNS, see RFC 4592
[RFC4592]. 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.
Subtle management issues may also arise when the delegations from
service to sub service label involves several parties and different
stake holders.
4. The format of the URI RR
This is the format of the URI RR, whose DNS type code is NNNN (to be
assigned by IANA).
Ownername TTL Class URI Priority Weight Target
4.1. Ownername, class and type
The URI ownername is subject to special conventions.
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 uses 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
Faltstrom & Kolkman Expires January 10, 2008 [Page 4]
Internet-Draft URI Resource Record July 2007
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).
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")
The type number for the URI record is NNNN (to be assigned by IANA).
The URI resource record is class independent.
The URI RR has no special TTL requirements.
4.2. Priority
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.
4.3. Weight
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.
4.4. Target
The URI of the target. Resolution of the URI is according to the
definitions for the URI Scheme the URI consists of.
The URI is encoded as one or more <character-string> RFC1035 section
3.3 [RFC1035].
4.5. URI RDATA Wire Format
The RDATA for a URI RR consists of a 2 octet Priority field, a two
octet Weight field, and a variable length target field.
Faltstrom & Kolkman Expires January 10, 2008 [Page 5]
Internet-Draft URI Resource Record July 2007
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 /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.6. The URI RR Presentation Format
The presentation format of the RDATA portion is as follows:
Priority field MUST be represented as an unsigned decimal integer.
The Weight Type field MUST be represented as an unsigned decimal
integer.
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>.
5. Definition of the flag 'D' for NAPTR records
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.
The Regexp field in the NAPTR record MUST be empty when the 'D' flag
is in use.
6. Examples
6.1. Homepage at one domain, but two domains in use
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:
Faltstrom & Kolkman Expires January 10, 2008 [Page 6]
Internet-Draft URI Resource Record July 2007
_web.example.com. IN URI 10 1 "http://www.example.com/"
_web.example.net. IN URI 10 1 "http://www.example.com/"
6.2. Different providers for services for the same E.164
An organisation have the E.164 +442079460148, but different
organisations handle routing of calls for the number on the Internet
(with the help of SIP) and traditional PSTN. More specifically, the
two providers want to run DNS for the record(s) that refer to the
services they provide.
The ENUM provider for the +44 country code in this case not only do
delegations on the full E.164 number, but delegations on the service
parameter values, as can be seen below:
In this example we also include the NAPTR records that with the help
of the 'D' flag refer to the URI records. We also include NAPTR
records according to RFC 3761 [RFC3761] that give backward
compatibility.
In zone 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa.:
Faltstrom & Kolkman Expires January 10, 2008 [Page 7]
Internet-Draft URI Resource Record July 2007
$ORIGIN 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa.
;; NAPTR records that refer to URI records
IN NAPTR 1 1 "D" "E2U:sip" ( ; service
"" ; regexp
_sip._e2u ; replacement
)
IN NAPTR 1 1 "D" "E2U:tel" ( ;service
"" ;regexp
_tel._e2u ;replacement
)
;; NAPTR records for RFC 3761 compatibility
IN NAPTR 1 1 "U" "E2U:sip" ( ;service
"!.*!sip:+442079460148@sipprovider.net!" ; regexp
. ; replacement
)
IN NAPTR 1 1 "U" "E2U:tel" ( ;service
"!.*!sip:+442079460148@sipprovider.net!" ; regexp
. ; replacement
)
;; Delegations to child zones
_sip._e2u IN NS ns1.example.net.
_tel._e2u IN NS ns1.example.com.
In zone _sip._e2u.8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa:
$ORIGIN 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa.
_sip._e2u IN URI "sip:+442079460148@example.net"
In zone 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa:
$ORIGIN 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa.
_tel._e2u IN URI "tel:+442079460148"
7. IANA Considerations
8. Security Considerations
Faltstrom & Kolkman Expires January 10, 2008 [Page 8]
Internet-Draft URI Resource Record July 2007
9. Acknowledgements
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.
10. References
10.1. Normative References
[E164] ITU-T, "The International Public Telecommunication Number
Plan", Recommendation E.164, May 1997.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Four: The Uniform Resource Identifiers (URI)",
RFC 3404, October 2002.
[RFC3958] Daigle, L. and A. Newton, "Domain-Based Application
Service Location Using SRV RRs and the Dynamic Delegation
Discovery Service (DDDS)", RFC 3958, January 2005.
10.2. Non-normative references
[I-D.iab-dns-choices]
Faltstrom, P., "Design Choices When Expanding DNS",
draft-iab-dns-choices-04 (work in progress), October 2006.
[RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part One: The Comprehensive DDDS", RFC 3401, October 2002.
[RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform
Resource Identifiers (URI) Dynamic Delegation Discovery
System (DDDS) Application (ENUM)", RFC 3761, April 2004.
[RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name
System", RFC 4592, July 2006.
Faltstrom & Kolkman Expires January 10, 2008 [Page 9]
Internet-Draft URI Resource Record July 2007
Authors' Addresses
Patrik Faltstrom
Cisco Systems
Email: paf@cisco.com
Olaf Kolkman
NLnet Labs
Email: olaf@NLnetLabs.nl
Faltstrom & Kolkman Expires January 10, 2008 [Page 10]
Internet-Draft URI Resource Record July 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Faltstrom & Kolkman Expires January 10, 2008 [Page 11]
