ENUM Scott Bradner
Internet-Draft Harvard University
Intended status: Standards Track Lawrence Conroy
Roke Manor Research
Kazunori Fujiwara
Japan Registry Service Co., Ltd.
12 February 2008
The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation
Discovery System (DDDS) Application (ENUM)
<draft-ietf-enum-3761bis-02.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 August 12, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This document discusses the use of the Domain Name System (DNS) for
the storage of E.164 numbers, and for resolving them into URIs that
can be used for (for example) telephony call setup. This document
also describes how the DNS can be used to identify the services
associated with an E.164 number. This document obsoletes RFC 3761.
Bradner, Conroy & Fujiwara [Page 1]
Internet-Draft 3761bis 12 February 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . .
1.2. Use for these mechanisms for private dialing plans . . . . .
1.3. Application of local policy . . . . . . . . . . . . . . . .
2. The ENUM Application Specifications . . . . . . . . . . . . .
2.1. Application Unique String . . . . . . . . . . . . . . . . .
2.2. First Well Known Rule . . . . . . . . . . . . . . . . . . .
2.3. Expected Output . . . . . . . . . . . . . . . . . . . . . .
2.4. Valid Databases . . . . . . . . . . . . . . . . . . . . . .
2.4.1. Flags . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.2. Services Parameters . . . . . . . . . . . . . . . . . . .
2.5. What constitutes an 'Enum Resolver'? . . . . . . . . . . . .
3.xxxxx
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . .
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . .
6. Security Considerations . . . . . . . . . . . . . . . . . . .
6.1. DNS Security . . . . . . . . . . . . . . . . . . . . . . . .
6.2. Caching Security . . . . . . . . . . . . . . . . . . . . . .
6.3. Call Routing Security . . . . . . . . . . . . . . . . . . .
6.4. URI Resolution Security . . . . . . . . . . . . . . . . . .
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .
8. Changes from RFC 3761 . . . . . . . . . . . . . . . . . . . .
9. References . . . . . . . . . . . . . . . . . . . . . . . . . .
9.1. Normative References . . . . . . . . . . . . . . . . . . . .
9.2. Non-normative references . . . . . . . . . . . . . . . . . .
Editor's Address . . . . . . . . . . . . . . . . . . . . . . . . .
Intellectual Property and Copyright Statements . . . . . . . . . .
1. Introduction
This document discusses the use of the Domain Name System (DNS) for
the storage of E.164 [E164] numbers, and for resolving them into URIs
that can be used for (for example) telephony call setup. This
document also describes how the DNS can be used to identify the
services associated with an E.164 number. This document includes a
Dynamic Delegation Discovery System (DDDS) Application specification,
as detailed in the document series described in RFC 3401 [RFC3401].
This document obsoletes RFC 3761 [RFC3761].
Using the process defined in this document, International Public
Telecommunication Numbers in the international format defined in ITU
Recommendation E.164 [E164] (called here "E.164 numbers") can be
transformed into DNS names. Using existing DNS services (such as
delegation through NS records and queries for NAPTR resource
records), one can look up the services associated with that E.164
number. This takes advantage of standard DNS architectural features
of decentralized control and management of the different levels in
Bradner, Conroy & Fujiwara [Page 2]
Internet-Draft 3761bis 12 February 2008
the lookup process.
The domain "e164.arpa" has been assigned to provide the
infrastructure in DNS for storage of E.164 numbers. In order to
facilitate distributed operations, this domain is divided into
subdomains. Holders of E.164 numbers which want the numbers to be
listed in the DNS should contact the appropriate zone administrator
as listed in the policy attached to the zone. One should start
looking for this information by examining the SOA resource record
associated with the zone, just like in normal DNS operations.
Of course, as with other domains, policies for such listings will be
controlled on a subdomain basis and may differ in different parts of
the world.
1.1. Terminology
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].
All other capitalized terms are taken from the vocabulary found in
the DDDS algorithm specification found in RFC 3402 [RFC3402].
1.2. Use for these mechanisms for private dialing plans
This document describes the operation of these mechanisms in the
context of numbers allocated according to the ITU-T recommendation
E.164. The same mechanisms might be used for private dialing plans.
If these mechanisms are re-used, the suffix used for the private
dialing plan MUST NOT be e164.arpa, to avoid conflict with this
specification. Parties to the private dialing plan will need to know
the suffix used by their private dialing plan for correct operation
of these mechanisms. Further, the application unique string used
SHOULD be the full number as specified, but without the leading '+',
and such private use MUST NOT be called "ENUM".
2. The ENUM Application Specifications
This template defines the ENUM DDDS Application according to the
rules and requirements found in RFC 3402 [RFC3402]. The DDDS
database used by this Application is found in RFC 3403 [RFC3403],
which is the document that defines the NAPTR DNS Resource Record
type.
ENUM is only applicable for E.164 numbers. ENUM compliant
applications MUST only query DNS for what it believes is an E.164
number. Since there are numerous dialing plans which can change over
time, it is probably impossible for a client application to have
Bradner, Conroy & Fujiwara [Page 3]
Internet-Draft 3761bis 12 February 2008
perfect knowledge about every valid and dialable E.164 number.
Therefore a client application, doing everything within its power,
can end up with what it thinks is a syntactically correct E.164
number which in reality is not actually valid or dialable. This
implies that applications MAY send DNS queries when, for example, a
user mistypes a number in a user interface. Because of this, there
is the risk that collisions between E.164 numbers and non-E.164
numbers can occur. To mitigate this risk, the E2U portion of the
service field MUST NOT be used for non-E.164 numbers.
2.1. Application Unique String
The Application Unique String is a fully qualified E.164 number minus
any non-digit characters except for the '+' character which appears
at the beginning of the number. The "+" is kept to provide a well
understood anchor for the AUS in order to distinguish it from other
telephone numbers that are not part of the E.164 namespace.
For example, the E.164 number could start out as "+44-116-496-0348".
To ensure that no syntactic sugar is allowed into the AUS, all non-
digits except for "+" are removed, yielding "+441164960348".
2.2. First Well Known Rule
The First Well Known Rule for this Application is the identity rule.
The output of this rule is the same as the input. This is because
the E.164 namespace and this Applications databases are organized in
such a way that it is possible to go directly from the name to the
smallest granularity of the namespace directly from the name itself.
Take the previous example, the AUS is "+441164960348". Applying the
First Well Known Rule produces the exact same string,
"+441164960348".
2.3. Expected Output
The output of the last DDDS loop is a Uniform Resource Identifier in
its absolute form according to the 'absoluteURI' production in the
Collected ABNF found in RFC 2396 [RFC2396].
2.4. Valid Databases
At present only one DDDS Database is specified for this Application.
"Dynamic Delegation Discovery System (DDDS) Part Three: The DNS
Database" [RFC3403] specifies a DDDS Database that uses the NAPTR DNS
resource record to contain the rewrite rules. The Keys for this
database are encoded as domain names.
2.4.1 Initial Key Construction
The output of the First Well Known Rule for the ENUM Application is
the E.164 number minus all non-digit characters except for the "+".
In order to convert this to a unique key in this Database the string
Bradner, Conroy & Fujiwara [Page 4]
Internet-Draft 3761bis 12 February 2008
is converted into a domain name according to this algorithm:
1. Remove all characters with the exception of the digits. For
example, the First Well Known Rule produced the Key
"+442079460148". This step would simply remove the leading
"+", producing "442079460148".
2. Put dots (".") between each digit. Example:
4.4.2.0.7.9.4.6.0.1.4.8
3. Reverse the order of the digits. Example:
8.4.1.0.6.4.9.7.0.2.4.4
4. Append the string ".e164.arpa." to the end. Example:
8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa.
This domain name is used to request NAPTR records which may contain
the end result or, if the flags field is empty, produces new keys in
the form of domain names from the DNS.
The character set used to encode the substitution expression is
UTF-8. The allowed input characters are all those characters that
are allowed anywhere in an E.164 number. The characters allowed to
be in a Key are those that are currently defined for DNS domain
names.
2.4.2. Optional Name Server Additional Section Processing
Some nameserver implementations attempt to be intelligent about items
that are inserted into the additional information section of a given
DNS response. For example, BIND will attempt to determine if it is
authoritative for a domain whenever it encodes one into a packet. If
it is, then it will insert any A records it finds for that domain
into the additional information section of the answer until the
packet reaches the maximum length allowed. It is therefore
potentially useful for a client to check for this additional
information. It is also easy to contemplate an ENUM enhanced
nameserver that understand the actual contents of the NAPTR records
it is serving and inserts more appropriate information into the
additional information section of the response. Thus, DNS servers
MAY interpret Flag values and use that information to include
appropriate resource records in the Additional Information portion of
the DNS packet. Clients are encouraged to check for additional
information but are not required to do so. See the Additional
Information Processing section of RFC 3403 [RFC3403], Section 4.2 for
more information on NAPTR records and the Additional Information
section of a DNS response packet.
2.4.1. Flags
This Database contains a field that contains flags that signal when
the DDDS algorithm has finished. At this time only one flag, "U", is
Bradner, Conroy & Fujiwara [Page 5]
Internet-Draft 3761bis 12 February 2008
defined. This means that this Rule is the last one and that the
output of the Rule is a URI [RFC2396]. See RFC 3404 [RFC3404].
If a client encounters a record with an unknown flag, it MUST ignore
it and move to the next Rule. This test takes precedence over any
ordering since flags can control the interpretation placed on fields.
A novel flag might change the interpretation of the regexp and/or
replacement fields such that it is impossible to determine if a
record matched a given target.
If this flag is not present then this rule is non-terminal. If a
Rule is non-terminal then clients MUST use the Key produced by this
Rewrite Rule as the new Key in the DDDS loop (i.e., causing the
client to query for new NAPTR records at the domain name that is the
result of this Rule).
2.4.2. Services Parameters
Service Parameters for this Application take the following form and
are found in the Service field of the NAPTR record.
service-field = "E2U" 1*(servicespec)
servicespec = "+" enumservice
enumservice = type 0*(subtypespec)
subtypespec = ":" subtype
type = 1*32(ALPHA / DIGIT / "-")
subtype = 1*32(ALPHA / DIGIT / "-")
In other words, a non-optional "E2U" (used to denote ENUM only
Rewrite Rules in order to mitigate record collisions) followed by 1
or more Enumservices which indicate the class of functionality a
given end point offers. Each Enumservice is indicated by an initial
'+' character.
2.4.2.1. ENUM Services
Enumservice specifications contain the functional specification
(i.e., what it can be used for), the valid protocols, and the URI
schemes that may be returned. Note that there is no implicit mapping
between the textual string "type" or "subtype" in the grammar for the
Enumservice and URI schemes or protocols. The mapping, if any, must
be made explicit in the specification for the Enumservice itself. A
registration of a specific Type also has to specify the Subtypes
allowed.
The only exception to the registration rule is for Types and Subtypes
used for experimental purposes, and those are to start with the facet
"X-". These elements are unregistered, experimental, and should be
used only with the active agreement of the parties exchanging them.
Bradner, Conroy & Fujiwara [Page 6]
Internet-Draft 3761bis 12 February 2008
The registration mechanism is specified in "Guide and Template for
IANA Registrations of Enumservices" [SV_GUIDE].
2.4.2.2. Compound NAPTRs
It is possible to have more than one Enumservice associated with a
single NAPTR. Of course, the different Enumservices share the same
Regexp field and so generate the same URI. Such a "compound" NAPTR
could well be used to indicate, for example, a mobile phone that
supports both "voice:tel" and "sms:tel" Enumservices.
The services field in that case would be "E2U+voice:tel+sms:tel".
This compound NAPTR may be reconstructed into a set of NAPTRs each
holding a single Enumservice. ENUM clients SHOULD process the
Enumservices within a compound NAPTR in a left to right sequence.
ENUM provisioning systems SHOULD assume that such processing order
will be used and provision the Enumservices within a compound NAPTR
accordingly.
2.5. The ENUM algorithm always returns a single rule
The ENUM algorithm always returns a single rule. Specific
applications may have application-specific knowledge or facilities
that allow them to present multiple results or speed selection, but
these should never change the operation of the algorithm.
3. ENUM Clients
3.1. Unsupported NAPTRs
An ENUM client MAY discard a NAPTR received in response to an ENUM
query because:
o the NAPTR is syntactically or semantically incorrect,
o the NAPTR has a different (non-empty) DDDS Application identifier
from the 'E2U' used in ENUM,
o the ENUM client does not recognize the Enumservice held in that
NAPTR,
o the ENUM client has local knowledge that the URI that would be
generated by processing the NAPTR is not supported, or
o the end user has specified that this Enumservice is not to be
considered.
These conditions SHOULD NOT cause the whole ENUM query to terminate,
and processing SHOULD continue with the next NAPTR in the returned
Resource Record Set (RRSet).
When an ENUM client encounters a compound NAPTR (i.e. one containing
more than one Enumservice) and cannot process or cannot recognise one
of the Enumservices within it, that ENUM client SHOULD ignore this
Enumservice and continue with the next Enumservice within this
Bradner, Conroy & Fujiwara [Page 7]
Internet-Draft 3761bis 12 February 2008
NAPTR's Services field, discarding the NAPTR only if it cannot handle
any of the Enumservices contained. These conditions SHOULD NOT be
considered errors.
If a problem is detected when processing an ENUM query across
multiple domains (by following non-terminal NAPTR references), then
the ENUM query SHOULD NOT be abandoned, but instead processing SHOULD
continue at the next NAPTR after the non-terminal NAPTR that referred
to the domain in which the problem would have occurred.
3.2. ORDER/PRIORITY Processing
3.2.1. Use of Order and Preference fields
NAPTRs in ENUM zones that hold incorrect ORDER values can cause major
problems. RFC 3403 highlights that having both ORDER and
PREFERENCE/PRIORITY fields is a historical artifact of the NAPTR
resource record type. It is reasonable to have a common default
value for the ORDER field, relying on the PREFERENCE/PRIORITY field
to indicate the preferred sort.
The ORDER field value is the major sort term, and the
PREFERENCE/PRIORITY field value is the minor sort term. Thus one
should expect to have a set of NAPTRs in a zone with identical ORDER
field values and different PREFERENCE/PRIORITY field values; not the
other way around.
To avoid these common mistakes, it is recommended that ENUM NAPTRs
SHOULD hold a default value in their ORDER field.
3.2.2. NAPTRs with identical ORDER/PRIORITY values
There are some zones that hold discrete NAPTRs with identical ORDER
and identical PREFERENCE/PRIORITY field values, with an apparent
reliance on delivery of these NAPTRs in a fixed sequence within the
RRSet returned to queries. This will lead to indeterminate client
behaviour and is unwise.
Multiple NAPTRs with identical ORDER and identical
PREFERENCE/PRIORITY field values SHOULD NOT be provisioned into an
RRSet, unless the intent is that these NAPTRs are truly identical and
there is no preference between them. Implementers SHOULD NOT assume
that the DNS will deliver NAPTRs within an RRSet in a particular
sequence.
3.2.2.1. Compound NAPTRs and implicit ORDER/REFERENCE Values
The Enumservices within a compound NAPTR (i.e. one containing more
than one Enumservice) SHOULD be processed in a left to right order. A
Compound NAPTR can be treated as a set of NAPTRs each holding a
single Enumservice. If this is done, these reconstructed NAPTRs
Bradner, Conroy & Fujiwara [Page 8]
Internet-Draft 3761bis 12 February 2008
share the same ORDER and PREFERENCE/PRIORITY field values but should
be treated as if each had a logically different priority. In this
case the reconstructed NAPTR holding the leftmost Enumservice within
the Compound NAPTR has a better priority, and the reconstructed NAPTR
holding the rightmost Enumservice has the worst priority in this set.
3.2.3. Processing Order value across Domains
Using a different ORDER field value in different domains is
unimportant for most queries. However, DDDS includes a mechanism for
continuing a search for NAPTRs in another domain by including a
reference to that other domain in a "non-terminal" NAPTR. The
treatment of non-terminal NAPTRs is covered in the next section, but
if these are supported then it does have a bearing on the way that
ORDER and PREFERENCE/PRIORITY field values are processed.
ENUM implementations MUST consider the ORDER and PREFERENCE/PRIORITY
values only within the context of the domain currently being
processed in an ENUM query. These values MUST be discarded when
processing other RRSets in the query.
3.3. Non-Terminal NAPTR Processing
3.3.1. Non-Terminal NAPTRs - necessity
Consider an ENUM RRSet that contains a non-terminal NAPTR record.
This non-terminal NAPTR holds, as its target, another domain that has
a set of NAPTRs. In effect, this is similar to the non-terminal
NAPTR being replaced by the NAPTRs contained in the domain to which
it points.
It is possible to have a non-terminal NAPTR in a domain that is,
itself, pointed to by another non-terminal NAPTR. Thus a set of
domains forms a "chain", and the list of NAPTRs to be considered is
the set of all NAPTRs contained in all of the domains in that chain.
For an ENUM management system to support non-terminal NAPTRs, it is
necessary for it to be able to analyze, validate and (where needed)
correct, not only the NAPTRs in its current ENUM domain but also
those referenced by non-terminal NAPTRs in other domains. If the
domains pointed to have non-terminal NAPTRs of their own, the
management system will have to check each of the referenced domains
in turn, as their contents forms part of the result of a query on the
"main" ENUM domain. The domain content in the referenced domains may
well not be under the control of the ENUM management system, and so
it may not be possible to correct any errors in those RRSets. This
is both complex and prone to error in the management system design,
and any reported errors in validation may well be non-intuitive for
users.
Bradner, Conroy & Fujiwara [Page 9]
Internet-Draft 3761bis 12 February 2008
For an ENUM client, supporting non-terminal NAPTRs can also be
difficult. Processing non-terminal NAPTRs causes a set of sequential
DNS queries that can take an indeterminate time, and requires extra
resources and complexity to handle fault conditions like non-terminal
loops. The indeterminacy of response time makes ENUM supported
Telephony Applications difficult (such as in an "ENUM-aware" PBX),
whilst the added complexity and resources needed makes support
problematic in embedded devices like "ENUM-aware" mobile phones.
Given that, in principle, a non-terminal NAPTR can be replaced by the
NAPTRs in the domain to which it points, support of non-terminal
NAPTRs is not needed and non-terminal NAPTRs may not be useful.
Furthermore, some existing ENUM clients do not support non-terminal
NAPTRs and ignore them if received.
To avoid interoperability problems, some kind of acceptable advice is
needed on non-terminal NAPTRs. As current support is limited, non-
terminal NAPTRs SHOULD NOT be used in ENUM unless it is clear that
all ENUM clients this environment supports can process these.
3.3.2. Non-Terminal NAPTRs - considerations
The following specific issues need to be considered if non-terminal
NAPTRs are to be supported in a particular environment. These issues
are gleaned from experience, and indicate the kinds of conditions
that should be considered before support for non-terminal NAPTRs is
contemplated. Note that these issues are in addition to the point
just mentioned on ENUM provisioning or management system complexity
and the potential for that management system to have no control over
the zone contents to which non-terminal NAPTRs in its managed zones
refer.
3.3.2.1. Non-Terminal NAPTRs - general
A non-terminal NAPTR in one RRSet refers to the NAPTRs contained in
another domain. The NAPTRs in the domain referred to by the non-
terminal NAPTR may have a different ORDER value from that in the
referring non-terminal NAPTR.
3.3.2.2. Non-Terminal NAPTRs - loop detection and response
Where a chain of non-terminal NAPTRs refers back to a domain already
traversed in the current query, this implies a "non-terminal loop".
In ENUM processing, a chain of more than 5 domains traversed during a
single ENUM query may be considered excessive, and an indication that
such a self referential loop may have been entered.
There are many techniques that can be used to detect such a loop, but
the simple approach of counting the number of domains queried in the
current ENUM query suffices.
Bradner, Conroy & Fujiwara [Page 10]
Internet-Draft 3761bis 12 February 2008
Where a loop has been detected, processing SHOULD continue at the
next NAPTR in the referring domain (i.e. after the non-terminal NAPTR
that included the reference that triggered the loop detection).
3.3.2.3. Field content in Non-Terminal NAPTRs
The set of specifications defining DDDS and its applications are
complex and multi-layered. This reflects the flexibility that the
system provides, but it does mean that some of the specifications
need clarification as to their interpretation, particularly where
non-terminal rules are concerned.
3.3.2.3.1. Flags field content with Non-Terminal NAPTRs
The Flags field will be empty in non-terminal NAPTRs encountered in
ENUM processing. ENUM does not have any other way to indicate a non-
terminal NAPTR.
3.3.2.3.2. Services field content with Non-Terminal NAPTRs
The Services field SHOULD be empty in a non-terminal NAPTR
encountered in an ENUM query and clients SHOULD ignore any content it
contains.
3.3.2.3.3. Regular Expression and Replacement field content with non-
terminal NAPTRs
RFC 3403 is specific; the Regular Expression and Replacement field
elements are mutually exclusive. This means that if the Regexp
element is not empty then the Replacement element must be empty, and
vice versa.
A Replacement element can be used only in NAPTRs holding a non-
terminal rule (a "non-terminal NAPTR") unless that DDDS Application
has a domain name as its terminal output, whilst the alternative
Regexp element may be used either to generate a domain name as the
next key to be used in the non-terminal case, or to generate the
output of the DDDS application.
Note that each DDDS Application is free to specify the set of flags
to be used with that application. This includes specifying whether a
particular flag is associated with a terminal or non-terminal rule,
and also to specify the interpretation of an empty Flags field (i.e.
whether this is to be interpreted as a terminal or non-terminal rule,
and if it is terminal, then the expected output). ENUM uses only the
'u' flag, with an empty Flags field indicating a non-terminal NAPTR.
A non-terminal NAPTR MUST include its target domain in the (non-
empty) Replacement field. This field MUST be interpreted as holding
the domain name that forms the next key output from this non-terminal
rule. Similarly, the Regexp field SHOULD be empty in a non-terminal
NAPTR encountered in ENUM processing, and ENUM clients MUST ignore
Bradner, Conroy & Fujiwara [Page 11]
Internet-Draft 3761bis 12 February 2008
its content.
3.4. Implications for ENUM Clients
ENUM clients SHOULD NOT discard NAPTRs in which they detect
characters outside the US-ASCII "printable" range (0x20 to 0x7E
hexadecimal).
ENUM Clients MAY discard NAPTRs that have octets in the Flags,
Services, or Regexp fields that have byte values outside the US-ASCII
equivalent range (i.e. byte values above 0x7F). Clients MUST be
ready to encounter NAPTRs with such values without failure.
ENUM clients SHOULD NOT assume that the delimiter is the last
character of the Regexp field.
ENUM clients SHOULD discard NAPTRs that have more or less than 3
unescaped instances of the delimiter character within the Regexp
field.
Each ENUM client MAY reorder the NAPTRs it receives only to match an
explicit preference pre-specified by its end user.
Where the ENUM client presents a list of possible URLs to the end
user for his or her choice, it MAY present all NAPTRs, not just the
ones with the highest currently unprocessed ORDER field value. The
client SHOULD attempt to keep as close as possible to the ORDER and
PREFERENCE/PRIORITY values specified by the Registrant.
ENUM clients SHOULD accept all NAPTRs with identical ORDER and
identical PREFERENCE/PRIORITY field values, and process them in the
sequence in which they appear in the DNS response. (There is no
benefit in further randomising the order in which these are
processed, as intervening DNS Servers might have done this already).
ENUM clients receiving compound NAPTRs (i.e. ones with more than one
Enumservice) SHOULD process these Enumservices using a left-to-right
sort ordering, so that the first Enumservice to be processed will be
the leftmost one, and the last will be the rightmost one.
ENUM clients SHOULD consider the ORDER field value only when sorting
NAPTRs within a single RRSet. The ORDER field value SHOULD NOT be
taken into account when processing NAPTRs across a sequence of DNS
queries created by traversal of non-terminal NAPTR references.
ENUM Clients MUST be ready to process NAPTRs that use a different
character from '!' as their Regexp Delimiter without failure.
ENUM Clients MUST be ready to process NAPTRs that have non-trivial
Bradner, Conroy & Fujiwara [Page 12]
Internet-Draft 3761bis 12 February 2008
patterns in their ERE sub-field values without failure.
ENUM Clients MUST be ready to process NAPTRs with a DDDS Application
identifier other than 'E2U' without failure.
ENUM Clients MUST be ready to process NAPTRs with many copies of a
Backreference pattern within the Repl sub-field without failure.
If a NAPTR is discarded, this SHOULD NOT cause the whole ENUM query
to terminate and processing SHOULD continue with the next NAPTR in
the returned Resource Record Set (RRSet).
When an ENUM client encounters a compound NAPTR (i.e. one containing
more than one Enumservice) and cannot process or cannot recognise one
of the Enumservices within it, that ENUM client SHOULD ignore this
Enumservice and continue with the next Enumservice within this
NAPTR's Services field, discarding the NAPTR only if it cannot handle
any of the Enumservices contained. These conditions SHOULD NOT be
considered errors.
3.4.1. Non-terminal NAPTR processing
ENUM Clients MUST be ready to process NAPTRs with an empty Flags
field ("non-terminal" NAPTRs) without failure. More generally, non-
terminal NAPTR processing SHOULD be implented, but ENUM clients MAY
discard non-terminal NAPTRs they encounter.
ENUM clients SHOULD ignore any content of the Services field when
encountering a non-terminal NAPTR with an empty Flags field.
ENUM clients receiving a non-terminal NAPTR with an empty Flags field
MUST treat the Replacement field as holding the domain name to be
used in the next round of the ENUM query. An ENUM client MUST
discard such a non-terminal NAPTR if the Replacement field is empty
or does not contain a valid domain name. By definition, it follows
that the Regexp field will be empty in such a non-terminal NAPTR, and
MUST be ignored by ENUM clients.
If a problem is detected when processing an ENUM query across
multiple domains (by following non-terminal NAPTR references), then
the ENUM query SHOULD NOT be abandoned, but instead processing SHOULD
continue at the next NAPTR after the non-terminal NAPTR that referred
to the domain in which the problem would have occurred.
If all NAPTRs in a domain traversed as a result of a reference in a
non-terminal NAPTR have been discarded, then the ENUM client SHOULD
continue its processing with the next NAPTR in the "referring" RRSet
(i.e. the one including the non-terminal NAPTR that caused the
Bradner, Conroy & Fujiwara [Page 13]
Internet-Draft 3761bis 12 February 2008
traversal).
ENUM clients MAY consider a chain of more than 5 "non-terminal"
NAPTRs traversed in a single ENUM query as an indication that a
referential loop has been entered.
Where a domain is about to be entered as the result of a reference in
a non-terminal NAPTR, and the ENUM client has detected a potential
referential loop, then the client SHOULD discard the non-terminal
NAPTR from its processing and continue with the next NAPTR in its
list. It SHOULD NOT make the DNS query indicated by that non-
terminal NAPTR.
3.4.2. Backwards Compatibility
ENUM clients MUST support ENUM NAPTRs according to RFC 3761 syntax.
ENUM clients SHOULD also support ENUM NAPTRs according to the
obsolete syntax of RFC 2916; there are still zones that hold "old"
syntax NAPTRs.
4. ENUM Service Examples
The examples below use theoretical services that contain Enumservices
which might not make sense, but that are still used for educational
purposes. For example, the protocol used is in some cases exactly
the same string as the URI scheme. That was the specification in RFC
2916, but this 'default' specification of an Enumservice is no longer
allowed.
4.1. Example
$ORIGIN 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa.
NAPTR 100 50 "u" "E2U+sip" "!^.*$!sip:info@example.com!" .
NAPTR 100 51 "u" "E2U+h323" "!^.*$!h323:info@example.com!" .
NAPTR 100 52 "u" "E2U+email:mailto"
"!^.*$!mailto:info@example.com!" .
This describes that the domain 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa. is
preferably contacted by SIP, secondly via H.323 for voice, and
thirdly by SMTP for messaging. Note that the Enumservice tokens
"sip", "h323", and "email" are Types registered with IANA, and they
have no implicit connection with the protocols or URI schemes with
the same names.
In all cases, the next step in the resolution process is to use the
resolution mechanism for each of the protocols, (specified by the URI
schemes sip, h323 and mailto) to know what node to contact.
5. Implications for ENUM Provisioning
Bradner, Conroy & Fujiwara [Page 14]
Internet-Draft 3761bis 12 February 2008
ENUM NAPTRs SHOULD NOT include characters outside the printable US-
ASCII equivalent range (U+0020 to U+007E) unless it is clear that all
ENUM clients they are designed to support will be able correctly to
process such characters. If ENUM zone provisioning systems require
non-ASCII characters, these systems SHOULD encode the non-ASCII data
to emit only US-ASCII characters by applying the appropriate
mechanism (RFC 3492 [RFC3492], RFC 3987 [RFC3987]). Non-printable
characters SHOULD NOT be used, as ENUM clients may need to present
NAPTR content in a human-readable form.
The case sensitivity flag ('i') is inappropriate for ENUM, and SHOULD
NOT be provisioned into the Regexp field of E2U NAPTRs.
ENUM zone provisioning systems SHOULD use '!' (U+0021) as their
Regexp delimiter character.
If the Regexp delimiter is a character in the static text of the Repl
sub-field, it MUST be "escaped" using the escaped-delimiter
production of the BNF specification shown in section 3.2 of RFC 3402
(i.e. "\!", U+005C U+0021).
If present in the ERE sub-field of an ENUM NAPTR, the literal
character '+' MUST be escaped as "\+" (i.e. U+005C U+002B).
The Registrant and the ENUM zone provisioning system he or she uses
SHOULD NOT rely on ENUM clients taking strict account of the value of
the ORDER and the PREFERENCE/PRIORITY fields in ENUM NAPTRs. Thus, a
Registrant SHOULD place into his or her zone only contacts that he or
she is willing to support; even those with the worst ORDER and
PREFERENCE/PRIORITY values MAY be selected by an end user.
Provisioning systems SHOULD NOT use different ORDER field values for
NAPTRs in a Resource Record Set (RRSet). All ENUM NAPTRs SHOULD hold
a default value in their ORDER field. A value of "100" is
recommended, as it seems to be used in most provisioned domains.
Multiple NAPTRs with identical ORDER and identical PREFERENCE/
PRIORITY field values SHOULD NOT be provisioned into an RRSet, unless
the intent is that these NAPTRs are truly identical and there is no
preference between them. Implementers SHOULD NOT assume that the DNS
will deliver NAPTRs within an RRSet in a particular sequence.
An ENUM zone provisioning system SHOULD assume that, if it generates
compound NAPTRs, the Enumservices will normally be processed in left
to right order within such NAPTRs.
ENUM zone provisioning systems SHOULD assume that, once a non-
terminal NAPTR has been selected for processing, the ORDER field
Bradner, Conroy & Fujiwara [Page 15]
Internet-Draft 3761bis 12 February 2008
value in a domain referred to by that non-terminal NAPTR will be
considered only within the context of that referenced domain (i.e.
the ORDER value will be used only to sort within the current RRSet,
and will not be used in the processing of NAPTRs in any other RRSet).
Whilst this client behaviour is non-compliant, ENUM provisioning
systems and their users should be aware that some ENUM Clients have
been detected with poor (or no) support for non-trivial ERE sub-field
expressions.
ENUM provisioning systems SHOULD be cautious in the use of multiple
Backreference patterns in the Repl sub-field of NAPTRs they
provision. Some Clients have limited buffer space for character
expansion when generating URIs.
As current support is limited, non-terminal NAPTRs SHOULD NOT be
provisioned in ENUM zones unless it is clear that all ENUM clients
this environment supports can process these.
When populating a set of domains with NAPTRs, ENUM zone provisioning
systems SHOULD NOT configure non-terminal NAPTRs so that more than 5
such NAPTRs will be processed in an ENUM query.
In a non-terminal NAPTR encountered in an ENUM query (i.e. one with
an empty Flags field), the Services field SHOULD be empty.
A non-terminal NAPTR MUST include its target domain in the (non-
empty) Replacement field. This field MUST be interpreted as holding
the domain name that forms the next key output from this non-terminal
rule. The Regexp field MUST be empty in a non-terminal NAPTR
intended to be encountered during an ENUM query.
ENUM zones MUST NOT be provisioned with NAPTRs according to the
obsolete form, and MUST be provisioned with NAPTRs in which the
services field is according to RFC 3761.
6. IANA Considerations
No IANA actions are required for this document. See [SV_GUIDE] for
ENUM-related IANA Considerations.
7. Security Considerations
7.1. DNS Security
As ENUM uses DNS, which in its current form is an insecure protocol,
there is no mechanism for ensuring that the data one gets back is
authentic. As ENUM is deployed on the global Internet, it is
expected to be a popular target for various kind of attacks, and
attacking the underlying DNS infrastructure is one way of attacking
Bradner, Conroy & Fujiwara [Page 16]
Internet-Draft 3761bis 12 February 2008
the ENUM service itself.
There are multiple types of attacks that can happen against DNS that
ENUM implementations should consider. See Threat Analysis of the
Domain Name System RFC 3833 [RFC3833] for a review of the various
threats to the DNS.
Because of these threats, a deployed ENUM service SHOULD include
mechanisms to ameliorate these threats. Most of the threats can be
solved by verifying the authenticity of the data via mechanisms such
as DNS Security (DNSSEC) RFC 4033 [RFC4033]. Others, such and Denial
Of Service attacks, cannot be solved by data authentication. It is
important to remember that these threats include not only the NAPTR
lookups themselves, but also the various records needed for the
services to be useful (for example NS, MX, SRV and A records).
Even if DNSSEC is deployed, a service that uses ENUM for address
translation should not blindly trust that the peer is the intended
party as DNSSEC deployment cannot protect against every kind of
attack on DNS. A service should always authenticate the peers as
part of the setup process for the service itself and never blindly
trust any kind of addressing mechanism.
Finally, as an ENUM service will be implementing some type of
security mechanism, software which implements ENUM MUST be prepared
to receive DNSSEC and other standardized DNS security responses,
including large responses, EDNS0 signaling, unknown RRs, etc.
7.2. Caching Security
The caching in DNS can make the propagation time for a change take
the same amount of time as the time to live for the NAPTR records in
the zone that is changed. The use of this in an environment where
IP-addresses are dynamically assigned (for example, when using DHCP
RFC 2131 [RFC2131]) must therefore be done very carefully.
7.3. Call Routing Security
There are a number of countries (and other numbering environments) in
which there are multiple providers of call routing and number/name-
translation services. In these areas, any system that permits users,
or putative agents for users, to change routing or supplier
information may provide incentives for changes that are actually
unauthorized (and, in some cases, for denial of legitimate change
requests). Such environments should be designed with adequate
mechanisms for identification and authentication of those requesting
changes and for authorization of those changes.
7.4. URI Resolution Security
Bradner, Conroy & Fujiwara [Page 17]
Internet-Draft 3761bis 12 February 2008
A large amount of Security Issues have to do with the resolution
process itself, and use of the URIs produced by the DDDS mechanism.
Those have to be specified in the registration of the Enumservice
used, as specified in "Guide and Template for IANA Registrations of
Enumservices" [SV_GUIDE].
8. Acknowledgements
This document is an update of RFC 3761, which was edited by Patrik
Faltstrom and Michael Mealling. Please see the Acknowledgements
section in that RFC for additional acknowledgements.
9. Changes from RFC 3761
xxxx
10. References
10.1. Normative References
[E164] ITU-T, "The International Public Telecommunication Number
Plan", Recommendation E.164, February 2005.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[RFC3402] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Two: The Algorithm", RFC 3402, October 2002.
[RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Three: The Domain Name System (DNS) Database", RFC 3403,
October 2002.
[RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Four: The Uniform Resource Identifiers (URI)", RFC 3404,
October 2002.
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
for Internationalized Domain Names in Applications (IDNA)", RFC
3492, March 2003.
[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.
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", RFC 3987, January 2005.
[SV_GUIDE] Hoeneisen, B., Mayrhofer, A., and J. Livingood, "Guide and
Template for IANA Registrations of Enumservices", draft-ietf-enum-
enumservices-guide-06.txt (work in progress), November 2007.
10.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998.
Bradner, Conroy & Fujiwara [Page 18]
Internet-Draft 3761bis 12 February 2008
[RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part One: The Comprehensive DDDS", RFC 3401, October 2002.
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain
Name System (DNS)", RFC 3833, August 2004.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC 4033,
March 2005.
Author's Address
Scott Bradner
Harvard University
29 Oxford St.
Cambridge MA 02138
Phone: +1 617 495 3864
Email: sob@harvard.edu
Lawrence Conroy
Roke Manor Research
Roke Manor
Old Salisbury Lane
Romsey
United Kingdom
Phone: +44-1794-833666
Email: lconroy@insensate.co.uk
URI: http://www.sienum.co.uk
Kazunori Fujiwara
Japan Registry Service Co., Ltd.
Chiyoda First Bldg. East 13F
3-8-1 Nishi-Kanda Chiyoda-ku
Tokyo 101-0165
JAPAN
Email: fujiwara@jprs.co.jp
URI: http://jprs.jp/en/
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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
Bradner, Conroy & Fujiwara [Page 19]
Internet-Draft 3761bis 12 February 2008
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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
change log - RFC Editor - please remove this section for publication
version 01 -> 02
clean up English - many places
removed Registration mechanism for Enumservices section
removed IANA considerations - point to draft-ietf-enum-enumservices-
guide ,br replace DNS Security Threats in section 6.1 with a pointer
to RFC 3833
fold in text from the ENUM Experiences ID - many places
Bradner, Conroy & Fujiwara [Page 20]
