RFC 6116

The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)

📅 published March 2011, from ietf

RFC 6116: The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM) 🎀

Okay bestie, the title block first! 💅 This one was written by S. Bradner (Harvard University), L. Conroy (Roke Manor Research), and K. Fujiwara (JPRS). It's a Standards Track doc, ISSN 2070-1721, dated March 2011, and it obsoletes RFC 3761. 🦋

Abstract ✨

Okay so this doc is about using the Domain Name System (DNS) to store info tied to E.164 numbers 📞, and to turn those numbers into URIs that can be used (for example) to set up a phone call. It also explains how the DNS can tell you which services are linked to an E.164 number. And yes, this one obsoletes RFC 3761 💖

Status of This Memo 🌸

This is an Internet Standards Track document. 🔥

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

Want the latest on this doc's status, any errata, or how to give feedback? Check http://www.rfc-editor.org/info/rfc6116 🧚

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, since they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 💅

Table of Contents 📖

1. Introduction ....................................................3
   1.1. Terminology ................................................3
2. Use of These Mechanisms for Private Dialing Plans ...............4
3. The ENUM Application Specifications .............................4
   3.1. Application Unique String ..................................4
   3.2. First Well Known Rule ......................................5
   3.3. Expected Output ............................................5
   3.4. Valid Databases ............................................5
        3.4.1. Optional Name Server Additional Section Processing ..6
        3.4.2. Flags ...............................................6
        3.4.3. Service Parameters ..................................7
               3.4.3.1. ENUM Services ..............................7
               3.4.3.2. Compound NAPTRs and Implicit
                        ORDER/PREFERENCE Values ....................8
   3.5. The ENUM Algorithm Always Returns a Single Rule ............8
   3.6. Case Sensitivity in ENUM ...................................8
   3.7. Collision Avoidance ........................................9
4. ENUM Service Example ...........................................10
5. Clarification of DDDS Use in ENUM ..............................10
   5.1. Collected Implications for ENUM Provisioning ..............11
   5.2. Collected Implications for ENUM Clients ...................13
        5.2.1. Non-Terminal NAPTR Processing ......................15
6. IANA Considerations ............................................16
7. Security Considerations ........................................17
   7.1. DNS Security ..............................................17
   7.2. Caching Security ..........................................18
   7.3. Call Routing Security .....................................19
   7.4. URI Resolution Security ...................................19
8. Acknowledgements ...............................................19
9. Changes from RFC 3761 ..........................................19
10. References ....................................................20
    10.1. Normative References .....................................20
    10.2. Informative References ...................................21

1. Introduction ✨

Okay so this section is the main event 🎉 It covers using the Domain Name System (DNS) [RFC1034] [RFC1035] to store data tied to E.164 [E.164] numbers, and to resolve those numbers into URIs that can be used (for example) in telephony call setup. It also explains how the DNS can identify the services linked to an E.164 number. The doc includes a Dynamic Delegation Discovery System (DDDS) Application spec, as detailed in the document series described in [RFC3401]. And yes, this one obsoletes [RFC3761] 💖

Using the process defined here, International Public Telecommunication Numbers in the international format defined in International Telecommunications Union (ITU) Recommendation E.164 [E.164] (called here "E.164 numbers") can be turned into DNS names. Then you can use existing DNS services (like delegation through NS records and queries for NAPTR resource records) to look up the services tied to that E.164 number. It's giving decentralized control and management of the different levels in the lookup process, which is a standard DNS architecture feature 🧚

The domain "e164.arpa" was assigned to give the DNS an infrastructure for storing data associated with E.164 numbers. To keep things distributed, this domain is split into subdomains. Holders of E.164 numbers who want their numbers listed in the DNS should contact the appropriate zone administrator listed in the policy attached to the zone. You start by checking the SOA resource record for the zone, just like normal DNS ops 🌈

Of course, like with other domains, listing policies are 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].

The DNS resource record types mentioned here are defined in [RFC1035] (NS, SOA, A, MX), [RFC3403] (NAPTR), and [RFC2782] (SRV), respectively.

All other capitalized terms are taken from the vocabulary in the DDDS algorithm specification found in [RFC3402]. 🎀

2. Use of These Mechanisms for Private Dialing Plans 🌸

Similar mechanisms might be used for other kinds of digit strings, like numbers in private dialing plans. If these mechanisms are used for dialing plans (or other unrelated digit strings), the domain apex used for that translation MUST NOT be e164.arpa, so it doesn't clash with this spec.

Also, the Application Unique String (see Section 3.1) used with dialing plans SHOULD be the full number as specified, without the leading '+' character. The '+' is what helps tell E.164 numbers in international format apart from dialed digit strings or other digit sequences. 🫶

