Summary

  • RFC 5346 reports a 2006 Korean Infrastructure ENUM trial in which one E.164 input could enter different routing regimes. A usable ENUM URI led toward IP interconnection; most DNS errors, timeout, an unknown private-table domain or an unresolvable URI domain sent the number to vendor-specific routing and the PSTN. A completed call therefore did not prove that ENUM selected its route.
  • Trial policy gave different operational meanings to superficially adjacent DNS states. NOERROR with no usable URI meant immediate failure for an ENUM-only number, while NXDOMAIN or another DNS error triggered legacy fallback. DNS syntax alone did not create that meaning; provisioning policy, number-range design and the existence of a PSTN point of interconnect did.
  • The durable control is a route-provenance ledger: retain the input number, query and response class, usable-record decision, chosen NAPTR, URI domainpart, mapping source, fallback reason, bilateral interconnect context, selected gateway and final outcome. Otherwise continuity can conceal which authority actually moved the call.

One green outcome contained two incompatible histories

The successful call could have followed an ENUM answer. A softswitch converted the dialled E.164 number into an ENUM domain, asked DNS for NAPTR records, selected a usable URI and resolved its domain into an IP interconnection. That history would make the shared directory part of the route decision.

The same call outcome could also follow a DNS failure. RFC 5346's trial rules sent NXDOMAIN, format error, server failure, not implemented, refused and eventual timeout toward the softswitch's existing vendor-specific method. In the Korean trial, that meant sending the original number to the PSTN for onward routing. The directory did not select the successful route at all.

A metric that records only “answered” collapses those histories. Even a pair consisting of the number and 200 OK is too small. The evidence needs the decision transition between discovery regimes.

That distinction matters beyond historical ENUM. Migration systems often introduce a new source of routing truth while retaining a legacy path. The legacy path protects service while the new database is sparse. It also lets the organization claim a successful outcome without knowing which control plane delivered it. Availability improves; attribution becomes harder.

NOERROR was not the success state

RFC 5346 did not map DNS response codes directly onto user outcomes. It mapped them through a trial-specific number policy.

For an “ENUM only” range, an in-service number had a usable SIP or H.323 URI and no PSTN point of interconnect. An out-of-service number kept an existing ENUM domain but no usable call URI. A NAPTR query could therefore return RCODE=0, yet the answer set contained nothing the softswitch could use to place a call. The prescribed result was immediate failure. Sending that number toward the PSTN would be pointless and could be dangerous because no legacy interconnect existed.

By contrast, a name error or another DNS error caused fallback. That was appropriate for the far larger class of numbers that still had a PSTN point of interconnect and did not need an ENUM record. Absence from the new directory did not mean absence from service.

The operational meaning was consequently not:

  1. successful DNS code means successful call; and
  2. DNS error means invalid number.

It was:

  1. NOERROR plus a usable URI means continue through ENUM processing;
  2. NOERROR without a usable URI means stop under the ENUM-only policy; and
  3. specified DNS errors mean leave ENUM and attempt the legacy route.

That three-way interpretation depended on correct provisioning. DNS carried the state, but the carrier policy defined what the state was allowed to mean.

The fallback changed the authority surface

The input did not change when fallback occurred. It remained the same E.164 number. The authority consulted did change.

On the ENUM path, the softswitch depended on the e164.arpa hierarchy, a recursive resolver, a NAPTR set, a supported service and a usable URI. On the fallback path, it depended on a vendor-specific prefix table and the PSTN routing regime. These systems could disagree while each remained internally valid.

A fallback rule therefore does more than offer a second transport. It selects which registry, contractual arrangement and error model controls the next hop. If an audit says merely “ENUM attempted,” it misses the decisive event. Attempt is not selection.

The issue appears again after a valid URI is returned. RFC 5346 describes two ways to map its domainpart. A carrier could use recursive DNS and SIP location rules, or a fixed private table that mapped a domain to an agreed gateway. If the private table did not contain the domain, the call fell back to the PSTN. If recursive resolution failed or returned no usable records, the call also fell back.

Thus a valid ENUM NAPTR was not yet a route. It was an instruction that still had to survive another authority boundary.

A private table could be more authoritative than public resolution

The fixed mapping was not presented as an elegant permanent architecture. It duplicated management: administrators had to maintain ENUM data and a second domain-to-gateway table inside the softswitch. But the trial began with few provisioned ENUM entries and established commercial service that could not be destabilized for the experiment.

The table also represented something DNS could not express by itself: bilateral interconnection. Carriers expected interconnection fees and could agree on a specific gateway. That route might be private to the parties. A domain name that resolved publicly did not prove that the calling carrier was entitled to use every address it found.

