Hi Ed and DB-WG, I just noticed that the RIPE DB RDAP interface returns a 500 error when querying for ENUM domains[1] (except for specifically the top level e164.arpa domain, which results in a 400 error). This seems to be due to an assumption that all domains in the RIPE DB are reverse DNS domains for IP addresses, which is not the case as ENUM domains are also in there. Is this an intentional decision or was this just an oversight? If it was just an oversight, consider this a bug report. :) If it was an intentional decision then I would be interested in hearing what the reasoning was. [1]: Example: https://rdap.db.ripe.net/domain/6.4.e164.arpa -Cynthia
Hi Cynthia,
On 31 Jul 2025, at 19:37, Cynthia Revström <me@cynthia.re> wrote:
Hi Ed and DB-WG,
I just noticed that the RIPE DB RDAP interface returns a 500 error when querying for ENUM domains[1] (except for specifically the top level e164.arpa domain, which results in a 400 error).
This seems to be due to an assumption that all domains in the RIPE DB are reverse DNS domains for IP addresses, which is not the case as ENUM domains are also in there.
Is this an intentional decision or was this just an oversight?
The RDAP Query Format RFC 9082 (was RFC 7482) does not include the e164.arpa zone : "Queries for domain information are of the form /domain/XXXX, where XXXX is a fully qualified (relative to the root) domain name (as specified in [RFC0952] and [RFC1123]) in either the in-addr.arpa or ip6.arpa zones (for RIRs) or a fully qualified domain name in a zone administered by the server operator (for DNRs)."
If it was just an oversight, consider this a bug report. :) If it was an intentional decision then I would be interested in hearing what the reasoning was.
I can't tell if this was intentional, I couldn't find any discussion of ENUM or e164.arpa in the WG archives: https://mailarchive.ietf.org/arch/browse/weirds/ https://mailarchive.ietf.org/arch/browse/regext/ If there is interest in supporting the e164.arpa zone in RDAP domain queries, I suggest the next step is to create a draft RFC, so we make it part of the standard and consider the impact on the protocol (e.g. how do we bootstrap the e1664.arpa zone, should other RIRs redirect e164.arpa to the RIPE NCC etc.).
[1]: Example: https://rdap.db.ripe.net/domain/6.4.e164.arpa
-Cynthia
Regards Ed Shryane RIPE NCC
Edward, On Aug 1, 2025, at 2:55 AM, Edward Shryane <eshryane@ripe.net> wrote:
If there is interest in supporting the e164.arpa zone in RDAP domain queries, […]
I guess the real question is whether or not anyone actually uses e164.arpa. My (perhaps mistaken) impression has been that while it was an interesting idea in theory, in practice non-technical considerations made public ENUM deployment challenging at best, a non-starter at worst. From https://www.ripe.net/manage-ips-and-asns/dns/enum/request-archives/, it looks like there’s been no delegation activity for a decade. If it’s not being used, I suspect spinning up interest in the IETF for an RFC may be difficult… Regards, -drc
Dear David,
On 1 Aug 2025, at 19:56, David Conrad <drc@virtualized.org> wrote:
Edward,
On Aug 1, 2025, at 2:55 AM, Edward Shryane <eshryane@ripe.net> wrote:
If there is interest in supporting the e164.arpa zone in RDAP domain queries, […]
I guess the real question is whether or not anyone actually uses e164.arpa.
I found a few hundred queries per day in the Whois query logs for e164.arpa domains.
My (perhaps mistaken) impression has been that while it was an interesting idea in theory, in practice non-technical considerations made public ENUM deployment challenging at best, a non-starter at worst. From https://www.ripe.net/manage-ips-and-asns/dns/enum/request-archives/, it looks like there’s been no delegation activity for a decade. If it’s not being used, I suspect spinning up interest in the IETF for an RFC may be difficult…
Is our time better spent in supporting e164.arpa in RDAP, or deprecating e164.arpa? If we need to continue to support e164.arpa (per RFC 3245), then I suggest we should also support it in RDAP. The NCC can create a short draft RFC to extend the RDAP domain object type, and update Whois to match. We can request the other RIRs to add a redirect in RDAP for e164.arpa. Regards Ed Shryane RIPE NCC
I support to support e164.arpa. Nobody knows, if an existing distributed call routing system is needed to overcome the limitations of VoIP-oligopols. Von: Edward Shryane <eshryane@ripe.net> Gesendet: Montag, 4. August 2025 11:01 An: David Conrad <drc@virtualized.org> Cc: db-wg <db-wg@ripe.net> Betreff: [db-wg] Re: RDAP for e164.arpa Dear David, On 1 Aug 2025, at 19:56, David Conrad <drc@virtualized.org<mailto:drc@virtualized.org>> wrote: Edward, On Aug 1, 2025, at 2:55 AM, Edward Shryane <eshryane@ripe.net<mailto:eshryane@ripe.net>> wrote: If there is interest in supporting the e164.arpa zone in RDAP domain queries, […] I guess the real question is whether or not anyone actually uses e164.arpa. I found a few hundred queries per day in the Whois query logs for e164.arpa domains. My (perhaps mistaken) impression has been that while it was an interesting idea in theory, in practice non-technical considerations made public ENUM deployment challenging at best, a non-starter at worst. From https://www.ripe.net/manage-ips-and-asns/dns/enum/request-archives/, it looks like there’s been no delegation activity for a decade. If it’s not being used, I suspect spinning up interest in the IETF for an RFC may be difficult… Is our time better spent in supporting e164.arpa in RDAP, or deprecating e164.arpa? If we need to continue to support e164.arpa (per RFC 3245), then I suggest we should also support it in RDAP. The NCC can create a short draft RFC to extend the RDAP domain object type, and update Whois to match. We can request the other RIRs to add a redirect in RDAP for e164.arpa. Regards Ed Shryane RIPE NCC
Dear colleagues,
On 4 Aug 2025, at 11:01, Edward Shryane <eshryane@ripe.net> wrote:
...
Is our time better spent in supporting e164.arpa in RDAP, or deprecating e164.arpa?
Thanks for raising this and for your feedback. The DB team will proceed with implementing the e164.arpa zone in RDAP and we will document in an RFC. This will be a small extension to the existing protocol. I don't foresee e164.arpa being deprecated, at least in the short term, and we are aiming for feature parity with Whois. Regards Ed Shryane RIPE NCC
Hi, I forgot to reply earlier but I mostly just want us to try to aim for feature parity with WHOIS. So I agree with with your decision :) -Cynthia On Tue, 5 Aug 2025, 13:00 Edward Shryane, <eshryane@ripe.net> wrote:
Dear colleagues,
On 4 Aug 2025, at 11:01, Edward Shryane <eshryane@ripe.net> wrote:
...
Is our time better spent in supporting e164.arpa in RDAP, or deprecating e164.arpa?
Thanks for raising this and for your feedback.
The DB team will proceed with implementing the e164.arpa zone in RDAP and we will document in an RFC. This will be a small extension to the existing protocol.
I don't foresee e164.arpa being deprecated, at least in the short term, and we are aiming for feature parity with Whois.
Regards Ed Shryane RIPE NCC
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/db-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
On 5 Aug 2025, at 12:00, Edward Shryane wrote:
The DB team will proceed with implementing the e164.arpa zone in RDAP and we will document in an RFC.
Thanks, Ed. I would like the WG to be aware that this will likely need some "pre-preparation", before an ID appears, so that stakeholders, who may not be aware of this WG, can be engaged appropriately. These include the IAB, SG2 of the ITU-T (who are parties to a formal liaison about this zone), and the operators of the registries for the daughter zones delegated from e164.arpa. Early engagement may help avoid either unwelcome surprises to, or unexpected consequences for, any of these organizations, as well as (potentially significant) diplomatic work needed to address any misunderstandings which may otherwise arise. I encourage any of these stakeholders who are actually present on this list to engage as soon as they can, which may be on their return from vacation. Following the multi-stakeholder model properly can be hard. Thanks for taking note of these concerns. Best regards, Niall O'Reilly RIPE Vice-Chair
participants (5)
-
Cynthia Revström -
David Conrad -
Edward Shryane -
Lutz Donnerhacke -
Niall O'Reilly