RFC 3761

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

📅 published April 2004, from ietf

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

okay bestie, this is RFC 3761 🎀 and it's giving phone numbers meet the DNS 📞✨ It was written by P. Faltstrom (Cisco Systems, Inc.) and M. Mealling (VeriSign) in April 2004. It's a Standards Track document 🦋 and it obsoletes RFC 2916 💅

Status of this Memo

This is an Internet standards track protocol for the Internet community 🌈 The authors want discussion and suggestions for improvements, so bring your ideas 🫶 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚 Distribution of this memo is unlimited 🍓

Copyright (C) The Internet Society (2004). All Rights Reserved. 💜

Abstract

Okay so this doc is all about using the Domain Name System (DNS) to store E.164 numbers 📞🧚 It's specifically about how DNS can help you find which services are connected to one E.164 number, and it's giving main character energy because it obsoletes RFC 2916 to match the Dynamic Delegation Discovery System (DDDS) Application spec in the document series from RFC 3401 🎀 Real talk: you literally cannot understand this one without reading the RFC 3401 docs first 😭📚

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
       1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . .  3
       1.2. Use for these mechanisms for private dialing plans. . . .  3
       1.3. Application of local policy . . . . . . . . . . . . . . .  3
   2.  The ENUM Application Specifications .  . . . . . . . . . . . .  4
       2.1. Application Unique String . . . . . . . . . . . . . . . .  5
       2.2. First Well Known Rule . . . . . . . . . . . . . . . . . .  5
       2.3. Expected Output . . . . . . . . . . . . . . . . . . . . .  5
       2.4. Valid Databases . . . . . . . . . . . . . . . . . . . . .  5
            2.4.1. Flags. . . . . . . . . . . . . . . . . . . . . . .  6
            2.4.2. Services Parameters. . . . . . . . . . . . . . . .  7
       2.5. What constitutes an 'Enum Resolver'?. . . . . . . . . . .  8
   3.  Registration mechanism for Enumservices .  . . . . . . . . . .  8

       3.1. Registration Requirements . . . . . . . . . . . . . . . .  8
            3.1.1. Functionality Requirement. . . . . . . . . . . . .  8
            3.1.2. Naming requirement . . . . . . . . . . . . . . . .  9
            3.1.3. Security requirement . . . . . . . . . . . . . . .  9
            3.1.4. Publication Requirements . . . . . . . . . . . . . 10
       3.2. Registration procedure. . . . . . . . . . . . . . . . . . 10
            3.2.1. IANA Registration. . . . . . . . . . . . . . . . . 10
            3.2.2. Registration Template. . . . . . . . . . . . . . . 11
   4.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
       4.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 11
   5.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 12
   6.  Security Considerations. . . . . . . . . . . . . . . . . . . . 12
       6.1. DNS Security. . . . . . . . . . . . . . . . . . . . . . . 12
       6.2. Caching Security. . . . . . . . . . . . . . . . . . . . . 14
       6.3. Call Routing Security . . . . . . . . . . . . . . . . . . 14
       6.4. URI Resolution Security . . . . . . . . . . . . . . . . . 15
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
   8.  Changes since RFC 2916 . . . . . . . . . . . . . . . . . . . . 15
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
       9.1. Normative References. . . . . . . . . . . . . . . . . . . 16
       9.2. Informative References. . . . . . . . . . . . . . . . . . 16
   10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
   11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 18

1. Introduction ✨

This doc is about using DNS to store E.164 numbers 📞 Specifically, it covers how DNS can tell you which services are available for one E.164 number 🎀 It obsoletes RFC 2916 so it lines up with the DDDS Application spec in the RFC 3401 series [6] 💅 And yes, it's very important that you read the RFC 3401 docs [6] first, because this one won't make sense without them 😭

So here's the vibe: you take an International Public Telecommunication Number in the international format [5] (these are the "E.164 numbers" in this doc) and turn it into DNS names 🧚 Then you use the DNS stuff that already exists, like delegation through NS records and NAPTR records, to look up what services a specific E.164 number has 🌸 The best part is that it's decentralized, so the management is spread across the different levels of the lookup process 🦋

The domain "e164.arpa" is being filled in to build the DNS infrastructure for E.164 numbers 🌈 To keep operations distributed, that domain gets split into subdomains 🫶 If you hold an E.164 number and want it listed in DNS, you should contact the right zone administrator for that zone's policy 💖 To start, look at the SOA resource record for the zone, just like in regular DNS 🍓

