1. Introduction
This document discusses the use of the Domain Name System (DNS) for
storage of E.164 numbers. More specifically, how DNS can be used for
identifying available services connected to one E.164 number. It
specifically obsoletes RFC 2916(-> 3761prop) to bring it in line with the Dynamic
Delegation Discovery System (DDDS) Application specification found in
the document series specified in RFC 3401 [6]. It is very important
to note that it is impossible to read and understand this document
without reading the documents discussed in RFC 3401 [6].
Through transformation of International Public Telecommunication
Numbers in the international format [5], called within this document
E.164 numbers, into DNS names and the use of existing DNS services
like delegation through NS records and NAPTR records, one can look up
what services are available for a specific E.164 in a decentralized
way with distributed management of the different levels in the lookup
process.
The domain "e164.arpa" is being populated in order 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 to be listed in DNS
should contact the appropriate zone administrator according to the
policy which is 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 [1].
All other capitalized terms are taken from the vocabulary found in
the DDDS algorithm specification found in RFC 3403prop [2].
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".
1.3. Application of local policy
The Order field in the NAPTR record specifies in what order the DNS
records are to be interpreted. This is because DNS does not
guarantee the order of records returned in the answer section of a
DNS packet. In most ENUM cases this isn't an issue because the
typical regular expression will be '!^.*$!' since the first query
often results in a terminal Rule.
But there are other cases (non-terminal Rules) where two different
Rules both match the given Application Unique String. As each Rule
is evaluated within the algorithm, one may match a more significant
piece of the AUS than the other. For example, by using a non-
terminal NAPTR a given set of numbers is sent to some private-
dialing-plan-specific zone. Within that zone there are two Rules
that state that if a match is for the entire exchange and the service
is SIP related then the first, SIP-specific rule is used. But the
other Rule matches a longer piece of the AUS, specifying that for
some other service (instant messaging) that the Rule denotes a
departmental level service. If the shorter matching Rule comes
before the longer match, it can 'mask' the other rules. Thus, the
order in which each Rule is tested against the AUS is an important
corner case that many DDDS applications take advantage of.
In the case where the zone authority wishes to state that two Rules
have the same effect or are identical in usage, then the Order for
those records is set to the same value. In that case, the Preference
is used to specify a locally over-ridable suggestion by the zone
authority that one Rule might simply be better than another for some
reason.
For ENUM this specifies where a client is allowed to apply local
policy and where it is not. The Order field in the NAPTR is a
request from the holder of the E.164 number that the records be
handled in a specific way. The Preference field is merely a
suggestion from that E.164 holder that one record might be better
than another. A client implementing ENUM MUST adhere to the Order
field but can simply take the Preference value "on advisement" as
part of a client context specific selection method.