The fixed table acted as both route data and an operational shadow of agreement. Its presence did not prove that the agreement remained current, but bypassing it in favour of any publicly resolved endpoint could ignore the commercial control surface. Conversely, a stale table could keep selecting a gateway after DNS had changed.

RFC 5346 says the softswitches could be switched immediately between fixed-table and DNS-based domain routing because operators were uncertain about ENUM performance and reliability. It calls this a temporary expedient, not a reasonable long-term solution. The important fact is that two route authorities coexisted, and the switch between them was itself a controlled decision.

Timeout was a route event, not just a latency event

No response eventually became a DNS error and led to fallback. From the caller's perspective, this could look like a slow setup followed by success. From the control plane's perspective, the timeout was the moment the new routing authority lost the decision.

The trial did not simply shorten DNS timeouts. The softswitch DNS stack served purposes beyond ENUM, and configuring it in a non-compliant way without studying the effects on other operations was rejected. That restraint exposes a useful dependency: a parameter that improves one call-routing branch can alter every other DNS consumer in the appliance.

Monitoring only total answer delay would combine the resolver wait, fallback decision, PSTN routing and SIP response into one number. It would not say where the delay accrued or why the path changed.

The held-for-document-update erratum to RFC 5346 matters here. Four passages in section 4.1.1 refer to “rule 2” when the branching rules are under rule 3. A runbook that copied the original numbering without checking the erratum could point operators to the wrong decision stage. A second erratum corrects “non-complaint” to “non-compliant”; neither changes the routing thesis, but both belong in a reproducible reading of the document.

The average table measured a narrow surface

The trial compared average answer delay from SIP INVITE to 200 OK. The six reported ENUM and non-ENUM pairs differed by less than one second: 2.33 versus 2.28 seconds for Carrier A to itself; 2.23 versus 2.25 for A to B; 4.11 versus 3.79 for A to another PSTN destination; 2.18 versus 2.05 for B to itself; 2.19 versus 2.19 for B to A; and 3.95 versus 3.41 for B to another PSTN destination.

Those numbers support a bounded observation: in the measured trial combinations, average initiation delay was similar enough that a caller would find the route choice difficult to detect as a quality difference. They do not establish a universal commercial benchmark.

The document does not supply sample counts, percentile distributions, failure denominators, cache-state breakdowns or per-call route provenance beside the table. The clock ends at 200 OK; it does not demonstrate media quality, billing correctness, conversation completion or correct number ownership. A fast fallback call and a fast ENUM-routed call can occupy the same average cell.

“The caller did not notice” is useful operational evidence. It is not proof that the new directory controlled the outcome.

Provisioning error had no obvious owner

Centralized discovery simplified sharing. It also moved errors across organizational boundaries.

RFC 5346 notes that incorrectly provisioned ENUM data causes trouble in the network of the carrier placing the call. Yet that carrier may not know which carrier is responsible for the number or who can correct the shared data. Number portability makes the owner of the repair less obvious.

This is an attribution problem, not just a DNS problem. The resolver can faithfully return the record that exists. The softswitch can faithfully process it. The call can fail in the caller's network. None of those facts identifies the party authorized and able to repair the source record.

For an operator, the incident record needs more than an RCODE. It needs the provisioning channel, record version, serving-carrier assertion, number-portability context, resolver view, route-source decision and repair contact. Without those links, the shared directory distributes route information faster than it distributes responsibility.

Public discovery and private operation pulled in opposite directions

The trial exposed its Infrastructure ENUM data through the public Internet. This supplied a demanding resolver environment and made sharing straightforward. Carriers nevertheless questioned whether public access was necessary because telephone-number data could be disclosed. They preferred private access in some circumstances.

The resolver itself was a control point. RFC 5346 warns that an attacker who compromised it could force call failures or delays, and recommends limiting resolver access to the softswitch's local network while restricting outside access.

Private access does not automatically make data correct. Public access does not automatically make a route authorized. The choice changes who can query, observe, attack and audit the directory. It should be recorded separately from record validity and call outcome.

The document is a historical operating report

RFC 5346 is Informational and explicitly not an Internet Standard. It describes a particular 2006 pre-commercial trial. RFC 6116 later replaced RFC 3761 as the ENUM specification. These status facts keep the evidence honest.

The trial remains valuable because it exposes a transition architecture in unusually concrete terms. It names the branches, the fallback, the duplicated tables, the latency surface and the responsibility gap. It does not prove that a current carrier uses those rules, that the Korean infrastructure remains deployed, or that another network should reproduce them unchanged.

The right reuse is analytical: whenever a new directory coexists with a legacy route, outcome telemetry must not erase the decision boundary between them.