Obviously, every domain has its own rules, and listing policies get controlled per subdomain, so they can be different 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] 💜

Every other capitalized term comes from the vocabulary in the DDDS algorithm spec, RFC 3403 [2] 🎀

1.2. Use for these mechanisms for private dialing plans 🔐

This doc describes how these mechanisms work for numbers allocated under the ITU-T recommendation E.164 📞 But fun twist: the same mechanisms might be reused for private dialing plans 🧚 If you do reuse them, the suffix for your private dialing plan MUST NOT be e164.arpa, so you don't clash with this spec 😭 The parties in that private plan will need to know their own suffix to make everything work correctly 💅 Also, the application unique string SHOULD be the full number as specified, just without the leading '+' 🦋 And that private use MUST NOT be called "ENUM" 🙈

1.3. Application of local policy 👑

The Order field in the NAPTR record says what order the DNS records should be read in 🌸 That's needed because DNS doesn't guarantee the order of records in the answer section of a packet ✨ In most ENUM cases this isn't a problem, since the usual regular expression is !^.*$! (the first query often gives you a terminal Rule) 💖

BUT there are also non-terminal Rules, where two different Rules both match the same Application Unique String 💀 Each Rule gets evaluated as part of the algorithm, and one might match a bigger chunk of the AUS than the other 🎀 Here's an example: a non-terminal NAPTR sends a set of numbers to some private-dialing-plan zone 🧚 In that zone, there are two Rules saying that if the match is for the entire exchange and the service is SIP-related, use the first SIP-specific rule 🦋 The other Rule matches a longer piece of the AUS and says that for another service (instant messaging) the Rule is a departmental-level service 🌈 If the shorter match comes first, it can "mask" the other rules 😭 So the order each Rule gets tested against the AUS is an important corner case that lots of DDDS apps depend on 👑

If the zone authority wants to say two Rules do the same thing or are identical in usage, they set the same Order value for those records 💅 Then the Preference is used as a locally overridable suggestion from the zone authority, saying one Rule might just be a bit better than another for some reason 🍓

For ENUM, this is where a client is allowed to apply local policy, and where it isn't 🫶 The Order field in the NAPTR is a request from the E.164 number holder asking for the records to be handled in a specific way 🔥 The Preference field is only a suggestion from that holder that one record might be better than another 💜 A client implementing ENUM MUST adhere to the Order field, but it can just take the Preference value "on advisement" as part of a client-context-specific selection method ✨

2. The ENUM Application Specifications 💎

This template defines the ENUM DDDS Application using the rules and requirements in [7] 📋 The DDDS database this Application uses is in [2], which is the doc that defines the NAPTR DNS Resource Record type 🎀

ENUM is only for E.164 numbers 📞 ENUM-compliant applications MUST only query DNS for what they believe is an E.164 number 🫶 The thing is, there are loads of dialing plans that change over time, so a client app probably can't have perfect knowledge of every valid and dialable E.164 number 😭 So even if a client does everything it can, it might end up with a number that looks syntactically correct but isn't actually valid or dialable 💀 That means applications MAY send DNS queries when, for example, a user mistypes a number in the UI 🧚 Because of that, collisions between E.164 numbers and non-E.164 numbers are a real risk 🔥 To reduce that 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 (AUS) is a fully qualified E.164 number with all non-digit characters removed, except for the '+' at the beginning 🦋 That "+" is kept as a well-understood anchor, so the AUS can be told apart from other telephone numbers that aren't in the E.164 namespace 🌸

For example, an E.164 number might start out as +44-116-496-0348 📞 To make sure no syntactic sugar sneaks into the AUS, every non-digit except "+" gets removed, giving +441164960348 💖

2.2. First Well Known Rule 🌟

The First Well Known Rule for this Application is the identity rule 🎀 Its output is the same as its input 🫶 That works because the E.164 namespace and this Application's databases are organized so you can go straight from the name to the smallest granularity of the namespace, using the name itself 🧚

Using the earlier example, the AUS is +441164960348, and applying the First Well Known Rule gives you 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, matching the 'absoluteURI' production in the Collected ABNF found in RFC2396 [4] 💅🌈

2.4. Valid Databases 💅✨

Okay so, right now there's only one DDDS Database specified for this Application, and it's giving main character energy 👑. "Dynamic Delegation Discovery System (DDDS) Part Three: The DNS Database" (RFC 3403) [2] is the one. It uses the NAPTR DNS resource record to hold the rewrite rules 🎀, and the Keys in this database are encoded as domain-names 🦋.