Here's an example. To address the E.164 number +44-3069-990038, a user might dial:

For example, to address the E.164 number +44-3069-990038 a user
might dial "03069990038" or "00443069990038" or "011443069990038".
These dialed digit strings differ from one another, but none of
them start with the '+' character.

Last thing, and this one's important 🚨 If these techniques are used for dialing plans or other digit strings, implementers and operators of systems using them for that purpose MUST NOT describe these schemes as "ENUM". The initial "E" in ENUM stands for E.164, and the term "ENUM" is used exclusively for applying these techniques to E.164 numbers according to this specification. 💀

3. The ENUM Application Specifications 💖

This template defines the ENUM DDDS Application according to the rules and requirements found in [RFC3402]. The DDDS database used by this Application is found in [RFC3403], which is the doc that defines the NAPTR DNS resource record type.

ENUM is designed as a way to translate E.164 numbers into URIs using NAPTR records stored in DNS. The First Well Known Rule for any ENUM query creates a key (a fully qualified domain name, or FQDN, within the e164.arpa domain apex) from an E.164 number. That FQDN is queried for NAPTR records, and the returned records are processed and interpreted according to this specification. ✨

3.1. Application Unique String 🦋

The Application Unique String (AUS) is a fully qualified E.164 number minus any non-digit characters, except for the '+' character at the beginning of the number. The '+' is kept as a well-understood anchor for the AUS, so it can be told apart from other telephone numbers that aren't part of the E.164 namespace. 🧚

For example, the E.164 number could start out as "+44-116-496-0348". To make sure no syntactic sugar sneaks into the AUS, all non-digits except for '+' are removed, yielding "+441164960348". 💅

3.2. First Well Known Rule 👑

The First Well Known Rule converts an AUS into an initial key. That key is used as an index into the Application's Rules Database. For ENUM, the Rules Database is the DNS, so the key is a fully qualified domain name (FQDN).

To convert the AUS into a unique key in this database, the string is turned into a domain name with this algorithm:

  1. Remove all characters except the digits. For example, given the E.164 number "+44-20-7946-0148" (which would then have been converted into an AUS of "+442079460148"), this step would simply remove the leading '+', producing 442079460148.
  2. Reverse the order of the digits. Example: 841064970244
  3. Put dots ('.') between each digit. Example: 8.4.1.0.6.4.9.7.0.2.4.4
  4. Append the string .e164.arpa. to the end and interpret as a domain name. Example: 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa.

The E.164 namespace and this Application's database are organized so that you can go straight from the name to the smallest granularity of the namespace, so no extra processing is needed to generate the initial key. Iconic design, honestly 😭

This domain name is used to request NAPTR records. Each of these records may contain the end result. Or, if its flags field is empty, it produces a new key in the form of a domain name, which is then used to request further NAPTR records from the DNS. 🌈

3.3. Expected Output 🍓

The output of the last DDDS loop is a Uniform Resource Identifier in its absolute form, according to the <absolute-URI> production in the Collected ABNF found in [RFC3986]. 🎀

3.4. Valid Databases 🗄️

okay so right now there's only one DDDS Database specified for this Application, bestie 💅 "Dynamic Delegation Discovery System (DDDS) Part Three: The DNS Database" [RFC3403] is the one. It stores the rewrite Rules in the NAPTR DNS resource record, and the keys for this database are encoded as domain names.

The substitution expression uses the UTF-8 [RFC3629] character set. The input characters that are allowed are all the characters that are allowed anywhere in an E.164 number. The characters allowed in a key are the ones currently defined for DNS domain names ✨

3.4.1. Optional Name Server Additional Section Processing

some nameservers are lowkey extra and try to be smart about what they stick in the additional information section of a DNS response 🙈 For example, BIND will check whether it is authoritative for a domain whenever it encodes one into a packet. If it is, it will add any A records it finds for that domain to the additional information section of the answer, until the packet hits the maximum length allowed. So it's potentially useful for a client to check that additional information.

it's also easy to imagine an ENUM enhanced nameserver that actually understands the contents of the NAPTR records it serves, and puts more appropriate info into the additional information section of the response. So DNS servers MAY interpret flag values and use that information to include appropriate resource records in the additional information section of the DNS packet 🧚 Clients are encouraged to check for additional information, but they are not required to do so. If you want the full story on NAPTR records and the additional information section of a DNS response packet, see Section 4.2 of [RFC3403] ("Additional Information Processing").

3.4.2. Flags

