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 seperated by a ":" character. Types and subtypes are limited to 32 alpha-neumeric characters which represent the valid protocols, and the URI schemes that may be returned. 

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