The output of the First Well Known Rule for the ENUM Application is the E.164 number with every non-digit character removed, except for the +. To turn that into a unique key in this Database, the string gets converted into a domain-name using this algorithm. It's so step-by-step, I'm obsessed 🧚:

  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. Those records might hold the end result, or, if the flags field is blank, they produce new keys in the form of domain-names from the DNS 🌸.

Some nameserver implementations get a little too clever about what they stick into the additional information section of a DNS response 🙈. For example, BIND will check whether it's authoritative for a domain whenever it encodes one into a packet. If it is, it will insert any A records it finds for that domain into the additional information section of the answer, until the packet hits the maximum allowed length. So it's potentially useful for a client to check for this extra info. It's also easy to imagine an ENUM enhanced nameserver that actually understands the contents of the NAPTR records it's serving, and then slips more appropriate info into the additional information section. 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 they are not required to do so. For more on NAPTR records and the Additional Information section of a DNS response packet, see the Additional Information Processing section of RFC 3403 [2], Section 4.2.

The character set used to encode the substitution expression is UTF-8 🌈. The allowed input characters are all of the characters that are allowed anywhere in an E.164 number. The characters allowed to be in a Key are the ones currently defined for DNS domain-names.

2.4.1. Flags 🚩

This Database has a field full of flags that signal when the DDDS algorithm has finished. Right now only one flag is defined, and that's U. It means this Rule is the last one, and that the output of the Rule is a URI [4]. See RFC 3404 [3].

If a client runs into a record with an unknown flag, it MUST ignore it and move on 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, so much that it becomes impossible to determine whether a record matched a given target. Yikes 😭.

If this flag is not present, then the 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. In other words, the client queries 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 they're 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)

