Summary

  • ENUM converts an E.164 number into a DNS key and processes NAPTR rules until it produces a URI; that result identifies a possible service contact, not a completed communications session.
  • A defensible call record joins number-control validation, DNSSEC state, the selected NAPTR, the generated URI, downstream peer authentication, signalling and observed bidirectional media without compressing them into “ENUM success”.

A communications console receives an E.164 number and reports success. The input was normalized, its digits were reversed into an e164.arpa name, a NAPTR RRSet arrived with valid DNSSEC, and the client generated a SIP URI. Yet the next lookup found an old service target. Or the peer rejected the invitation. Or a person never answered. Or signalling completed while media flowed in only one direction.

Nothing in that sequence makes the ENUM result false. The error is the label on the console. “Resolved” has been promoted into “connected” by deleting every transition after the URI.

Patrik Fältström and Michael Mealling authored RFC 3761, the 2004 Standards Track specification for ENUM. It was later obsoleted by RFC 6116, written by Scott Bradner, Lawrence Conroy and Kazunori Fujiwara. The later RFC calls itself an update of the document edited by Fältström and Mealling. That lineage matters: ENUM is collective, revised standards work, not the property or operational decision of one person.

The architecture’s enduring contribution is narrow and powerful. It allows an application to begin with a telephone number and discover a URI through DNS. It does not make DNS into a telephone switch, a number-assignment authority or a witness to human conversation.

The number becomes a DNS key

RFC 6116 first defines an Application Unique String. The client removes visual punctuation from the fully qualified E.164 number while retaining the leading plus sign. The first well-known rule then removes the plus sign, reverses the digits, puts a dot between them and appends .e164.arpa.. A familiar number becomes a precise DNS name.

That transformation proves something modest: the client constructed the key prescribed for this DDDS application. It does not prove who currently has the right to use the number. Nor does it prove that the input came from an authorized caller, that a registrar has kept pace with number portability, or that an application should contact every service published below the name.

The DNS query retrieves NAPTR records. A terminal record can produce the final output; a non-terminal record produces another domain name and another round of processing. The expected output of the last DDDS loop is an absolute URI. The endpoint of ENUM is therefore an address expression, not a call-state event.

RFC 3403 makes the rule machinery explicit. ORDER determines which rule group is considered first. Within a group, PREFERENCE helps choose among otherwise eligible records. FLAGS, SERVICES, REGEXP and REPLACEMENT tell the application how to interpret or rewrite the value. Capturing only the URI throws away why that URI won.

One returned rule still leaves a choice

RFC 6116 says the ENUM algorithm always returns a single rule. That sentence can sound like an execution verdict. It is not. An application can have its own knowledge, show multiple possible URLs to a user, support only some Enumservices, discard malformed or private records, or choose among contacts with equal ordering values. The RFC requires clients to sort an RRSet by ORDER and PREFERENCE, but it warns that DNS delivery order is not a dependable tie-breaker.

The registrant’s preferences also stop short of command. RFC 6116 advises registrants to publish only contacts they are willing to support because even a contact with the least attractive ordering can be selected by an end user. That is a statement about possible client behavior. It does not promise that the contact is live now, that the application implements its scheme, or that the downstream provider accepts the request.

This is why an operational trace needs the full candidate set. Record every returned NAPTR, its TTL, order, preference, service, flags and rewrite; record the client’s supported services and the reason each record was retained or discarded. A final URI without that denominator cannot explain whether the client followed policy, encountered a tie, used stale data or had no compatible alternative.

Number control is an upstream receipt

ENUM names are not ordinary first-come-first-served labels. They are coupled to E.164 assignments. RFC 4725 describes a validation architecture precisely because the DNS tree must track a separate numbering system.

It distinguishes the number-assignment entity, the assignee with the right to use the number, the ENUM registrant, a validation entity, the registry, registrar, DNS service provider and application service provider. The validation entity checks whether the registrant is the assignee or is authorized to act for it. The document also requires a way to revoke a delegation when the conditions cease to hold. Initial validation is followed by recurring validation or revalidation.

Those are provisioning and governance facts. They do not travel automatically inside every NAPTR answer. A resolver that receives a record can verify DNS data and still lack the current validation transaction, number-porting state or local-policy decision behind the delegation. “The name existed” and “the registrant still controlled the number at this instant” require different evidence.

The distinction protects both sides. A stale record is not proof of fraud; cache lifetime, unsynchronized updates or a delayed revocation may explain it. A valid historical token is not proof of present control. The useful audit join includes assignment version, validation method, validation time, expiry or revalidation state, delegation change and the exact DNS data observed by the client.

DNSSEC authenticates data, not the service peer

The security section of RFC 6116 states the boundary unusually plainly. DNSSEC can verify authenticity of DNS data and mitigate many attacks against ENUM. It cannot make the service immune to every attack. In particular, retrieving an address through a DNSSEC-validated ENUM lookup does not guarantee that the entity reached at that address is the service peer the user intended.

The RFC therefore tells the service to authenticate the peer during service setup rather than relying on address or identity data obtained outside the service. This is not a qualification buried at the edge of the design. It is the handoff between discovery and communication.

Caching lengthens the handoff. RFC 6116’s SIP example starts with an ENUM URI, then performs further NAPTR processing for the SIP domain, SRV lookup for servers and address lookup for a host before the user agent even attempts to initiate a session. Those records can have different TTLs and can change in different zones. A perfectly authentic collection of records can be temporally inconsistent.

Keep DNSSEC status, but do not let the green shield replace the rest of the receipt. Preserve the validation chain, inception and expiry times, negative answers, resolver identity, cache age and every downstream lookup. Then authenticate the actual service peer and bind the signalling attempt to that identity.

A voice URI starts another protocol

RFC 4415 registered the voice:tel Enumservice. Its wording is exact: the contact in the generated URI can be used to initiate an interactive voice call. A dialer uses the telephone number in the URI to place a call through a PSTN or PLMN connection, directly or through an IP provider and gateway.

“Can initiate” is a capability boundary. The client must support the type and subtype. A provider can authenticate and authorize the request. Routing can find a destination or fail. The far endpoint can ring, reject, redirect, time out or answer. Media then needs its own negotiated path. None of those events is encoded into the prior NAPTR result.

A SIP URI illustrates the separation. RFC 3261 defines a distinct protocol for locating prospective participants and creating, modifying and terminating sessions. SIP has transactions, authentication and authorization, invitations, provisional and final responses, acknowledgements and dialog state. ENUM supplies an input URI; it does not pre-execute that state machine.

Even “SIP succeeded” may be too broad for the operational question. An accepted invitation does not by itself show that bidirectional audio crossed the intended path, that a human conversation occurred, that it lasted, or that billing matched policy. Those claims need media observation and application records, bounded by privacy and retention rules.

Build the call receipt in order

A useful receipt begins with the original number and the normalization rule. Next come the derived DNS key, resolver, query time, DNSSEC validation, full NAPTR RRSet, TTLs and any non-terminal rewrite chain. The client then records its supported Enumservices, the candidate set, selection rationale and final URI.

The second half belongs to another control plane: downstream DNS resolution, authenticated peer, provider authorization, signalling request, transaction identifier, responses, acknowledgement and termination reason. Only after that can the record state whether the expected media endpoints exchanged bidirectional packets, whether the application considered the session usable and how long the observation remained valid.

Each element can succeed while the next fails. That is not bureaucratic duplication. It is how a system distinguishes an expired number delegation from a stale cache, an unsupported Enumservice from an unreachable host, a wrong service peer from a rejected caller, and accepted signalling from one-way audio.

Sources