A 2026 operational review of Public ENUM under e164.arpa found that half of the current delegations show some form of DNS problem. The findings are expected to be discussed at RIPE 92, including the operational status and future support of Public ENUM under e164.arpa.
ENUM sits at the intersection of two globally coordinated systems: the public telephone numbering system and the Internet’s naming system. It links E.164 telephone numbers, the internationally recognised numbering plan used for public telephony, with the Domain Name System (DNS), allowing information associated with a number to be published and retrieved through Internet infrastructure.
The RIPE NCC previously reviewed Public ENUM under e164.arpa in 2020. That review identified concerns with some delegations, including broken delegations and delegations that appeared vulnerable to misuse or hijacking. As part of the 2026 operational review, the RIPE NCC repeated the DNS check for ENUM delegations under e164.apra Of the 50 zones approved to date, two were abandoned immediately after approval and were never created, while two were later deleted. This leaves 46 zones currently delegated in the RIPE Database. Of these, 23 showed no observed DNS issues, 17 were assessed as completely broken, and 6 had partial issues. In total, 23 of the 46 current delegations showed some form of DNS problem.
In addition, discussions about possible additional support for Public ENUM under e164.arpa, including whether registration data for Public ENUM should be supported through the Registration Data Access Protocol (RDAP), have raised the question of whether there is a clear basis for continued support.
A brief reminder of what ENUM is
ENUM provides a common lookup mechanism between telephone numbering and Internet naming. It did not create a new numbering system, and it did not replace the public telephone numbering plan. It takes an existing telephone number and uses DNS to locate information associated with it, such as how that number might be reached or which Internet-based services are connected to it.
This review is concerned with Public ENUM, which maps E.164 numbers into the public DNS tree. This should be distinguished from private or carrier-oriented ENUM uses. Infrastructure ENUM, sometimes called Carrier ENUM, uses similar techniques for carrier-of-record, routing, or interconnection purposes, often in private, federated, or operator-controlled environments. Those uses may remain relevant, but they are not the focus of this review.
The ambition behind Public ENUM was global interoperability. It was intended to allow information associated with a globally unique telephone number to be stored in a single public location and consistently found. As RFC 3245 explains, a single Public ENUM tree was needed so applications had a consistent place to look. That public location became e164.arpa.
Why ENUM was put under .arpa
RFC 3245 explains that this was not an arbitrary choice. The IAB had already concluded that new infrastructure information placed in DNS should go under .arpa, which had long been used for Internet infrastructure purposes. Rather than creating a new top-level domain for each infrastructure function, the logic was to use one established infrastructure domain and create specific subdomains beneath it.
This is what e164.arpa represents. It is not a telephone database placed under an Internet label. It is a DNS-based infrastructure function for mapping E.164 numbers in a stable and globally consistent way. RFC 6116 still reflects this when it states that e164.arpa is used to provide the infrastructure in DNS for storage of data associated with E.164 numbers.
Placing ENUM there also made its governance implications clear. E.164 numbers remain part of a globally coordinated public numbering system, while the Public ENUM tree sits within the Internet’s infrastructure domain. ENUM can only work through coordination between the relevant technical, numbering, and operational actors.
The arrangement brings together several roles: protocol work through the IETF, architectural oversight through the IAB, administration of the .arpa infrastructure domain through IANA, numbering legitimacy through the ITU-T and relevant national authorities, and operation of the e164.arpa zone by the RIPE NCC under IAB instructions, with country-code-level changes coordinated through the ITU-T Telecommunication Standardization Bureau.
Stewardship means not assuming the answer
The RIPE NCC operates the e164.arpa zone under the IAB instructions for operating the e164.arpa domain. Changes to country-code delegations depend on the established ITU-T / TSB and Member State process. This review therefore needs to distinguish between what the RIPE NCC can assess operationally and what must be handled through the established coordination process.
The purpose of the review is not to assume the outcome. Some e164.arpa delegations are actively maintained and may still have a valid operational purpose. Others have already been found to be broken or degraded, and may require follow-up through the established ITU-T / TSB process. The RIPE NCC’s role is to establish the operational facts, contact the parties it can identify, and use that process where delegation changes may be needed.
The RIPE NCC has also asked ITU-T Study Group 2 for guidance, given SG2’s role in international numbering resources and because Public ENUM under e164.arpa is linked to E.164 numbering. The aim was to understand how relevant numbering authorities and Member States view the future of Public ENUM under e164.arpa: whether it should still be considered active, whether there are delegations or operational purposes that require continued support, whether additional implementation work such as RDAP support would be appropriate, and what operational steps may be needed in light of the TSB consultation. This was intended to inform the RIPE NCC’s operational review, not to pre-empt the outcome. In parallel, the RIPE NCC is contacting the operators and administrative contacts it has on record for existing e164.arpa delegations.
Since then, TSB has circulated revised interim procedures on ENUM administration, including how non-operational delegations may be withdrawn. These are still under consultation and may be considered at the next ITU-T Study Group 2 meeting in September 2026.
Input from delegation holders remains important. For example, Internet Society Netherlands has indicated that the 1.3.e164.arpa delegation, covering the Dutch country code +31, remains operationally maintained, that contact information is current, that DNSSEC is in place, and that revocation is not being sought. This does not by itself establish current use, but it does show that the delegation has an accountable operator and current operational information. That kind of input helps distinguish e164.arpa delegations that are still actively maintained from those that may require follow-up.
We will bring this discussion to RIPE 92 to gather community input and help inform any next steps. The underlying principle is that Public ENUM under e164.arpa should not continue by inertia, and it should not be changed by assumption. Its future should be based on evidence of continued relevance, accountable operation, and a clear process for handling delegations that require follow-up.



Comments 0