Basically, you need a non-optional "E2U" (which is used to flag ENUM only Rewrite Rules, so records don't collide 🫶), followed by 1 or more Enumservices. Those tell you what class of functionality a given end point offers. Every Enumservice starts with an initial '+' character.

2.4.2.1. ENUM Services 🌟

Enumservice specifications cover the functional specification (aka what it can be used for), the valid protocols, and the URI schemes that may be returned. Heads up: there's no implicit mapping between the textual strings "type" or "subtype" in the Enumservice grammar and URI schemes or protocols. Any mapping, if there is one, 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. Those have to start with the facet "X-". They're unregistered and experimental, and they should be used only with the active agreement of the parties exchanging them 🧪.

The registration mechanism is specified in Section 3 ✨.

2.5. What constitutes an 'Enum Resolver'? 🤔

There's been some confusion over what exactly an ENUM Resolver returns, and how that relates to the 'Note 1' section in RFC 3402. On first reading, it seems like an ENUM Resolver might be able to return two Rules 😵‍💫.

Here's the tea: the ENUM algorithm always returns a single rule. Specific 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 works 💖.

3. Registration mechanism for Enumservices 📝✨

As specified in the ABNF found in Section 2.4.2, an 'enumservice' is made up of 'types' and 'subtypes'. For any given 'type', the allowable 'subtypes' must be specified in the registration. Right now there's no such thing as a registered 'subtype' outside the scope of a given 'type'. So the registration process uses the 'type' as its main key within the IANA Registry 🗂️. The combination of each type and all of its subtypes is the allowed set of values for the 'enumservice' field, but just documenting those values isn't enough. A complete registration also includes the allowed URI schemes, a functional specification, security considerations, intended usage, and any other information needed for interoperability within ENUM. To become a registered ENUM Service, the entire specification (template included) needs approval by the IESG, and the Enumservice registration specification has to be published as an RFC 🎀.

3.1. Registration Requirements 📋

Service registration proposals are all expected to conform to the various requirements laid out in the following sections 💅.

3.1.1. Functionality Requirement ⚙️

A registered Enumservice MUST be able to function as a selection mechanism when choosing one NAPTR resource record from another. That means the registration MUST specify what's expected when using that very NAPTR record, and the URI that comes out of using it 🎯.

Specifically, a registered Enumservice MUST specify the URI scheme(s) that may be used for the Enumservice. When needed, it also has to specify other information that gets carried into the URI resolution process itself, like LDAP Distinguished Names, or transferring the AUS into the resulting URI, etc 🧩.

3.1.2. Naming requirement 🏷️

An Enumservice MUST be unique in order to be useful as a selection criteria. Since an Enumservice is made up of a type and a type-dependent subtype, it's enough to require that the 'type' itself be unique. The 'type' MUST be unique, MUST conform to the ABNF specified in Section 2.4.2, and MUST NOT start with the facet "X-", which is reserved for experimental, private use 🔒.

The subtype depends on the type, so it MUST be unique within a given 'type'. It must conform to the ABNF specified in Section 2.4.2, and it MUST NOT start with the facet "X-", which is reserved for experimental, private use. The subtype for one type MAY be the same as a subtype for a different registered type, but it's not enough to simply reference another type's subtype. The function of each subtype must be specified in the context of the type being registered 🧐.

3.1.3. Security requirement 🔐

An analysis of security issues is required for all registered Enumservices. (This is in accordance with the basic requirements for all IETF protocols.) 🛡️

All descriptions of security issues must be as accurate as possible, regardless of registration tree. In particular, a statement that there are "no security issues associated with this Enumservice" must not be confused with "the security issues associated with this Enumservice have not been assessed". Those are NOT the same vibe at all 💀.

There's no requirement that an Enumservice be secure or completely free from risks. Still, all known security risks must be identified in the registration of an Enumservice 🚨.

The security considerations section of all registrations is subject to continuing evaluation and modification 🔄.

Some of the issues that should be looked at in a security analysis of an Enumservice are:

  1. Complex Enumservices may include provisions for directives that institute actions on a user's resources. In many cases, provision can be made to specify arbitrary actions in an unrestricted fashion, which may then have devastating results. This is especially true if there is a risk for a new ENUM lookup, and because of that an infinite loop in the overall resolution process of the E.164. Scary stuff 😱.
  2. Complex Enumservices may include provisions for directives that institute actions which, while not directly harmful, may result in disclosure of information. That information may either facilitate a subsequent attack or else violate the user's privacy in some way 🕵️‍♀️.
  3. An Enumservice might be targeted for applications that require some sort of security assurance but don't provide the necessary security mechanisms themselves. For example, an Enumservice could be defined for storage of confidential security services information, such as alarm systems or message service passcodes, which in turn require an external confidentiality service 🚨🔑.

3.1.4. Publication Requirements 📚

Proposals for Enumservices registrations MUST be published as one of the following documents: an RFC on the Standards Track, an Experimental RFC, or a BCP 📖.

IANA will retain copies of all Enumservice registration proposals and "publish" them as part of the Enumservice Registration tree itself 🗃️.

3.2. Registration procedure 🪄

3.2.1. IANA Registration ✅

Provided that the Enumservice has obtained the necessary approval, and the RFC is published, IANA will register the Enumservice and make the Enumservice registration available to the community, in addition to the RFC publication itself 🎉.

3.2.1.1. Location of Enumservice Registrations 📍

Enumservice registrations will be published in the IANA repository and made available via anonymous FTP at the following URI:

"ftp://ftp.iana.org/assignments/enum-services/" 🦋

3.2.1.2. Change Control 🎀

okay so who's in charge of changing Enumservices? the IETF, bestie 💅 all changes go through the RFC publication process, no cap. and here's the tea: an Enumservice registration may not be deleted, ever 🙈 if an Enumservice stops being considered appropriate, it can be declared OBSOLETE by publishing a new RFC and updating its "intended use" field. IANA will clearly mark that Enumservice in the lists it publishes, so everyone can see it's been retired 🥀

3.2.2. Registration Template 📝

this is the form you fill out when you register one, and it's giving very organized energy ✨ here's the template in a code block so the field names stay exact:

Enumservice Type:

Enumservice Subtype(s):

URI Scheme(s):

Functional Specification:

Security considerations:

Intended usage: (One of COMMON, LIMITED USE or OBSOLETE)

Author:

Any other information that the author deems interesting:

Note: if a field has no value, you leave it completely blank 🫶 that's especially true when a type has no subtypes.

4. Examples 🧚

the examples below use pretend services that might not make total sense, but they're still super useful for learning 🍓 for example, the protocol is sometimes the exact same string as the URI scheme. that was allowed back in RFC 2916, but this "default" way of specifying an Enumservice is no longer allowed 🙅‍♀️ all Enumservices need to be registered explicitly through the procedure in section Section 3, no exceptions bestie.

4.1. Example 💖

$ORIGIN 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa.
   NAPTR 10 100 "u" "E2U+sip" "!^.*$!sip:info@example.com!" .
   NAPTR 10 101 "u" "E2U+h323" "!^.*$!h323:info@example.com!" .
   NAPTR 10 102 "u" "E2U+msg" "!^.*$!mailto:info@example.com!" .

so this is basically saying the domain 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa. is contacted by SIP first 📞 then H.323 for voice second, and SMTP for messaging third 💌 the tokens sip, h323 and msg are Types registered with IANA, and they have no implicit connection to the protocols or URI schemes that share their names. iykyk 🙈

after that, the next step is to use the resolution mechanism for each protocol (the URI schemes sip, h323 and mailto) to figure out which node to contact for each one 🔍

5. IANA Considerations 📋

okay, IANA history lesson incoming 🎀 RFC 2916, which this document replaces, asked IANA to delegate the E164.ARPA domain, following instructions the IAB would provide. the domain got delegated based on those instructions. names in this zone are delegated to parties according to ITU-T Recommendation E.164, and they should be hierarchic in line with that Recommendation, with codes assigned the same way 🌈

the IAB needs to coordinate with ITU-T TSB if the technical contact for the domain e164.arpa changes, because ITU-T TSB has an operational working relationship with that contact that needs to be reestablished 🤝

delegations inside the zone e164.arpa (not delegations inside its delegated domains) should be done after Expert Review, and the IESG will appoint a designated expert 👑

IANA has created a registry for Enumservices as specified in Section 3 🗂️ whenever a new Enumservice gets registered through the IETF RFC process, IANA registers it at the time the RFC is published and adds a pointer to the RFC itself ✨

6. Security Considerations 🔐

this section is dramatic, and it's supposed to be 😭

6.1. DNS Security 💀

ENUM uses DNS, and DNS in its current form is an insecure protocol 😬 so there's no mechanism for making sure the data you get back is authentic. ENUM is deployed on the global Internet, so 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 🎯

there are multiple types of DNS attacks that ENUM implementations should be aware of. the following threats are taken from Threat Analysis Of The Domain Name System [10]:

  • Packet Interception: some of the simplest DNS threats are packet interception attacks, like monkey-in-the-middle attacks, eavesdropping on requests combined with spoofed responses that beat the real response back to the resolver, and so on. in these scenarios, the attacker can tell either party (usually the resolver) whatever they want it to believe. packet interception isn't unique to DNS, but DNS usually sends an entire query or response in a single unsigned, unencrypted UDP packet, which makes these attacks especially easy for anyone who can intercept packets on a shared or transit network 👀
  • ID Guessing and Query Prediction: the ID field in the DNS header is only 16 bits, and the server UDP port for DNS is a well-known value. that means there are only 2**32 possible combinations of ID and client UDP port for a given client and server. so a reasonably brute-force attack could let an attacker pretend to be a trusted server 🥷 this is similar to packet interception, except the attacker doesn't need to be on a transit or shared network
  • Name-based Attacks: these use the real DNS caching behavior as a tool to insert bad data into a victim's cache, which can mess with later decisions based on DNS names. most examples involve CNAME, NS and DNAME Resource Records, since they redirect a victim's query somewhere else. the common thread is that responses let the attacker introduce arbitrary DNS names and claim extra information about those names. unless the victim already knows better, defending against this is really hard 😵‍💫
  • Betrayal By A Trusted Server: this is another spin on packet interception, where the trusted server turns out not to be so trustworthy, either by accident or on purpose 🫠 lots of client machines only have stub resolvers and rely on trusted servers to do all their DNS queries. often that trusted server is provided by the user's ISP and advertised to the client via DHCP or PPP options. besides accidental betrayal (server bugs, successful server break-ins, etc.), the server itself might be configured to return answers the user wouldn't expect, whether to be helpful or to push some other goal, like a business partnership between the ISP and a third party 💼
  • Denial of Service: like any network service (or pretty much any service in any domain of discourse), DNS is vulnerable to denial of service attacks. DNS servers can also be used as denial of service amplifiers, since DNS response packets tend to be a lot longer than DNS query packets 📢
  • Authenticated Denial of Domain Names: RR types whose absence causes something other than immediate failure (like missing MX and SRV RRs, which fail over to A RRs) are a real threat 🚨 for ENUM specifically, even the immediate failure of a missing RR can be a problem if it's used to change call routing policy 📞

because of these threats, a deployed ENUM service SHOULD include mechanisms that reduce them 🛡️ most of these can be solved by verifying the authenticity of the data with mechanisms like DNSSEC [8] once it's deployed. others, like Denial Of Service attacks, can't be solved by data authentication alone. it's important to remember that these threats cover not only the NAPTR lookups themselves, but also the other records services need to be useful (for example NS, MX, SRV and A records) 💅

even with DNSSEC deployed, a service that uses ENUM for address translation should not blindly trust that the peer is the intended party, because DNSSEC can't protect against every kind of DNS attack 🙅‍♀️ a service should always authenticate its peers as part of its own setup process and never blindly trust any kind of addressing mechanism 🔑

and finally, since an ENUM service will be implementing some kind of security mechanism, software that implements ENUM MUST be prepared to receive DNSSEC and other standardized DNS security responses 🔥 that includes large responses, EDNS0 signaling, unknown RRs, and so on 🧩

6.2. Caching Security 🕰️

DNS caching can make a change take as long to propagate as the time to live of the NAPTR records in the changed zone ⏳ using this in an environment where IP addresses are for hire (for example, when using DHCP [9]) has to be done very carefully 🫣

6.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 can encourage changes that aren't actually authorized, and in some cases can encourage denial of legitimate change requests 🙃 these environments should be designed with proper mechanisms to identify and authenticate whoever's requesting changes, and to authorize those changes 🔐

6.4. URI Resolution Security 🔗

a large number of security issues come from the resolution process itself, and from using the URIs produced by the DDDS mechanism 🌀 those have to be specified in the registration of the Enumservice being used, as specified in Section 3.1.3 📝

7. Acknowledgements 🫶

huge thanks to the people at Ericsson for the support and ideas that led to RFC 2916, including Bjorn Larsson and the group that implemented this scheme in their lab to check that it worked 🧪 input also came from ITU-T SG2, Working Party 1/2 (Numbering, Routing, Global Mobility and Enumservice Definition), the ENUM working group in the IETF, John Klensin and Leif Sunnegardh 💖

this update of RFC 2916 was created with specific input from Randy Bush, David Conrad, Richard Hill, Jon Peterson, Jim Reid, Joakim Stralmark, Robert Walter and James Yu 🌸

8. Changes since RFC 2916 🦋

apart from some clarifications in the text, there are two major changes:

first, the document uses an explicit DDDS algorithm instead of only NAPTR resource records in an "ad-hoc" mode 🧠 in reality, this doesn't change the deployed base of applications at all, because the algorithm used for ENUM resolution is exactly the same ✅

second, the format of the service field has changed. the old format looked like example+E2U, and the new format is E2U+example 🔄 the reason for this change has to do with the added subtypes in the Enumservice, the ability to support more than one Enumservice per NAPTR RR, and a general agreement in the IETF that the main selector between different NAPTR records with the same owner (E2U in this case) should come first 🥇

9. References 📚

9.1. Normative References

okay bestie, these are the must-read ones, the stuff the whole doc leans on 💅✨

  • [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
  • [3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI) Resolution Application", RFC 3404, October 2002.
  • [4] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
  • [5] ITU-T, "The International Public Telecommunication Number Plan", Recommendation E.164, May 1997.
  • [6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002.
  • [7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402, October 2002.

9.2. Informative References

these ones are more like extra reading, good for context but not required to get the spec 🧚

  • [8] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
  • [9] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
  • [10] Atkins, D. and R. Austein, "Threat Analysis Of The Domain Name System", Work in Progress, April 2004.

10. Authors' Addresses

the people who wrote it, aka the legends 🫶

Patrik Faltstrom Cisco Systems Inc Ledasa 273 71 Lovestad Sweden

EMail: paf@cisco.com URI: http://www.cisco.com

Michael Mealling VeriSign 21345 Ridgetop Circle Sterling, VA 20166 US

Email: michael@verisignlabs.com URI: http://www.verisignlabs.com

Copyright (C) The Internet Society (2004). 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 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property ✨

the IETF is not picking a side on who owns what here, so no position on patents or rights, and it hasn't done an independent search for any of them either. 🙈 if you want the procedures for rights in RFC docs, check BCP 78 and BCP 79.

copies of IPR disclosures sent to the IETF Secretariat, plus any assurances of licenses, or the results of trying to get a general license or permission for implementers or users, can be found in the IETF online IPR repository at http://www.ietf.org/ipr.

the IETF also invites anyone to point out any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. send that to the IETF at ietf-ipr@ietf.org 💌

Acknowledgement 🌸

funding for the RFC Editor function is currently provided by the Internet Society. thank you, Internet Society 💖

📦 where this page comes from