this Database has a field full of flags that signal when the DDDS algorithm has finished 🚩 Right now only one flag is defined, "U". That means this Rule is the last one, and the output of the Rule is a URI [RFC3986]. See Section 4.3 of [RFC3404].

if a client runs into a resource record with an unknown flag, it MUST ignore it and move on to the next Rule. This test takes precedence over any ordering, because flags can control how the fields are interpreted 🙅‍♀️

a novel flag could change how the Regexp and/or Replacement fields are interpreted, so it might become impossible to tell whether a resource record matched a given target 💀

if this flag is not present, then this Rule is non-terminal. For a non-terminal Rule, the result produced by this rewrite Rule MUST be an FQDN. Clients MUST use this result as the new Key in the DDDS loop (i.e., the client will query for NAPTR resource records at this FQDN) 🔁

3.4.3. Service Parameters

the Service Parameters for this Application are written in Augmented Backus-Naur Form (ABNF, specified in [RFC5234]). They live in the Services field of the NAPTR record that holds a terminal Rule. When the NAPTR holds a non-terminal Rule, the Services field SHOULD be empty, and clients SHOULD ignore its content 🫶

service-field = "E2U" 1*(servicespec)
servicespec   = "+" enumservice
enumservice   = type 0*(subtypespec)
subtypespec   = ":" subtype
type          = 1*32(ALPHA / DIGIT / "-")
subtype       = 1*32(ALPHA / DIGIT / "-")

basically, a required "E2U" (which marks ENUM only Rewrite Rules, to help avoid record collisions) is followed by one or more Enumservices that describe what a given end point can do 🦋 Every Enumservice starts with a '+' character.

3.4.3.1. ENUM Services

Enumservices can be specified and registered through the process defined in "IANA Registration of Enumservices: Guide, Template, and IANA Considerations" [RFC6117]. This registration process is NOT open to any Enumservice that has '-' as the second character in its type string 🚫

it's also not open to Enumservice types that start with the "X-" facet. That facet is reserved for experimental or trial use, and those Enumservices cannot be registered through the normal process 🧪

and then there's the "P-" facet 🔒 Any Enumservice type that starts with it is meant for use exclusively on private networks. So NAPTRs with Enumservice types starting "P-" should not be seen on the global Internet. Even if an ENUM client recognizes the Enumservice and can engage in it, the client may not be able to resolve the URI generated by the containing NAPTR. These Enumservices WILL NOT be registered.

such Enumservices MUST NOT be provisioned in any system that answers DNS queries for NAPTR resource record sets (RRSets) from entities outside the private network context they are meant for. Unless an ENUM client is sure it is connected to the private network these NAPTRs were provisioned and intended for, it MUST discard any NAPTR with an Enumservice type that starts with the "P-" facet 🙅‍♀️

3.4.3.2. Compound NAPTRs and Implicit ORDER/PREFERENCE Values

a single NAPTR can have more than one Enumservice attached to it 🍓 Those Enumservices share the same Regexp field, so they generate the same URI. This kind of "compound" NAPTR could easily be used for a mobile phone that supports both "voice:tel" and "sms:tel" Enumservices. In that case, the Services field would be "E2U+voice:tel+sms:tel".

a compound NAPTR can be treated as a set of NAPTRs that each hold a single Enumservice. These reconstructed NAPTRs share the same ORDER and PREFERENCE/PRIORITY field values, but each should be treated as if it had a logically different priority. A left-to-right priority is assumed 👑

3.5. The ENUM Algorithm Always Returns a Single Rule

the ENUM algorithm always returns a single Rule ✨ Individual applications may have application-specific knowledge or facilities that let them present multiple results or speed up selection, but those should never change how the algorithm operates.

3.6. Case Sensitivity in ENUM

okay, the tea ☕ Case sensitivity was not mentioned at all in [RFC3761] (or [RFC2916]), but it has been seen as an issue during interoperability test events ever since. There are a lot of case-sensitive clients out in the wild.

the only place where NAPTR field content is case sensitive is in static text in the Repl sub-field of the Regexp field (see Section 3.2 of [RFC3402] for Regexp field definitions). In that sub-field, case must be preserved when the record output is generated. Everywhere else, case sensitivity is not used 🌈

where ENUM clients can be exposed to NAPTR records whose field content has different capitalization, clients MUST use case-insensitive processing. ENUM clients that use the Internet to send their queries, typically called "Public ENUM" scenarios, fall into this category 🌸

