ENUM allows normal phone (E.164) numbers to be represented as DNS names ending in e164.arpa. One number can be resolved to one or more services in a predefined order.

For example, the phone number +44-116-496-0348 is represented as 8.4.3.0.6.9.4.6.1.1.4.4.e164.arpa after traversing the following rules from the RFC: (RFC 3761)

  1. Remove all characters with the exception of the digits. ("+44-116-496-0348" becomes "441164960348")

  2. Put dots (".") between each digit.  ("4.4.1.1.6.4.9.6.0.3.4.8")

  3. Reverse the order of the digits. ("8.4.3.0.6.9.4.6.1.1.4.4")

  4. Append the string ".e164.arpa" to the end.  ("8.4.3.0.6.9.4.6.1.1.4.4.e164.arpa")

Resulting NAPTR record(s) denote services for that number. For example, the BIND configuration:

$ORIGIN 8.4.3.0.6.9.4.6.1.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!" .

describes that the domain 8.4.3.0.6.9.4.6.1.1.4.4.e164.arpa. is preferably contacted by SIP, secondly via H.323, and thirdly by SMTP for messaging.

Picking which service to use is the job of the Dynamic Delegation Discovery System. (DDDS) In the above example, the "u" flag tells the DDDS that each of these are terminal rules. Transformational rules which don't have this flag present can be used to rewrite the key produced by this rule as the new key in the DDDS lookup but an example of that is not shown here. At the moment, the "u" flag is the only flag defined.

The service field of the NAPTR record (such as "E2U+sip") is required to start with "E2U" so as to prevent name collisions. One or more ENUM services starting with a "+" are listed. An ENUM service consists of a type and zero or more subtypes separated by a ":" character. Types and subtypes are limited to 32 alpha-numeric characters which represent the valid protocols, and the URI schemes that may be returned.

NAPTR records are supported natively with BIND but not djbdns without the djbdns SRV+NAPTR patch. Alternatively, djbdns users could construct a NAPTR record through a generic record but it isn't easy to manage records in this format.

Please note that Asterisk (tested on 1.4.x) can't handle "i" in the NAPTR regular expression. The "i" is not really needed anyway since we are only sending digits. One of the two examples below work:

1: IN NAPTR 100 10 "u" "sip+E2U" "!^.*$!sip:xxx@voip.domain.se!i" . 
2: IN NAPTR 100 10 "u" "sip+E2U" "!^.*$!sip:xxx@voip.domain.se!" . 

Example 1 will not work. You will get a "regex delimiter error" from Asterisk.
Example 2, from where the "i" has been removed, will work.