some ENUM clients work inside closed networks, like isolated data networks run by Communication Service Providers. These are typically called "Infrastructure ENUM" scenarios. All zones provisioned within these closed networks usually have a known capitalization for ENUM record string content, since provisioning systems for these networks are often carefully controlled. In that kind of environment, clients are never exposed to records with "unexpected" capitalization, so they can be (and have been) designed with case-sensitive processing 💅 Only if a client is known to operate in an environment where the capitalization of every ENUM record it will encounter is known and controlled MAY that client use case-sensitive processing.

3.7. Collision Avoidance

an ENUM-compliant application MUST only pass numbers to the ENUM client query process that it believes are E.164 numbers (e.g., it MUST NOT pass dialed digit strings to the ENUM query process) 📞

number plans can change over time, so it can be impossible for a client to know whether the number it wants to query is assigned and active within the current number plan 🤷‍♀️ That's why it's important that such clients can tell data tied to the E.164 number plan apart from data tied to other digit strings (i.e., numbers NOT in accordance with the E.164 number plan).

it's the job of operators provisioning data into domains to make sure that data associated with a query on an E.164 number cannot be mistaken for data associated with other uses of NAPTRs 🛡️ Three techniques are used to achieve this:

  • the domain apex used for purposes other than data associated with the E.164 number plan MUST NOT be e164.arpa.
  • for use other than with E.164 numbers, the Application Unique String MUST NOT begin with the '+' character, whilst for ENUM use, the AUS MUST begin with this character.
  • NAPTRs that are intended for other DDDS applications MUST NOT include the E2U token in their service field, whilst NAPTRs intended for ENUM use MUST include this token.

4. ENUM Service Example ✨

okay, time for the fun part 🎀 Here's what an ENUM service looks like in DNS master file syntax:

      $ORIGIN 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa.
       NAPTR 100 50 "u" "E2U+sip"
           "!^(\\+441632960083)$!sip:\\1@example.com!"    .
       NAPTR 100 51 "u" "E2U+h323"
           "!^\\+441632960083$!h323:operator@example.com!"    .
       NAPTR 100 52 "u" "E2U+email:mailto"
           "!^.*$!mailto:info@example.com!"    .

so this says the domain 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa. is preferably contacted by SIP, then secondly via H.323 for voice, and thirdly by SMTP for messaging 📱 Note that the Enumservice tokens "sip", "h323", and "email" are Enumservice Types registered with IANA, and they have no implicit connection to the protocols or URI schemes that share those names 🙃

in all cases, the next step in the resolution process is to use the resolution mechanism for each protocol (specified by the URI schemes sip, h323, and mailto) to figure out which node to contact 🧭

in each of the first two records, the ERE sub-field only matches queries made for the telephone number +441632960083. The last record's ERE matches any Application Unique String value. The first record also shows how the matched pattern can be used in the generated URI 💜

heads up, bestie ⚠️ where NAPTR resource records are shown in DNS master file syntax (like in the example above), each backslash has to be escaped with a second backslash. The DNS on-the-wire packet only has a single backslash in each case.

5. Clarification of DDDS Use in ENUM

ENUM is a DDDS Application, which means it relies on the DDDS for its operation 🦋 DDDS is designed to be flexible, but that opens the door to differences of interpretation. This section covers ENUM-specific interpretation of text within the DDDS specifications. The goal is to make sure ENUM clients and provisioning systems used to populate domains with E2U NAPTRs can actually interoperate 🫶

as part of ongoing development work on the ENUM specifications, [RFC5483] gives an (informative) analysis of how ENUM client and provisioning system implementations behave, and the interoperability issues that have come up. The following recommendations reflect that analysis, and you can find more narrative explaining the issues in that RFC 🌟

5.1. Collected Implications for ENUM Provisioning 💅

okay so ENUM NAPTRs SHOULD NOT include characters outside the printable US-ASCII equivalent range (U+0020 to U+007E) unless it's clear that all the ENUM clients they're designed for can handle those characters properly 🎀 if ENUM zone provisioning systems need non-ASCII characters, these systems MUST encode the non-ASCII data so they only emit US-ASCII characters, using an appropriate mechanism (like the ones in [RFC3492], [RFC3987]) ✨ non-printable characters SHOULD NOT be used either, because ENUM clients may need to show NAPTR content to a human 👀

the case-sensitivity flag ('i') is literally not it for ENUM 🙅‍♀️ it SHOULD NOT be provisioned into the Regexp field of E2U NAPTRs

the Registrant and the ENUM zone provisioning system they use SHOULD NOT rely on ENUM clients looking only at the ORDER and PREFERENCE/PRIORITY fields in ENUM NAPTRs 💖 so a Registrant SHOULD only put contacts in their zone that they're actually willing to support, because even the ones with the worst ORDER and PREFERENCE/PRIORITY values MAY be selected by an end user 😭

all E2U NAPTRs SHOULD hold a default value in their ORDER field 🌸 a value of "100" is recommended, since it seems to be what most provisioned domains use 🦋

Some ENUM clients have been known to pre-discard NAPTRs in an RRSet just because those records don't have the lowest ORDER value in that RRSet 💀 other ENUM client implementations seem to have mixed up the ORDER and PREFERENCE/PRIORITY fields, using the latter as the major sort term instead of the former like it's supposed to be 🙈 and the opposite has happened too: some ENUM zones have the ORDER value changing while the PREFERENCE/PRIORITY value stays the same. That might have been on purpose, but since clients act differently when the ORDER values vary, it might not give the result you want 🧚

multiple NAPTRs with identical ORDER and identical PREFERENCE/PRIORITY field values SHOULD NOT be provisioned into an RRSet unless the whole point is that these NAPTRs are truly identical and there's no preference between them 🫶 and implementers SHOULD NOT assume the DNS will hand back NAPTRs within an RRSet in any particular sequence 🌈

an ENUM zone provisioning system SHOULD assume that, if it generates compound NAPTRs, the Enumservices will normally get processed in left-to-right order within those NAPTRs 🍓

ENUM zone provisioning systems SHOULD also assume that once a non-terminal NAPTR has been selected for processing, the ORDER field value in the domain that non-terminal NAPTR points to will only be looked at within that referenced domain (that is, the ORDER value is only used to sort within the current RRSet and doesn't get used when processing NAPTRs in any other RRSet) 👑

ENUM zone provisioning systems SHOULD use '!' (U+0021) as their Regexp delimiter character ⭐

if the Regexp delimiter shows up as 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 [RFC3402] (that is, "\!", U+005C U+0021) 🔥 and note that when a NAPTR resource record is written in DNS master file syntax, the backslash itself has to be escaped with a second backslash 🙌

if the literal character '+' is present in the ERE sub-field of an ENUM NAPTR, it MUST be escaped as "\+" (that is, U+005C U+002B) 💅 same deal as always: when a NAPTR resource record is entered in DNS master file syntax, the backslash itself must be escaped using a second backslash 🫶

Whilst this client behavior 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 about using multiple back-reference patterns in the Repl sub-field of the NAPTRs they provision 🥺 some clients have limited buffer space for character expansion when they generate URIs, so these provisioning systems SHOULD check the back-reference replacement patterns they use and make sure regular expression processing won't produce excessive-length URIs 🌸

ENUM zones MUST NOT be provisioned with NAPTRs that use the obsolete syntax of [RFC2916], and they MUST be provisioned with NAPTRs where the Services field follows Section 3.4.3 of this document 💖

[RFC2915] and [RFC2916] have been obsoleted by [RFC3401]-[RFC3404] and by this document, respectively ✨

Enumservices where the Enumservice type starts with the facet "P-" MUST NOT be provisioned in any system that answers DNS queries for NAPTR resource record sets from entities outside the private network context those Enumservices are meant for 🔒

as current support is limited, non-terminal NAPTRs SHOULD NOT be provisioned in ENUM zones unless it's clear that every ENUM client this environment supports can process them 🧚‍♀️

when populating a set of domains with NAPTRs, ENUM zone provisioning systems SHOULD NOT configure non-terminal NAPTRs so that more than 5 of them will be processed in an ENUM query 🎀

in a non-terminal NAPTR that might get encountered in an ENUM query (that is, 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, because this field gets read as the FQDN that forms the next key output from this non-terminal Rule 👑 and the Regexp field MUST be empty in a non-terminal NAPTR meant to be encountered during an ENUM query 🌈

5.2. Collected Implications for ENUM Clients 🦋

if a NAPTR gets discarded, this SHOULD NOT cause the whole ENUM query to end, and processing SHOULD continue with the next NAPTR in the returned RRSet 💖

ENUM clients SHOULD NOT discard NAPTRs where they spot 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 with byte values outside the US-ASCII equivalent range (that is, byte values above 0x7F) 🙈 but clients MUST be ready to encounter NAPTRs with such values without failing 💪

ENUM clients MUST sort the records of a retrieved NAPTR RRSet into sequence using the ORDER and PREFERENCE fields of those records 💅 ORDER is the major sort term, with the lowest numerical values coming earlier in the sequence, and PREFERENCE/PRIORITY is the minor sort term, also with the lowest numerical values coming earlier in the sequence 👑

ENUM clients SHOULD NOT discard a NAPTR record until it's considered, or a record before it in the evaluation sequence has been accepted ✨

Notably, if a record has a "worse" ORDER value than others in this RRSet, that record MUST NOT be discarded before consideration unless a record has been accepted as the result of this ENUM query 😭

where the ENUM client shows the end user a list of possible URLs to pick from, it MAY present all NAPTRs, not just the ones with the lowest currently unprocessed ORDER field value 🎀 the client SHOULD still observe the ORDER and PREFERENCE/PRIORITY values the Registrant specified 🫶

ENUM clients SHOULD accept all NAPTRs with identical ORDER and identical PREFERENCE/PRIORITY field values, and process them in the sequence they appear in the DNS response 🍓 (there's no point in randomizing the order again, since intervening DNS Servers might have already done it 🙄)

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 traversing non-terminal NAPTR references 🌈

ENUM clients receiving compound NAPTRs (that is, ones with more than one Enumservice) SHOULD process these Enumservices using a left-to-right sort ordering, so the first Enumservice processed is the leftmost one and the last is the rightmost one 💖

ENUM clients MUST be ready to process NAPTRs that use a different character from '!' as their Regexp Delimiter without failing 🔥

ENUM clients SHOULD NOT assume the delimiter is the last character of the Regexp field 👀

Unless they're sure that this is the case in their environment, an ENUM client may still encounter NAPTRs that have been provisioned with a following 'i' (case-insensitive) flag, even though that flag has no effect at all in an ENUM scenario 💅

ENUM clients SHOULD discard NAPTRs that have more or fewer than 3 unescaped instances of the delimiter character within the Regexp field 🙅‍♀️

Being liberal with what you accept is the spirit here 🌷 so if the ENUM client is sure how the Regexp field should be interpreted, it MAY choose to process the NAPTR even with an incorrect number of unescaped delimiter characters. If it's not clear how the Regexp field should be interpreted, the client MUST discard the NAPTR 😤

ENUM clients MUST be ready to process NAPTRs that have non-trivial patterns in their ERE sub-field values without failing 🧚‍♀️

ENUM clients MUST be ready to process NAPTRs with many copies of back-reference patterns within the Repl sub-field without failing 🎀

ENUM clients MUST be ready to process NAPTRs with a DDDS Application identifier other than 'E2U' without failing 🌈

when an ENUM client runs into a compound NAPTR (that is, one containing more than one Enumservice) and can't process or recognize one of the Enumservices in it, that ENUM client SHOULD ignore that Enumservice and carry on with the next Enumservice in this NAPTR's Services field 🍓 it should only discard the NAPTR if it can't handle any of the Enumservices it contains 🫶 and these conditions SHOULD NOT be considered errors 💖

ENUM clients MUST support ENUM NAPTRs according to the syntax defined in Section 3.4.3 🌸 ENUM clients SHOULD also support ENUM NAPTRs using the obsolete syntax of [RFC2916], because there are still zones holding "old" syntax NAPTRs 🙈 the informational [RFC3824] recommended that kind of support 📚

unless an ENUM client is sure it's connected to the private network these NAPTRs are provisioned for and intended for, it MUST discard any NAPTR with an Enumservice type that starts with the "P-" facet 🔒

5.2.1. Non-Terminal NAPTR Processing 🔀

Okay bestie, first up: ENUM clients MUST be ready to process NAPTRs with an empty Flags field (the "non-terminal" NAPTRs) without failure 💀 Like, no crashing allowed. More generally, non-terminal NAPTR processing SHOULD be implemented, but ENUM clients MAY discard non-terminal NAPTRs they run into. Super flexible, but the no-crash part is non-negotiable 💅

ENUM clients SHOULD ignore any content of the Services field when they hit a non-terminal NAPTR with an empty Flags field. It's giving "don't read what doesn't apply to you" 🙈

Now the big one 👑 ENUM clients receiving a non-terminal NAPTR with an empty Flags field MUST treat the Replacement field as holding the FQDN 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 FQDN. By definition, the Regexp field will be empty in such a non-terminal NAPTR, so it's kind of a built-in vibe check 🫶 If a non-empty Regexp field somehow shows up in a non-terminal NAPTR, ENUM clients MUST ignore it. Not me being dramatic, but yes, ignore it 🙅‍♀️

Okay, when a problem pops up while you're processing an ENUM query across multiple domains (by following non-terminal NAPTR references), the ENUM query SHOULD NOT be abandoned 😭 Instead, processing SHOULD continue at the next NAPTR after the non-terminal NAPTR that referred to the domain where the problem would have happened. Keep going, queen 🌸

If all NAPTRs in a domain you traversed because of a reference in a non-terminal NAPTR have been discarded, the ENUM client SHOULD continue its processing with the next NAPTR in the "referring" RRSet (aka the one that includes the non-terminal NAPTR that caused the traversal) 🦋

Referential loops are a whole thing 🌀 ENUM clients MUST be prepared to encounter a referential loop, where a sequence of non-terminal NAPTRs gets retrieved within an ENUM query and they refer back to an earlier FQDN. ENUM clients MUST be able to detect and recover from such a loop, without failure. Literally the drama of the DNS world 🎭

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. Five is the magic number here, babe ✨

When a domain is about to be entered because of a reference in a non-terminal NAPTR, and the ENUM client has detected a potential referential loop, the client SHOULD discard that non-terminal NAPTR from its processing and continue with the next NAPTR in its list. It SHOULD NOT make the DNS query that the non-terminal NAPTR indicated. Dodge the loop, don't walk into it 🙅‍♀️💖

6. IANA Considerations 🌈

RFC 2916 and then RFC 3761 (which this document replaces) asked IANA to delegate the E164.ARPA domain, following the instructions the IAB gave (as described in [RFC3245]). The domain was delegated according to those instructions, which are published at <http://www.ripe.net/data-tools/dns/enum/iab-instructions> 📜

Names in this zone are to be delegated to parties consistent with ITU Recommendation E.164. The names allocated should be hierarchic in accordance with ITU Recommendation E.164, and the codes should be assigned in accordance with that Recommendation. Organisation is everything 🍓

The IAB is to coordinate with the ITU Telecommunications Standardization Bureau (TSB) if the technical contact for the domain e164.arpa is going to change, because ITU TSB has an operational working relationship with this technical contact that would need to be re-established. Relationships are fragile, we get it 🫶

See [RFC6117] for Enumservice-related IANA Considerations. Go read that one next 🧚

7. Security Considerations 🔐

Heads up, this part is serious, so let's go 😤

7.1. DNS Security

ENUM uses DNS, which in its current form is an insecure protocol, so there's no mechanism for making sure the data you get back is authentic 💀 As ENUM gets deployed on the global Internet, it's expected to be a popular target for all kinds of attacks, and attacking the underlying DNS infrastructure is one way to attack the ENUM service itself. Main character villain arc energy 🦹‍♀️

There are multiple types of attacks against DNS that ENUM implementations should consider. See Threat Analysis of the Domain Name System [RFC3833] for a review of the various threats to DNS 📚

Because of these threats, a deployed ENUM service SHOULD include mechanisms to mitigate them. Most of these threats can be solved by verifying the authenticity of the data with mechanisms like DNS Security (DNSSEC) [RFC4033] ✅

Others, like Denial-Of-Service attacks, can't be solved by data authentication 😩 And these threats don't only target the NAPTR lookups themselves, they also hit the various records needed for the services to be useful (for example NS, MX, SRV, and A records). The whole buffet is at risk 🍽️

Even with DNSSEC deployed, it can't protect against every kind of attack on DNS. ENUM is often used for number or address translation, and retrieving an address through an ENUM lookup with DNSSEC support does not, however, make the service immune to attack. It's unwise for a service to blindly trust that the address it retrieved is valid, and that the entity it connects to using that address is the service peer it meant to contact 🚨 A service SHOULD always authenticate the entity it connects to during the service setup phase, and not rely on address or identity data retrieved outside that service. Trust but verify, bestie 🫶

Finally, since an ENUM service will be implementing some type of security mechanism, software that implements ENUM MUST be prepared to receive DNSSEC and other standardized DNS security responses. That includes large responses and other EDNS0 signaling (see [RFC2671]), unknown resource records (see [RFC3597]), and so on. Be ready for everything, periodt 💅

7.2. Caching Security

The DNS architecture leans heavily on caching records at intermediary nodes to improve performance ⚡ The propagation time (for changes to resource records to show up in query responses at end nodes) approaches the "time to live" value for those records. There may be a bunch of different resource records involved in resolving a communication target. Changes to these records may not be synchronised (especially if they indicate different times to live), so a change in any one of them may cause inappropriate decisions about communication targets. And since DNS Update (specified in [RFC2136]) can cause pretty rapid content changes in different zones, these transient states can become important 😵‍💫

Let's look at a typical set of queries that follow an ENUM query returning a SIP URI (for details, see [RFC3263]):

  • Evaluating the SIP URI triggers a query on the SIP domainpart for D2U/D2T NAPTRs.
  • That in turn triggers a query on that record's target domain for SRV records.
  • The SRV records will return the SIP server hostname, which triggers a further query on that hostname for an A record to get the server's associated IP address.
  • Finally, the local SIP User Agent Client attempts to start a communications session to that IP address.

The E2U NAPTR may have changed its URI, indicating a new SIP identity 🫠 The D2U NAPTR for the SIP URI domainpart may have changed its target. The SRV record pointed to by that D2U NAPTR may have changed its target hostname. The hostname's A record may have changed its IP address. And if the server lives in an environment where IP addresses are dynamically assigned (for example, when using DHCP [RFC2131]), an unexpected end point may have been allocated to the IP address returned from the SIP resolution chain. Chaos, but make it DNS 🌪️

In environments where changes to any part of the chain of resource records, or dynamic assignments to IP addresses, happen, the systems provisioning this data SHOULD take care to minimise changes and to consider the respective times to live of resource records and/or DHCP lease times. Users of this data SHOULD take care to detect and recover from unintended communications session attempts, since in a transient environment these may occur 🧠

7.3. Call Routing Security

There are a number of countries (and other numbering environments) with multiple providers of call routing and number/name-translation services 🌍 In these areas, any system that lets users, or putative agents for users, change routing or supplier information may give incentives for changes that are actually unauthorised (and, in some cases, for denial of legitimate change requests). Such environments should be designed with adequate mechanisms for identifying and authenticating those requesting changes, and for authorising those changes. Gatekeeping is a whole vibe 🔒

7.4. URI Resolution Security

A large amount of security issues have to do with the resolution process itself, and with the use of the URIs produced by the DDDS mechanism 🕵️‍♀️ Those have to be specified in the registration of the Enumservice used, as specified in "IANA Registration of Enumservices: Guide, Template, and IANA Considerations" [RFC6117]. Check the paperwork, it matters 📝

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. The authors would also like to thank Alfred Hoenes and Bernie Hoeneisen for their detailed reviews. Shoutout to the reviewers, they're the real MVPs 🏆

9. Changes from RFC 3761 🔄

A section has been added to explain the way DDDS is used with this specification. These recommendations were collected from experience of ENUM deployment 🛠️ Differences in how people interpreted the DDDS specifications led to interoperability issues, so this document updates RFC 3761 to add many clarifications, intended to help interoperability.

The clarifications include a default value for the ORDER field and for the Regexp delimiter character, required use of the Replacement field in non-terminal NAPTRs, and that string matching is case insensitive (Section 3.6). Iconic upgrades only ✨

Other substantive changes include removing the discussion of registration mechanisms (now specified in "IANA Registration of Enumservices: Guide, Template, and IANA Considerations" [RFC6117]), correcting an existing error by adding "-" as a valid character in the type and subtype fields specified in Services Parameters (Section 3.4.3), and adding the "P-" private service type (Section 3.4.3.1). Glow-up era 🦋

10. References 📚

10.1. Normative References 📚✨

okay bestie, these are the receipts 🧾 Normative means you need these to actually get the spec, and they're all right here.

  • [E.164] ITU-T, "The International Public Telecommunication Number Plan", Recommendation E.164, February 2005.
  • [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
  • [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.
  • [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.
  • [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 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.
  • [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
  • [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
  • [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.

10.2. Informative References 🌸

these ones are the bonus content 💅 super worth a read if you want the full story, but you don't need them to get the spec 🫶

  • [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
  • [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
  • [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
  • [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
  • [RFC2915] Mealling, M. and R. Daniel, "The Naming Authority Pointer (NAPTR) DNS Resource Record", RFC 2915, September 2000.
  • [RFC2916] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000.
  • [RFC3245] Klensin, J., Ed., and IAB, "The History and Context of Telephone Number Mapping (ENUM) Operational Decisions: Informational Documents Contributed to ITU-T Study Group 2 (SG2)", RFC 3245, March 2002.
  • [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
  • [RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002.
  • [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003.
  • [RFC3824] Peterson, J., Liu, H., Yu, J., and B. Campbell, "Using E.164 numbers with the Session Initiation Protocol (SIP)", RFC 3824, June 2004.
  • [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.
  • [RFC5483] Conroy, L. and K. Fujiwara, "ENUM Implementation Issues and Experiences", RFC 5483, March 2009.
  • [RFC6117] Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA Registration of Enumservices: Guide, Template, and IANA Considerations" RFC 6117, March 2011.

Authors' Addresses 🦋

meet the people who made this happen 🎀 here's how to reach them

   Scott Bradner
   Harvard University
   29 Oxford St.
   Cambridge MA 02138
   USA

   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://lawrence.tel


   Kazunori Fujiwara
   Japan Registry Services 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/
📦 where this page comes from