Whois using these ARIN services?? (fwd: Consultation on the Future of ARIN’s Directory Services)
NANOGers - ARIN is undertaking a community consultation on the Future of ARIN’s Directory Services. If you are interested in this topic, please see details below, including how to join the ARIN-consult mailing list. Thanks! /John John Curran President and CEO American Registry for Internet Numbers Begin forwarded message: From: ARIN <info@arin.net> Subject: [ARIN-consult] Consultation on the Future of ARIN’s Directory Services Date: August 14, 2026 at 11:16:12 AM EDT To: <arin-consult@arin.net> ARIN is seeking feedback from the community on a proposed road map to streamline and consolidate its directory services. ARIN currently maintains four directory information protocols: Whois-RWS, RWhois, Whois (Port 43), and RDAP. Supporting multiple redundant services that provide the same information creates additional administrative and operational overhead to the organization. To reduce ARIN’s attack surface, streamline operations and lower future operational overhead, ARIN proposes retiring use of older protocols in favor of RDAP as our single, standardized directory service. This transition is an important step toward improving alignment with established IETF standards. We have already seen this transition in the domain industry with ICANN mandating the use of RDAP for directory services and dropping the requirement to support Whois. We also expect RDAP clients to become increasingly common in OS distributions in the coming years. ------ Benefits of Transition to RDAP - Enhanced Directory Services: Future enhancements, such as geolocation, will only be implemented in RDAP. - Standardization and Automation: RDAP’s standardized data structure will improve automation for clients and provide greater flexibility in managing future data changes. - Reduced Technical Overhead: Removing old and redundant services will provide time and cost savings for ARIN. ------ Timeline and Retirement Planning This consultation seeks community input for the proposed retirement timelines below. We are keenly interested in receiving specific input on any barriers and/or obstacles these changes may create for customers, as well as steps ARIN can take to ensure a smooth transition. Note that the retirement plans for each impacted directory service will be completed independently, though in some cases work may be conducted concurrently. *** Whois-RWS Retirement Plan and Timeline ARIN currently offers Whois-RWS in two formats: an API and a web interface (located at https://whois.arin.net/ui/). Because the API has the same functionality between Whois-RWS and RDAP, ARIN proposes sunsetting the Whois-RWS API following a 180-day customer outreach program. This will include updating the Whois-RWS payloads to include a notification to users, as well as a robust communication strategy that includes announcements, social promotion, and other outreach. The Whois-RWS web interface will remain available until work is completed to ensure parity, providing equivalent query capabilities to RDAP. The changeover from Whois-RWS to RDAP will be transparent to end users visiting that URL. ARIN will inform the community a minimum of 30 days before the retirement of the Whois-RWS web interface, noting the switch to RDAP will not change the end user experience. *** RWhois Retirement Plan and Timeline When RWhois server use is retired, we will provide organizations with a recommendation for an open-source RDAP server implementation. To help ease the transition and migration of data, ARIN plans to provide a conversion tool for populating that recommended RDAP server with existing RWhois data. When the tool is publicly available, ARIN proposes a 365-day sunsetting timeline for RWhois. This will allow for robust communication and direct outreach to organizations who use RWhois and plan to either convert to the RDAP client or discontinue their use of local clients and report their reassignment information directly to ARIN instead. *** Whois (Port 43) Retirement Plan and Timeline ARIN understands that Whois (Port 43) carries a high volume of queries and will require the longest timeline to retire. We propose a two-year sunsetting window, during which ARIN will engage in active outreach to users. This will include updates to Whois (Port 43) results during the sunsetting period that will contain information about the retirement deadline. Because Whois (Port 43) has been the historically preferred method of querying Internet number resource registration data, it remains heavily used by cybersecurity professionals, researchers, law enforcement, and many other types of organizations. ARIN will seek to engage beyond our community to raise awareness of the planned retirement date for Whois (Port 43). ------ After the retirement of the directory service protocols described above and listed below, ARIN will only support RDAP as our single, standardized directory service. - Whois-RWS: on or after 1 July 2027 - RWhois: dependent on migration tool release date, but no sooner than 1 January 2028 - Whois (Port 43): on or after 1 January 2029 Throughout the sunsetting process for all services, ARIN will engage with our community to ensure customers and users are well-informed about the retirement of the described services and ARIN’s transition to RDAP as its standard directory service. We look forward to your feedback on the proposed timelines for retirement for Whois-RWS, RWhois, and Whois (Port 43). We ask that you consider each service independently, with the understanding that each of these services may impact your organization differently. Please provide comments to arin-consult@arin.net. You can subscribe to this mailing list at https://lists.arin.net/mailman/listinfo/arin-consult. This consultation will remain open until 5:00 PM ET on 14 September 2026. ARIN seeks clear direction through community input, so your feedback is important. Thank you for your continued support in improving ARIN’s services. Regards, John Curran President and CEO ARIN ------ Relevant links: - Presentation from ARIN 56: https://www.arin.net/participate/meetings/ARIN56/materials/arin56_directorys... - IETF Standard for RDAP: https://www.rfc-editor.org/info/std95 - Guide to RDAP Client Implementations: https://rdap.rcode3.com/client_implementations/index.html - ARIN RDAP Documentation: https://www.arin.net/resources/registry/whois/rdap/ _______________________________________________ ARIN-Consult
hi john, can we assume there will be somewhat finger compatible CLI client tools for most platforms? and a staged trasition, to allow for lot of automation that is gonna have to change. speaking of automation, sure would be nice if the rirs were compatible. yes, still a dreamer at my age. randy
Randy - There is a proposed timeline (done in stages) contained in the consultation - do you consider if sufficient for transition? As for clients, we’ve quite a few on github; I note that ICANN has mature RDAP client that includes solid IP/ASN support. Thanks! /John John Curran President and CEO American Registry for Internet Numbers On Aug 14, 2026, at 1:19 PM, Randy Bush <randy@psg.com> wrote: hi john, can we assume there will be somewhat finger compatible CLI client tools for most platforms? and a staged trasition, to allow for lot of automation that is gonna have to change. speaking of automation, sure would be nice if the rirs were compatible. yes, still a dreamer at my age. randy
On Fri, Aug 14, 2026 at 10:19:23AM -0700, Randy Bush via NANOG wrote:
can we assume there will be somewhat finger compatible CLI client tools for most platforms?
I know of two tools, both seem useful: https://openrdap.org/ (doas pkg_add openrdap) $ openrdap 192.0.2.1 | head IP Network: Handle: NET-192-0-2-0-1 Start Address: 192.0.2.0 End Address: 192.0.2.255 IP Version: v4 Name: TEST-NET-1 https://metacpan.org/dist/App-rdapper (doas pkg_add rdapper) $ rdapper rg.net Object type: Domain Name URL: https://rdap.joker.com/domain/rg.net Name: RG.NET Nameserver: NLNS.GLOBNIX.NET Nameserver: NS1.RG.NET IP Address: 46.224.94.61 IP Address: 2a01:4f8:1c1a:5360::1 Nameserver: RIP.PSG.COM IP Address: 147.28.0.39 IP Address: 2001:418:1::39 DS Record: rg.net. 1 IN DS 12391 8 2 0fb5f11e4fe4045d519a55915bd71d6dcfb1fa045b01be891640c8ea1c0792c9 Registration: 1993-04-28T04:00:00Z Last Changed: 2025-12-23T03:23:28Z Expiration: 2028-04-29T04:00:00Z Last update of RDAP database: 2026-08-14T17:25:00Z ...
and a staged trasition, to allow for lot of automation that is gonna have to change.
Yes, perhaps so. However, the usual "RIR IRR source -> NRTM -> IRRd instance -> query utility" flow seems out-of-scope for the proposal, right?
speaking of automation, sure would be nice if the rirs were compatible.
For posterity it might be worth to repeat what exactly the incompatibilities are and what ARIN (or other RIRs) can do to improve. Kind regards, Job
On 8/14/26, 1:19 PM, "Randy Bush via NANOG" <nanog@lists.nanog.org <mailto:nanog@lists.nanog.org>> wrote:
speaking of automation, sure would be nice if the rirs were compatible. yes, still a dreamer at my age.
The RIRs have agreed to support a base level of RDAP operations/results that are consistent to the NRO RDAP Profile specification (https://bitbucket.org/nroecg/nro-rdap-profile/raw/v1/nro-rdap-profile.txt) . In the profile document, the introduction says: " This document defines an RDAP profile for use by the RIRs, so as to increase consistency in service offerings and simplify the development of client software that uses those services." All the RIR's operate a RDAP service and have agreed to follow this profile. ARIN announced its conformance back in March of 2022 (https://www.arin.net/vault/blog/2022/03/09/nro-rdap-profile-conformance/). Regards, Mark Kosters ARIN CTO
Have you considered working with various OSen/distros to ensure they start shipping a usable client as part of their core/default? One of the lovely things about whois is that you don't need to know enough to go and install something (which may or may not be feasible, depending on everything from corporate policy through end-user capability). cheers!
On Aug 14, 2026, at 10:32, John Curran via NANOG <nanog@lists.nanog.org> wrote:
Randy -
There is a proposed timeline (done in stages) contained in the consultation - do you consider if sufficient for transition?
As for clients, we’ve quite a few on github; I note that ICANN has mature RDAP client that includes solid IP/ASN support.
Thanks! /John
John Curran President and CEO American Registry for Internet Numbers
On Aug 14, 2026, at 1:19 PM, Randy Bush <randy@psg.com> wrote:
hi john,
can we assume there will be somewhat finger compatible CLI client tools for most platforms?
and a staged trasition, to allow for lot of automation that is gonna have to change.
speaking of automation, sure would be nice if the rirs were compatible. yes, still a dreamer at my age.
randy
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/WRTHL23Q...
On 2026-08-14 16:20, John Curran via NANOG wrote:
NANOGers -
ARIN is undertaking a community consultation on the Future of ARIN’s Directory Services. If you are interested in this topic, please see details below, including how to join the ARIN-consult mailing list.
Thanks! /John
John Curran President and CEO American Registry for Internet Numbers
Begin forwarded message:
From: ARIN <info@arin.net> Subject: [ARIN-consult] Consultation on the Future of ARIN’s Directory Services Date: August 14, 2026 at 11:16:12 AM EDT To: <arin-consult@arin.net>
ARIN is seeking feedback from the community on a proposed road map to streamline and consolidate its directory services.
ARIN currently maintains four directory information protocols: Whois-RWS, RWhois, Whois (Port 43), and RDAP. Supporting multiple redundant services that provide the same information creates additional administrative and operational overhead to the organization. To reduce ARIN’s attack surface, streamline operations and lower future operational overhead, ARIN proposes retiring use of older protocols in favor of RDAP as our single, standardized directory service.
What excessive attack surface is there to operating whois? Yes, it is an additional service, but whois, in some form, has been around since forever and I am most certain that after so many years, there are well hardened whois servers available.
This transition is an important step toward improving alignment with established IETF standards.
Which rfc calls for the decommissioning of whois? If there is one, I have not heard about it yet.
We have already seen this transition in the domain industry with ICANN mandating the use of RDAP for directory services and dropping the requirement to support Whois. We also expect RDAP clients to become increasingly common in OS distributions in the coming years.
The reason why we have redundant services that provides the same information is for backwards compatibility. "[T]o become increasingly common in OS distributions in the coming years" does not inspire confidence. Right now, a whois client comes packaged and installed in every major distro. On a fresh install of fedora 44, I can run ``whois 1.2.3.4`` and it would just work, contra rdap, which requires an additional package (perl-rdapper) to be installed. Going back a bit, Fedora 42 has no packaged rdap client, unless you trust copr or snap. Fedora 42 only came to EOL this year. These types of breaking changes must not be made until rdap obtains the same level of support that whois does.
------ Benefits of Transition to RDAP
- Enhanced Directory Services: Future enhancements, such as geolocation, will only be implemented in RDAP. - Standardization and Automation: RDAP’s standardized data structure will improve automation for clients and provide greater flexibility in managing future data changes.
Great! That's amazing! However, maintaining rdap and whois simultaneously are not mutually exclusive.
- Reduced Technical Overhead: Removing old and redundant services will provide time and cost savings for ARIN.
What are the expected time and cost savings, and how do they stack up against the time and cost of everyone who currently uses whois to transition to rdap within the timeframe proposed?
------ Timeline and Retirement Planning
This consultation seeks community input for the proposed retirement timelines below. We are keenly interested in receiving specific input on any barriers and/or obstacles these changes may create for customers, as well as steps ARIN can take to ensure a smooth transition. Note that the retirement plans for each impacted directory service will be completed independently, though in some cases work may be conducted concurrently.
*** Whois-RWS Retirement Plan and Timeline
ARIN currently offers Whois-RWS in two formats: an API and a web interface (located at https://whois.arin.net/ui/). Because the API has the same functionality between Whois-RWS and RDAP, ARIN proposes sunsetting the Whois-RWS API following a 180-day customer outreach program. This will include updating the Whois-RWS payloads to include a notification to users, as well as a robust communication strategy that includes announcements, social promotion, and other outreach.
The Whois-RWS web interface will remain available until work is completed to ensure parity, providing equivalent query capabilities to RDAP. The changeover from Whois-RWS to RDAP will be transparent to end users visiting that URL. ARIN will inform the community a minimum of 30 days before the retirement of the Whois-RWS web interface, noting the switch to RDAP will not change the end user experience.
*** RWhois Retirement Plan and Timeline
When RWhois server use is retired, we will provide organizations with a recommendation for an open-source RDAP server implementation. To help ease the transition and migration of data, ARIN plans to provide a conversion tool for populating that recommended RDAP server with existing RWhois data. When the tool is publicly available, ARIN proposes a 365-day sunsetting timeline for RWhois. This will allow for robust communication and direct outreach to organizations who use RWhois and plan to either convert to the RDAP client or discontinue their use of local clients and report their reassignment information directly to ARIN instead.
*** Whois (Port 43) Retirement Plan and Timeline
ARIN understands that Whois (Port 43) carries a high volume of queries and will require the longest timeline to retire. We propose a two-year sunsetting window, during which ARIN will engage in active outreach to users. This will include updates to Whois (Port 43) results during the sunsetting period that will contain information about the retirement deadline.
Because Whois (Port 43) has been the historically preferred method of querying Internet number resource registration data, it remains heavily used by cybersecurity professionals, researchers, law enforcement, and many other types of organizations. ARIN will seek to engage beyond our community to raise awareness of the planned retirement date for Whois (Port 43).
------ After the retirement of the directory service protocols described above and listed below, ARIN will only support RDAP as our single, standardized directory service.
- Whois-RWS: on or after 1 July 2027 - RWhois: dependent on migration tool release date, but no sooner than 1 January 2028 - Whois (Port 43): on or after 1 January 2029
Throughout the sunsetting process for all services, ARIN will engage with our community to ensure customers and users are well-informed about the retirement of the described services and ARIN’s transition to RDAP as its standard directory service.
With all due respect, ARIN is an internet registry. ARIN is not some tech company that must be at the forefront of innovation, moving fast and breaking things.
We look forward to your feedback on the proposed timelines for retirement for Whois-RWS, RWhois, and Whois (Port 43). We ask that you consider each service independently, with the understanding that each of these services may impact your organization differently.
Hard no on two years for Whois as there is insufficient Rdap support at this time. No comment on Whois-RWS and RWhois.
Please provide comments to arin-consult@arin.net. You can subscribe to this mailing list at https://lists.arin.net/mailman/listinfo/arin-consult.
This consultation will remain open until 5:00 PM ET on 14 September 2026. ARIN seeks clear direction through community input, so your feedback is important.
Thank you for your continued support in improving ARIN’s services.
Regards,
John Curran President and CEO ARIN
------ Relevant links: - Presentation from ARIN 56: https://www.arin.net/participate/meetings/ARIN56/materials/arin56_directorys... - IETF Standard for RDAP: https://www.rfc-editor.org/info/std95 - Guide to RDAP Client Implementations: https://rdap.rcode3.com/client_implementations/index.html - ARIN RDAP Documentation: https://www.arin.net/resources/registry/whois/rdap/ _______________________________________________ ARIN-Consult _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/VPMTFPBU...
What excessive attack surface is there to operating whois? Yes, it is an additional service, but whois, in some form, has been around since forever and I am most certain that after so many years, there are well hardened whois servers available.
i too have been around since forever. but i am hard to maintain, crufty, and there are younger net geeks who are probably better them i at some of the modern stuff. randy
</lurk><grumpy_old_router_hacker> when I asked the goog^WAI about CLI rdap tools, one suggestion was "nicinfo," apparently produced by ARIN. deprecated, and they recommended icann-rdap, which is produced in rust. It is still compiling on my development system as I write this. Compiling icann-rdap-cli v0.0.31 (/home/sthomas/src/icann-rdap/icann-rdap-cli) Building [=======================> ] 539/545: rdap-srv-data(bin), rdap-test(bin), rdap(bin), rdap-srv(bin) meanwhile, on one of the few cores not getting rusted... <farfarello:/usr/src/usr.bin/whois% wc -l whois.c 610 whois.c <farfarello:/usr/src/usr.bin/whois% make [Creating objdir /usr/obj/usr/src/amd64.amd64/usr.bin/whois...] echo whois.full: /usr/lib/libc.a >> .depend cc -fpie -DPIC -O2 -pipe -fno-common -fPIE -ffile-prefix-map=/usr/src=/usr/src -ffile-prefix-map=/usr/obj/usr/src=/usr/obj -g -gz=zlib -MD -MF.depend.whois.pieo -MTwhois.pieo -std=gnu17 -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Wnested-externs -Wold-style-definition -Wno-pointer-sign -Wdate-time -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-error=unused-but-set-parameter -Wno-error=cast-function-type-mismatch -Qunused-arguments -c /usr/src/usr.bin/whois/whois.c -o whois.pieo cc -O2 -pipe -fno-common -fPIE -ffile-prefix-map=/usr/src=/usr/src -ffile-prefix-map=/usr/obj/usr/src=/usr/obj -g -gz=zlib -std=gnu17 -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Wnested-externs -Wold-style-definition -Wno-pointer-sign -Wdate-time -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-error=unused-but-set-parameter -Wno-error=cast-function-type-mismatch -Qunused-arguments -Wl,-zrelro -pie -o whois.full whois.pieo objcopy --only-keep-debug whois.full whois.debug objcopy --strip-debug --add-gnu-debuglink=whois.debug whois.full whois gzip -cn /usr/src/usr.bin/whois/whois.1 > whois.1.gz <farfarello:/usr/obj/usr/src/amd64.amd64/usr.bin/whois% ls -lh whois -rwxr-xr-x 1 sthomas wheel 17K Aug 15 19:08 whois the icann-rdap build finally finished: <farfarello:~/src/icann-rdap/target/release% ls -lh rdap -rwxr-xr-x 2 sthomas sthomas 18M Aug 15 19:08 rdap only 1000x the bits to do the same job; progress!. :) tongue firmly in cheek, as I do love the JSON, but good grief do we have to make everything this way? it's perfectly ok to have one standard for machine-to-machine data exchange and a separate standard for human consumption, especially if we rely on only one canonical source for the data. On Fri, Aug 14, 2026 at 12:37 PM Job Snijders via NANOG <nanog@lists.nanog.org> wrote:
On Fri, Aug 14, 2026 at 10:19:23AM -0700, Randy Bush via NANOG wrote:
can we assume there will be somewhat finger compatible CLI client tools for most platforms?
I know of two tools, both seem useful:
https://openrdap.org/ (doas pkg_add openrdap)
$ openrdap 192.0.2.1 | head IP Network: Handle: NET-192-0-2-0-1 Start Address: 192.0.2.0 End Address: 192.0.2.255 IP Version: v4 Name: TEST-NET-1
https://metacpan.org/dist/App-rdapper (doas pkg_add rdapper)
$ rdapper rg.net Object type: Domain Name URL: https://rdap.joker.com/domain/rg.net Name: RG.NET Nameserver: NLNS.GLOBNIX.NET Nameserver: NS1.RG.NET IP Address: 46.224.94.61 IP Address: 2a01:4f8:1c1a:5360::1 Nameserver: RIP.PSG.COM IP Address: 147.28.0.39 IP Address: 2001:418:1::39 DS Record: rg.net. 1 IN DS 12391 8 2 0fb5f11e4fe4045d519a55915bd71d6dcfb1fa045b01be891640c8ea1c0792c9 Registration: 1993-04-28T04:00:00Z Last Changed: 2025-12-23T03:23:28Z Expiration: 2028-04-29T04:00:00Z Last update of RDAP database: 2026-08-14T17:25:00Z ...
and a staged trasition, to allow for lot of automation that is gonna have to change.
Yes, perhaps so.
However, the usual "RIR IRR source -> NRTM -> IRRd instance -> query utility" flow seems out-of-scope for the proposal, right?
speaking of automation, sure would be nice if the rirs were compatible.
For posterity it might be worth to repeat what exactly the incompatibilities are and what ARIN (or other RIRs) can do to improve.
Kind regards,
Job _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/RLT3RT54...
According to Lavender-Jamie via NANOG <nanog@lists.nanog.org>:
Which rfc calls for the decommissioning of whois? If there is one, I have not heard about it yet.
None, but ICANN told their contracted TLDs to support RDAP by February 2024 for DNS names. In January 2025 they said that WHOIS is no longer required, and a lot of them have now turned off their WHOIS servers.
These types of breaking changes must not be made until rdap obtains the same level of support that whois does.
We passed that point several years ago. I have scripts that do a lot of lookups of both IPs and domain names, and they use RDAP for everything other than a few country ccTLDs that still don't do RDAP. RDAP is much, much better than WHOIS. It has well defined query and response syntax rather than being an ill-defined adaptation of a 50 year old proticol invented for something else, and since it's based on HTTP it automatically handles redirects and forwarding and encryption yin transit. R's, John
On 8/15/26 8:26 PM, Sam Thomas via NANOG wrote:
</lurk><grumpy_old_router_hacker>
when I asked the goog^WAI about CLI rdap tools, one suggestion was "nicinfo," apparently produced by ARIN.
deprecated, and they recommended icann-rdap, which is produced in rust. It is still compiling on my development system as I write this.
Compiling icann-rdap-cli v0.0.31 (/home/sthomas/src/icann-rdap/icann-rdap-cli) Building [=======================> ] 539/545: rdap-srv-data(bin), rdap-test(bin), rdap(bin), rdap-srv(bin)
Its one thing to write something in Rust, its something entirely different to have FIVE HUNDRED AND FOURTY FIVE DEPENDENCIES. In what world is that even remotely acceptable for modern software that people might want to use in production environments. Matt
On 8/17/26 4:11 PM, Matt Corallo via NANOG wrote:
Compiling icann-rdap-cli v0.0.31 (/home/sthomas/src/icann-rdap/icann-rdap-cli) Building [=======================> ] 539/545: rdap-srv-data(bin), rdap-test(bin), rdap(bin), rdap-srv(bin) Its one thing to write something in Rust, its something entirely different to have FIVE HUNDRED AND FOURTY FIVE DEPENDENCIES. In what world is that even remotely acceptable for modern software that people might want to use in production environments.
If you look closely, he didn't just compile the client. Also, that client does A LOT more than a typical WHOIS client. This is an apples-to-oranges comparison. The users manual is here: https://icann.github.io/icann-rdap/rdap-cli-tools/cli-client/ It includes instructions on how to get pre-built binaries and pointers to packages. As was stated upthread, there are plenty of RDAP clients and plenty pre-packaged: https://pkgs.org/search/?q=rdap -andy
Its one thing to write something in Rust, its something entirely different to have FIVE HUNDRED AND FOURTY FIVE DEPENDENCIES. In what world is that even remotely acceptable for modern software that people might want to use in production environments.
For Rust, <1000 for any full featured application is pretty decent. I also fail to see why it matters. On Mon, Aug 17, 2026 at 4:12 PM Matt Corallo via NANOG < nanog@lists.nanog.org> wrote:
On 8/15/26 8:26 PM, Sam Thomas via NANOG wrote:
</lurk><grumpy_old_router_hacker>
when I asked the goog^WAI about CLI rdap tools, one suggestion was "nicinfo," apparently produced by ARIN.
deprecated, and they recommended icann-rdap, which is produced in rust. It is still compiling on my development system as I write this.
Compiling icann-rdap-cli v0.0.31 (/home/sthomas/src/icann-rdap/icann-rdap-cli) Building [=======================> ] 539/545: rdap-srv-data(bin), rdap-test(bin), rdap(bin), rdap-srv(bin)
Its one thing to write something in Rust, its something entirely different to have FIVE HUNDRED AND FOURTY FIVE DEPENDENCIES. In what world is that even remotely acceptable for modern software that people might want to use in production environments.
Matt _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/4WX4EHZ5...
Compiling icann-rdap-cli v0.0.31 (/home/sthomas/src/icann-rdap/icann-rdap-cli) Building [=======================> ] 539/545: rdap-srv-data(bin), rdap-test(bin), rdap(bin), rdap-srv(bin)
Its one thing to write something in Rust, its something entirely different to have FIVE HUNDRED AND FOURTY FIVE DEPENDENCIES. In what world is that even remotely acceptable for modern software that people might want to use in production environments.
it's the fashionable way to be sure to catch as many supply chain attacks as you can you'll love iirdv4 randy
John, Your email says "This transition is an important step toward improving alignment with established IETF standards.", aligning a new feature to a standard doesn't mean shutting down a service that is used in so many ways, and expecting users to rely on a service that by your own admission isn't the standard in todays OS deployments. Wouldn't it make sense to work with the OS community to rdap clients ubiquitous before pushing a sunset of whois? Shane On Sat, Aug 15, 2026 at 10:06 PM John Levine via NANOG < nanog@lists.nanog.org> wrote:
According to Lavender-Jamie via NANOG <nanog@lists.nanog.org>:
Which rfc calls for the decommissioning of whois? If there is one, I have not heard about it yet.
None, but ICANN told their contracted TLDs to support RDAP by February 2024 for DNS names. In January 2025 they said that WHOIS is no longer required, and a lot of them have now turned off their WHOIS servers.
These types of breaking changes must not be made until rdap obtains the same level of support that whois does.
We passed that point several years ago. I have scripts that do a lot of lookups of both IPs and domain names, and they use RDAP for everything other than a few country ccTLDs that still don't do RDAP.
RDAP is much, much better than WHOIS. It has well defined query and response syntax rather than being an ill-defined adaptation of a 50 year old proticol invented for something else, and since it's based on HTTP it automatically handles redirects and forwarding and encryption yin transit.
R's, John _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/HF6T4KG6...
On Tue, Aug 18, 2026 at 07:44:31PM -0400, Shane Ronan via NANOG wrote:
Your email says "This transition is an important step toward improving alignment with established IETF standards.", aligning a new feature to a standard doesn't mean shutting down a service that is used in so many ways, and expecting users to rely on a service that by your own admission isn't the standard in todays OS deployments.
Wouldn't it make sense to work with the OS community to rdap clients ubiquitous before pushing a sunset of whois?
I strongly concur with this. There are no doubt a LOT of people who have no idea that any of this happening, but who have built extensive tooling on top of whois and will not be happy when it all suddenly breaks (with whatever operational consequences that implies). What needs to happen is: (1) the developers of every significant whois client need to be notified (2) they need to be convinced to put a notice in the client software (3) they need to push a release (4) the release needs to be picked up by every significant OS distribution (5) the release needs to be adopted by most of the users those OS distributions. And then (6) software with equivalent functionality needs to be developed and tested and deployed and picked up and so on. Maybe that means modifying what already exists, maybe it means starting over; but whatever it is, it needs to be ubiquitous *well before* anyone can even consider discussing turning off whois. That's going to take a long time -- years. But it needs to be done in order to avoid blindsiding a lot of people who've spent years (decades) building and relying on whois. ---rsk
Also, there are users, who occasionally want to check something and will be turned away. On Fri, Aug 21, 2026 at 8:54 PM Rich Kulawiec via NANOG < nanog@lists.nanog.org> wrote:
On Tue, Aug 18, 2026 at 07:44:31PM -0400, Shane Ronan via NANOG wrote:
Your email says "This transition is an important step toward improving alignment with established IETF standards.", aligning a new feature to a standard doesn't mean shutting down a service that is used in so many ways, and expecting users to rely on a service that by your own admission isn't the standard in todays OS deployments.
Wouldn't it make sense to work with the OS community to rdap clients ubiquitous before pushing a sunset of whois?
I strongly concur with this. There are no doubt a LOT of people who have no idea that any of this happening, but who have built extensive tooling on top of whois and will not be happy when it all suddenly breaks (with whatever operational consequences that implies).
What needs to happen is: (1) the developers of every significant whois client need to be notified (2) they need to be convinced to put a notice in the client software (3) they need to push a release (4) the release needs to be picked up by every significant OS distribution (5) the release needs to be adopted by most of the users those OS distributions. And then (6) software with equivalent functionality needs to be developed and tested and deployed and picked up and so on. Maybe that means modifying what already exists, maybe it means starting over; but whatever it is, it needs to be ubiquitous *well before* anyone can even consider discussing turning off whois.
That's going to take a long time -- years. But it needs to be done in order to avoid blindsiding a lot of people who've spent years (decades) building and relying on whois.
---rsk _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/4EX2LDRH...
It appears that Rich Kulawiec via NANOG <nanog@lists.nanog.org> said:
I strongly concur with this. There are no doubt a LOT of people who have no idea that any of this happening, but who have built extensive tooling on top of whois and will not be happy when it all suddenly breaks (with whatever operational consequences that implies).
I'm scratching my head. Is it really the case that nobody here has been using WHOIS to look up domain name info? Because that ship sailed years ago. ICANN mandated RDAP with about a two-year transition period which was over last year. If you want to get (what remains of) info about domains, you have to use RDAP, with a little bit of WHOIS left for some country code TLDs. Having written scripts to do all this, both for domains and for IPs and ASNs, I can say it was sort of annoying, but writing RDAP scripts is vastly simpler because there is nothing to parse. You do an https request and decode the JSON and you're done. That's a line or two in the programming languages people use. You don't even have to guess which RDAP server to use because IANA has bootstrap files: https://data.iana.org/rdap/asn.json https://data.iana.org/rdap/ipv4.json https://data.iana.org/rdap/ipv6.json R's, John
I'm scratching my head. Is it really the case that nobody here has been using WHOIS to look up domain name info? Because that ship sailed years ago.
why would one given that anything useful is redacted? randy
On Fri, Aug 21, 2026 at 6:42 PM John Levine via NANOG <nanog@lists.nanog.org> wrote:
I'm scratching my head. Is it really the case that nobody here has been using WHOIS to look up domain name info? Because that ship sailed years ago. ICANN mandated RDAP with about a two-year transition period which was over last year. If you want to get (what remains of) info about domains, you have to use RDAP, with a little bit of WHOIS left for some country code TLDs.
I just did a "whois" on my own domains and found it still working. And I checked under the hood - the client isn't using RDAP. Maybe there's a disconnect between announcement and practice here? And the lack of outcry is because pragmatically speaking whois still works? Regards, Bill Herrin
Curious, why retire Whois? With the ever increasing ARIN rates, can y’all not afford to continue the service? As it stands now, every time i use the whois web client (couple times a week), it never loads the first time (on any device and on any network i’m on) and i have to reload the page. How hard and expensive can it be to keep a whois webpage up and running? -Mike
On Aug 21, 2026, at 19:56, William Herrin via NANOG <nanog@lists.nanog.org> wrote:
On Fri, Aug 21, 2026 at 6:42 PM John Levine via NANOG <nanog@lists.nanog.org> wrote:
I'm scratching my head. Is it really the case that nobody here has been using WHOIS to look up domain name info? Because that ship sailed years ago. ICANN mandated RDAP with about a two-year transition period which was over last year. If you want to get (what remains of) info about domains, you have to use RDAP, with a little bit of WHOIS left for some country code TLDs.
I just did a "whois" on my own domains and found it still working. And I checked under the hood - the client isn't using RDAP.
Maybe there's a disconnect between announcement and practice here? And the lack of outcry is because pragmatically speaking whois still works?
Regards, Bill Herrin _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/3O227WEG...
On Fri, 21 Aug 2026, William Herrin wrote:
I just did a "whois" on my own domains and found it still working. And I checked under the hood - the client isn't using RDAP.
It depends on the registry. Verisign and PIR which run com, net, and org, still have whois, Identity Digital which runs .info and a lot of other smaller domains doesn't.
Maybe there's a disconnect between announcement and practice here? And the lack of outcry is because pragmatically speaking whois still works?
No, it's because people who do domain WHOIS have seen the news from ICANN and done the small amount of work to move to RDAP. Re Randy's comment, a lot of info is redacted but again it depends on the registrar. Everyone still provides registration and expiration dates and a link to the registrar, some registrars provide a lot more. Look for example at GURUS.COM which I sold about 30 years ago and has been baouncing around among speculators ever since. R's, John
As it stands now, every time i use the whois web client (couple times a week), it never loads the first time (on any device and on any network i’m on) and i have to reload the page.
WHOIS is a very old protocol originally defined in RFC 812 in 1982 and slightly updated by RFCs 954 and 3912. It is much older than the web and has nothing to do with the web. There are web pages that fetch WHOIS info (perhaps using RDAP) and display it, but that's something else.
How hard and expensive can it be to keep a whois webpage up and running?
I don't know, but honestly, who cares. Here is a dandy RDAP client that runs entirely in your browser. https://client.rdap.org/ R's, John
Hello John , Are you the RDAP Sales Person , Because every word you have spoken about (r)whois & the proponent product have been exactly in the vien of trying to Sell ... My opinion , JimL On Sat, 22 Aug 2026, John R. Levine via NANOG wrote:
As it stands now, every time i use the whois web client (couple times a week), it never loads the first time (on any device and on any network i?m on) and i have to reload the page.
WHOIS is a very old protocol originally defined in RFC 812 in 1982 and slightly updated by RFCs 954 and 3912. It is much older than the web and has nothing to do with the web. There are web pages that fetch WHOIS info (perhaps using RDAP) and display it, but that's something else.
How hard and expensive can it be to keep a whois webpage up and running?
I don't know, but honestly, who cares. Here is a dandy RDAP client that runs entirely in your browser.
R's, John
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/MKXBWH5D...
-- +---------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network & System Engineer | 3237 Holden Road | Give me Linux | | jiml@system-techniques.com | Fairbanks, AK. 99709 | only on AXP | +---------------------------------------------------------------------+
Hello John , Are you the RDAP Sales Person , Because every word you have spoken about (r)whois & the proponent product have been exactly in the vien of trying to Sell ...
I get a 50% commission on every RDAP sale! Wow! Too bad it's free. But it really does work better than WHOIS. R's, John
On Sat, 22 Aug 2026, John R. Levine via NANOG wrote:
As it stands now, every time i use the whois web client (couple times a week), it never loads the first time (on any device and on any network i?m on) and i have to reload the page.
WHOIS is a very old protocol originally defined in RFC 812 in 1982 and slightly updated by RFCs 954 and 3912. It is much older than the web and has nothing to do with the web. There are web pages that fetch WHOIS info (perhaps using RDAP) and display it, but that's something else.
How hard and expensive can it be to keep a whois webpage up and running?
I don't know, but honestly, who cares. Here is a dandy RDAP client that runs entirely in your browser.
If they both reference the same underlying data maybe just leave rwhois there but make it intentionally slower over time... If they somehow don't reference the same underlying data, well, fix that first by maybe just making rwhois a proxy to rdap? On Sun, Aug 23, 2026 at 2:51 PM John R. Levine via NANOG < nanog@lists.nanog.org> wrote:
Hello John , Are you the RDAP Sales Person , Because every word you have spoken about (r)whois & the proponent product have been exactly
in
the vien of trying to Sell ...
I get a 50% commission on every RDAP sale! Wow!
Too bad it's free. But it really does work better than WHOIS.
On Sat, 22 Aug 2026, John R. Levine via NANOG wrote:
As it stands now, every time i use the whois web client (couple times a week), it never loads the first time (on any device and on any network i?m on) and i have to reload the page.
WHOIS is a very old protocol originally defined in RFC 812 in 1982 and slightly updated by RFCs 954 and 3912. It is much older than the web and has nothing to do with the web. There are web pages that fetch WHOIS info (perhaps using RDAP) and display it, but that's something else.
How hard and expensive can it be to keep a whois webpage up and running?
I don't know, but honestly, who cares. Here is a dandy RDAP client
R's, John that
runs entirely in your browser.
NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/VXPEE5FZ...
If they both reference the same underlying data maybe just leave rwhois there but make it intentionally slower over time...
That seems awfully passive aggressive. For domains, ICANN set a timeline and after a little bit of grumbling, we adapted. I did it, it wasn't hard. While I was at it I switched the IP and ASN lookups to RDAP too.
If they somehow don't reference the same underlying data, well, fix that first by maybe just making rwhois a proxy to rdap?
It occurs to me that if people REALLY REALLY want WHOIS, it would not be terribly hard to write a proxy that puts a WHOIS front end on RDAP servers. Here's one that goes the other way: https://github.com/redirect2me/rdap-proxy R's, John
On Sun, Aug 23, 2026 at 2:51 PM John R. Levine via NANOG < nanog@lists.nanog.org> wrote:
Hello John , Are you the RDAP Sales Person , Because every word you have spoken about (r)whois & the proponent product have been exactly in the vien of trying to Sell ...
I get a 50% commission on every RDAP sale! Wow!
Too bad it's free. But it really does work better than WHOIS.
John R. Levine via NANOG wrote on 23/08/2026 23:22:
It occurs to me that if people REALLY REALLY want WHOIS, it would not be terribly hard to write a proxy that puts a WHOIS front end on RDAP servers.
Or even simpler: $ brew install rdap $ echo alias whois rdap >> ~/.bashrc $ . ~/.bashrc As a benefit of this, you'll even get parsable yaml (or json / xml if you want that instead), instead of the unstructured mess you get with whois. Nick
On Aug 28, 2026, at 5:28 AM, Nick Hilliard via NANOG <nanog@lists.nanog.org> wrote:
John R. Levine via NANOG wrote on 23/08/2026 23:22:
It occurs to me that if people REALLY REALLY want WHOIS, it would not be terribly hard to write a proxy that puts a WHOIS front end on RDAP servers.
Or even simpler:
$ brew install rdap $ echo alias whois rdap >> ~/.bashrc $ . ~/.bashrc
While I definitely agree that RDAP is vastly preferable to Whois, care may be warranted here. Aliasing whois to rdap will (may?) work for address lookups, a large number of ccTLDs do not support RDAP (of course, some don’t even support Whois either) and some TLDs (both cc and g) block IPs, e.g., from cloud providers or, oddly, residential ISP blocks. (I’ll spare everyone the rants about the degradation of the usefulness of registration databases and the increasing insanity of IP block lists) Regards, -drc
On Fri, 28 Aug 2026, David Conrad wrote:
John R. Levine via NANOG wrote on 23/08/2026 23:22:
It occurs to me that if people REALLY REALLY want WHOIS, it would not be terribly hard to write a proxy that puts a WHOIS front end on RDAP servers.
While I definitely agree that RDAP is vastly preferable to Whois, care may be warranted here. Aliasing whois to rdap will (may?) work for address lookups, a large number of ccTLDs do not support RDAP (of course, some don’t even support Whois either) and some TLDs (both cc and g) block IPs, e.g., from cloud providers or, oddly, residential ISP blocks.
Remember that this argument was about WHOIS and RDAP at the RIRs. They all do RDAP, and as I'm sure you know, adjusting your code to use it is not hard. I agree it's harder for domains due to the tail of ccTLDs that don't do RDAP, but few of those have WHOIS that returns anything useful. I have been fighting domain RDAP/WHOIS rate limits and I've found that they're the same either way for registries that do both. R's, John
John, On Aug 28, 2026, at 10:56 AM, John R. Levine <johnl@iecc.com> wrote:
On Fri, 28 Aug 2026, David Conrad wrote:
While I definitely agree that RDAP is vastly preferable to Whois, care may be warranted here. Aliasing whois to rdap will (may?) work for address lookups, a large number of ccTLDs do not support RDAP (of course, some don’t even support Whois either) and some TLDs (both cc and g) block IPs, e.g., from cloud providers or, oddly, residential ISP blocks.
Remember that this argument was about WHOIS and RDAP at the RIRs.
I was responding to Nick who was suggesting aliasing ‘whois’ to ‘rdap’. My point was that this would break some DNS-related ‘whois’ lookups that “work".
I agree it's harder for domains due to the tail of ccTLDs that don't do RDAP, but few of those have WHOIS that returns anything useful.
My experience with RDAP at the ccTLDs suggests the tail is quite fat (I ran a quick test and it suggested there were 134 TLDs that answered Whois but not RDAP), but I’d agree that the folks who don’t do RDAP are also unlikely to do anything useful for Whois. Regards, -drc
Actually, I think RIRs could actually run proxy themselfs, and generate WHOIS reply based on RDAP data. Why not? ---------- Original message ---------- From: Nick Hilliard via NANOG <nanog@lists.nanog.org> To: North American Network Operators Group <nanog@lists.nanog.org> Cc: John R. Levine <johnl@iecc.com>, Nick Hilliard <nick@foobar.org> Subject: Re: Whois using these ARIN services?? (fwd: Consultation on the Future of ARIN???s Directory Services) Date: Fri, 28 Aug 2026 13:28:43 +0100 John R. Levine via NANOG wrote on 23/08/2026 23:22:
It occurs to me that if people REALLY REALLY want WHOIS, it would not be terribly hard to write a proxy that puts a WHOIS front end on RDAP servers.
Or even simpler: $ brew install rdap $ echo alias whois rdap >> ~/.bashrc $ . ~/.bashrc As a benefit of this, you'll even get parsable yaml (or json / xml if you want that instead), instead of the unstructured mess you get with whois. Nick _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/RRSXMQ5C...
Hello Borg , The first sensible statement i've from either oponents or sales types . Tnx , JimL On Sat, 29 Aug 2026, borg--- via NANOG wrote:
Actually, I think RIRs could actually run proxy themselfs, and generate WHOIS reply based on RDAP data. Why not?
---------- Original message ----------
From: Nick Hilliard via NANOG <nanog@lists.nanog.org> To: North American Network Operators Group <nanog@lists.nanog.org> Cc: John R. Levine <johnl@iecc.com>, Nick Hilliard <nick@foobar.org> Subject: Re: Whois using these ARIN services?? (fwd: Consultation on the Future of ARIN???s Directory Services) Date: Fri, 28 Aug 2026 13:28:43 +0100
John R. Levine via NANOG wrote on 23/08/2026 23:22:
It occurs to me that if people REALLY REALLY want WHOIS, it would not be terribly hard to write a proxy that puts a WHOIS front end on RDAP servers.
Or even simpler:
$ brew install rdap $ echo alias whois rdap >> ~/.bashrc $ . ~/.bashrc
As a benefit of this, you'll even get parsable yaml (or json / xml if you want that instead), instead of the unstructured mess you get with whois.
Nick
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/RRSXMQ5C... _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/4BYYJBWD...
-- +---------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network & System Engineer | 3237 Holden Road | Give me Linux | | jiml@system-techniques.com | Fairbanks, AK. 99709 | only on AXP | +---------------------------------------------------------------------+
"I want the RIRs to do this so I don't have to do it." then some time later "Why are the RIRs charging so much in renewal fees?" On Sat, Aug 29, 2026 at 3:05 AM borg--- via NANOG <nanog@lists.nanog.org> wrote:
Actually, I think RIRs could actually run proxy themselfs, and generate WHOIS reply based on RDAP data. Why not?
---------- Original message ----------
From: Nick Hilliard via NANOG <nanog@lists.nanog.org> To: North American Network Operators Group <nanog@lists.nanog.org> Cc: John R. Levine <johnl@iecc.com>, Nick Hilliard <nick@foobar.org> Subject: Re: Whois using these ARIN services?? (fwd: Consultation on the Future of ARIN???s Directory Services) Date: Fri, 28 Aug 2026 13:28:43 +0100
John R. Levine via NANOG wrote on 23/08/2026 23:22:
It occurs to me that if people REALLY REALLY want WHOIS, it would not be terribly hard to write a proxy that puts a WHOIS front end on RDAP servers.
Or even simpler:
$ brew install rdap $ echo alias whois rdap >> ~/.bashrc $ . ~/.bashrc
As a benefit of this, you'll even get parsable yaml (or json / xml if you want that instead), instead of the unstructured mess you get with whois.
Nick
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/RRSXMQ5C... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/4BYYJBWD...
On Sat, Aug 29, 2026 at 12:04 AM borg--- via NANOG <nanog@lists.nanog.org> wrote:
Actually, I think RIRs could actually run proxy themselfs, and generate WHOIS reply based on RDAP data. Why not?
Your telephone landline (if you still have one) or VoIP to POTS adapter usually supports rotary dialing. It's been nearly half a century since anyone made a rotary phone but the POTS equipment still supports rotary dialing. Why? Because backward compatibility is valuable. There's a disadvantage to building a POTS adapter which is less than 100% backward compatible. And the cost to implement a user-interface skin atop modern signaling which implements rotary dialing is utterly trivial. So I agree with you: why shouldn't the RIR use an RDAP server that also provides a whois-compatible user interface skin? And do so indefinitely? Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/
Your telephone landline (if you still have one) or VoIP to POTS adapter usually supports rotary dialing. It's been nearly half a century since anyone made a rotary phone but the POTS equipment still supports rotary dialing.
Why?
Because backward compatibility is valuable. There's a disadvantage to building a POTS adapter which is less than 100% backward compatible. And the cost to implement a user-interface skin atop modern signaling which implements rotary dialing is utterly trivial.
So I agree with you: why shouldn't the RIR use an RDAP server that also provides a whois-compatible user interface skin? And do so indefinitely?
The PSTN hasn't supported pulse 'indefinitely'. In the 60s when DTMF was deployed, the PSTN supported both as a transition mechanism for 30 years. In the 90s, LECs started retiring the pulse equipment, moving to DTMF only. Once a given network did that, users then were required to use a pulse-DTMF adapter to continue using the system with old equipment. While some systems still haven't fully retired pulse, most have. Almost everything in tech moves through these transition cycles. Start with A , run A + B in parallel, retire A. Demanding that A and B run in parallel indefinitely just because "I don't want to change my thing that relies on A" is silly. On Sun, Aug 30, 2026 at 12:16 AM William Herrin via NANOG < nanog@lists.nanog.org> wrote:
On Sat, Aug 29, 2026 at 12:04 AM borg--- via NANOG <nanog@lists.nanog.org> wrote:
Actually, I think RIRs could actually run proxy themselfs, and generate WHOIS reply based on RDAP data. Why not?
Your telephone landline (if you still have one) or VoIP to POTS adapter usually supports rotary dialing. It's been nearly half a century since anyone made a rotary phone but the POTS equipment still supports rotary dialing.
Why?
Because backward compatibility is valuable. There's a disadvantage to building a POTS adapter which is less than 100% backward compatible. And the cost to implement a user-interface skin atop modern signaling which implements rotary dialing is utterly trivial.
So I agree with you: why shouldn't the RIR use an RDAP server that also provides a whois-compatible user interface skin? And do so indefinitely?
Regards, Bill Herrin
-- For hire. https://bill.herrin.us/resume/ _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/7SIXWDUQ...
On 8/30/26 12:15 AM, William Herrin via NANOG wrote:
So I agree with you: why shouldn't the RIR use an RDAP server that also provides a whois-compatible user interface skin? And do so indefinitely?
There are RDAP clients that produce WHOIS output. Though I suspect people needing to parse WHOIS output gave up on that fragile endeavor long ago and switched to RDAP. The numbers prove it. rdap.org just reported a 4x jump in bootstrap queries since January. Also see [1]. I get that a transition plan could use more than a flag day, but for eye-balls there isn't much difference between WHOIS and RDAP. -andy [1] https://www.ietf.org/blog/current-state-of-rdap/
I'll have to check again -- as recently as a couple of months ago, my VOIP line was perfectly happy to support pulse dial (ditto the land line). That aside -- there's a great deal to be said for maintaining simple and easy to manage interfaces with a substantial history of tooling and support -- ones that don't require expensive upgrades, time from specialists, or (I'm looking at you, SNMP) can't be understood by (most) humans in their native form. cheers!
On Aug 30, 2026, at 06:52, Tom Beecher via NANOG <nanog@lists.nanog.org> wrote:
Your telephone landline (if you still have one) or VoIP to POTS adapter usually supports rotary dialing. It's been nearly half a century since anyone made a rotary phone but the POTS equipment still supports rotary dialing.
Why?
Because backward compatibility is valuable. There's a disadvantage to building a POTS adapter which is less than 100% backward compatible. And the cost to implement a user-interface skin atop modern signaling which implements rotary dialing is utterly trivial.
So I agree with you: why shouldn't the RIR use an RDAP server that also provides a whois-compatible user interface skin? And do so indefinitely?
The PSTN hasn't supported pulse 'indefinitely'. In the 60s when DTMF was deployed, the PSTN supported both as a transition mechanism for 30 years. In the 90s, LECs started retiring the pulse equipment, moving to DTMF only. Once a given network did that, users then were required to use a pulse-DTMF adapter to continue using the system with old equipment. While some systems still haven't fully retired pulse, most have.
Almost everything in tech moves through these transition cycles. Start with A , run A + B in parallel, retire A. Demanding that A and B run in parallel indefinitely just because "I don't want to change my thing that relies on A" is silly.
On Sun, Aug 30, 2026 at 12:16 AM William Herrin via NANOG < nanog@lists.nanog.org> wrote:
On Sat, Aug 29, 2026 at 12:04 AM borg--- via NANOG <nanog@lists.nanog.org> wrote:
Actually, I think RIRs could actually run proxy themselfs, and generate WHOIS reply based on RDAP data. Why not?
Your telephone landline (if you still have one) or VoIP to POTS adapter usually supports rotary dialing. It's been nearly half a century since anyone made a rotary phone but the POTS equipment still supports rotary dialing.
Why?
Because backward compatibility is valuable. There's a disadvantage to building a POTS adapter which is less than 100% backward compatible. And the cost to implement a user-interface skin atop modern signaling which implements rotary dialing is utterly trivial.
So I agree with you: why shouldn't the RIR use an RDAP server that also provides a whois-compatible user interface skin? And do so indefinitely?
Regards, Bill Herrin
-- For hire. https://bill.herrin.us/resume/ _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/7SIXWDUQ...
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/GQCZWRRY...
Uh, first off all. Its not a service that needs constant babysitting. You set up it once and forget, probably forever. Second, its not 80s or 90s, compute is cheap.. very cheap. Are you saying that running such proxy is such a problem? I doubt it... ---------- Original message ---------- From: Tom Beecher <beecher@beecher.cc> To: North American Network Operators Group <nanog@lists.nanog.org> Cc: borg@uu3.net Subject: Re: Whois using these ARIN services?? (fwd: Consultation on the Future of ARIN???s Directory Services) Date: Sat, 29 Aug 2026 20:22:24 -0400 "I want the RIRs to do this so I don't have to do it." then some time later "Why are the RIRs charging so much in renewal fees?" On Sat, Aug 29, 2026 at 3:05˙˙AM borg--- via NANOG <nanog@lists.nanog.org> wrote:
Actually, I think RIRs could actually run proxy themselfs, and generate WHOIS reply based on RDAP data. Why not?
---------- Original message ----------
From: Nick Hilliard via NANOG <nanog@lists.nanog.org> To: North American Network Operators Group <nanog@lists.nanog.org> Cc: John R. Levine <johnl@iecc.com>, Nick Hilliard <nick@foobar.org> Subject: Re: Whois using these ARIN services?? (fwd: Consultation on the Future of ARIN???s Directory Services) Date: Fri, 28 Aug 2026 13:28:43 +0100
John R. Levine via NANOG wrote on 23/08/2026 23:22:
It occurs to me that if people REALLY REALLY want WHOIS, it would not be terribly hard to write a proxy that puts a WHOIS front end on RDAP servers.
Or even simpler:
$ brew install rdap $ echo alias whois rdap >> ~/.bashrc $ . ~/.bashrc
As a benefit of this, you'll even get parsable yaml (or json / xml if you want that instead), instead of the unstructured mess you get with whois.
Nick
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/RRSXMQ5C... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/4BYYJBWD...
On Sat, Aug 15, 2026 at 09:59:54AM -0400, Patrick Klos wrote:
Don't tell me that the text based WHOIS service creates a greater "threat landscape" or "attack vector". Text based WHOIS has been around for decades - by now, I'm sure it's quite hardened!
On Sun, Aug 16, 2026 at 12:59:31AM +0100, Lavender-Jamie via ARIN-consult wrote:
What excessive attack surface is there to operating whois? Yes, it is an additional service, but whois, in some form, has been around since forever and I am most certain that after so many years, there are well hardened whois servers available.
The threat is in the use of the protocol. Port 43 Whois query/response transactions are susceptible to man-in-the-middle attacks due to the unauthenticated and unencrypted nature of the WHOIS protocol. "Hardening" the Whois server does nothing to mitigate the risk of data interception or undetected tampering: there is no transport security in port 43 Whois. WHOIS-based services simply lack mechanisms for integrity and confidentiality. The above means that entities using port 43 are at significant risk if they are making any kind of business decisions based on the WHOIS data retrieved via an insecure channel. Kind regards, Job ps. ARIN discontinued unsafe protocols before https://www.arin.net/announcements/20250204/
Agreed, but none of that risks data tampering or attacks affecting the operator, only the data consumer *choosing* to use the old way are at risk, and they can remedy it whenever they want. They can be grownups and make their own choices as long as the blast radius is just themselves. On Tue, Sep 1, 2026 at 5:10 AM Job Snijders via NANOG <nanog@lists.nanog.org> wrote:
On Sat, Aug 15, 2026 at 09:59:54AM -0400, Patrick Klos wrote:
Don't tell me that the text based WHOIS service creates a greater "threat landscape" or "attack vector". Text based WHOIS has been around for decades - by now, I'm sure it's quite hardened!
On Sun, Aug 16, 2026 at 12:59:31AM +0100, Lavender-Jamie via ARIN-consult wrote:
What excessive attack surface is there to operating whois? Yes, it is an additional service, but whois, in some form, has been around since forever and I am most certain that after so many years, there are well hardened whois servers available.
The threat is in the use of the protocol. Port 43 Whois query/response transactions are susceptible to man-in-the-middle attacks due to the unauthenticated and unencrypted nature of the WHOIS protocol.
"Hardening" the Whois server does nothing to mitigate the risk of data interception or undetected tampering: there is no transport security in port 43 Whois. WHOIS-based services simply lack mechanisms for integrity and confidentiality.
The above means that entities using port 43 are at significant risk if they are making any kind of business decisions based on the WHOIS data retrieved via an insecure channel.
Kind regards,
Job
ps. ARIN discontinued unsafe protocols before https://www.arin.net/announcements/20250204/ _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/7APKQ2PO...
On Tue, Sep 1, 2026 at 4:09 AM Job Snijders via NANOG <nanog@lists.nanog.org> wrote:
The threat is in the use of the protocol. Port 43 Whois query/response transactions are susceptible to man-in-the-middle attacks due to the unauthenticated and unencrypted nature of the WHOIS protocol.
Hi Job, That threat you're talking about is to organizations which are not ARIN. It is no more ARIN's place to tell those folks how to secure their systems than it is ARIN's place to tell them how to run their networks. ARIN has provided RDAP. Folks using whois in a manner which is meaningfully at risk from in-flight data manipulation are free to follow that upgrade path. The greatest sin of IPv6 was failing to implement backward compatibility. Have we learned nothing from that _expense_? Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/
borg--- via NANOG wrote on 01/09/2026 08:39:
Uh, first off all. Its not a service that needs constant babysitting. You set up it once and forget, probably forever.
Second, its not 80s or 90s, compute is cheap.. very cheap. Are you saying that running such proxy is such a problem? I doubt it...
if it's a daemon running on the home server in your basement, you set it up once, then forget about it. If it's a service run by an organisation like ARIN, you cost it, code it and run it as a formally supported service. You then monitor it and restart it when it falls over. You fix the occasional bug, keep the code up to date, and you need to take it into account when the underlying data store changes in any way. That includes looking at any part of the information stack sideways, because the more ancient the code base, the more fragile it is. You then test it to make sure nothing breaks. You train people up on the lifecycle of the product and write documentation, both internal and external. You throw the codebase into CI, you run security audits on the code, and then you answer the security auditor's queries about it. Despite all that, it's still got some weird stuff going on inside it, and there's probably only a single person in the organisation who knows how it all works. Handling it consumes time at meetings, it consumes technical time and because it's public facing, everyone across the organisation - from the board to the helpdesk - needs to have some awareness of it. Then you multiply all that by something approximating 4 to handle the 4 different directory protocols which are exposed by ARIN, and it turns out that the costs to do this are not just non-zero, they're actually substantial. The costs here are the direct costs of the technical debt incurred in supporting legacy products and systems. These costs can't be magicked away by declaring all this to be silly, or by claiming that whois doesn't need much compute, or by stating that this is all unnecessary overhead and it would be much simpler to put in a small proxy (just a little one) to do the job instead. People running a service in their basement have the privilege of ignoring all this because if the service falls over, it doesn't matter. If you're an ARIN, proper support of externally facing protocols really does matter. Nick
Folks using whois in a manner which is meaningfully at risk from in-flight data manipulation are free to follow that upgrade path.
There is no way to use WHOIS that is NOT at risk of in-flight manipulation. That's the point. On Tue, Sep 1, 2026 at 10:30 AM William Herrin via NANOG < nanog@lists.nanog.org> wrote:
On Tue, Sep 1, 2026 at 4:09 AM Job Snijders via NANOG <nanog@lists.nanog.org> wrote:
The threat is in the use of the protocol. Port 43 Whois query/response transactions are susceptible to man-in-the-middle attacks due to the unauthenticated and unencrypted nature of the WHOIS protocol.
Hi Job,
That threat you're talking about is to organizations which are not ARIN. It is no more ARIN's place to tell those folks how to secure their systems than it is ARIN's place to tell them how to run their networks. ARIN has provided RDAP. Folks using whois in a manner which is meaningfully at risk from in-flight data manipulation are free to follow that upgrade path.
The greatest sin of IPv6 was failing to implement backward compatibility. Have we learned nothing from that _expense_?
Regards, Bill Herrin
-- For hire. https://bill.herrin.us/resume/ _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/NWNHTIHM...
On Tue, Sep 1, 2026 at 12:09 PM Tom Beecher via NANOG <nanog@lists.nanog.org> wrote:
There is no way to use WHOIS that is NOT at risk of in-flight manipulation.
Not exactly. You can whois query the same items several iterations over various periods of time from multiple network perspectives if you want. You can render the probability low enough that it is not a risk worth considering. Which is equal to a zero risk. The possibility of an in-flight manipulation does not matter for some consumers and applications. So not fundamentally part of the Whois server nor ARIN's attack surface. Mail operators are running email transport protocols over 25 which send messages in the clear and using Whois to find IP address contacts for issue reporting. Encrypting the Whois transport does not add security to the common use case, because the underlying protocol itself for email transmission is in the clear. Your security can never be greater than the weakest link in the chain, so the fact that the underlying SMTP transport is in the clear means that Whois in the clear has a zero risk component in that case. Even if the Whois transport is not encrypted: the transport does not authenticate that the data has not been tampered with at rest while on ARIN's servers nor after your client has received it before displaying in the terminal. And the risk can be near zero because most applications of Whois data are simply for finding a contact in order to report a problem, abuse, or begin an investigation. Only specific applications, such as verifying a contact have a real risk. It is also irrelevant to ARIN's attack surface, since this has always been an inherent well-known trait to the WHOIS protocol itself which affects only the consumer's security not the server operator's. And the consumer can mitigate it. There is nothing about the Whois protocol which prevents the server from creating a timestamped digital signature footer in the response, and it could be solved within the bounds of the existing protocol. I would say that RDAP ought to be first fully implemented with full parity regarding Whois and Whois-RWS query and output result selection/filterting features, and have wide support across major OSes first and the N years sunset dates should be set 2 years after that happens. The year or less sunset on those protocols is way too low. Rdap is not widely supported on the client yet, and the simplest common end user use case; WHOIS on 1 ip address to be read by a human does not benefit at all from the "upgrade" to RDAP. -- -J
participants (23)
-
Alexander Harrowell -
Andy Newton -
babydr DBA James W. Laferriere -
borg＠uu3.net -
Cat Okita -
David Conrad -
Dorn Hetzel -
Jay A -
Job Snijders -
John Curran -
John Levine -
John R. Levine
-
Lavender-Jamie -
Mark Kosters -
Matt Corallo -
Mike Lyon -
Nick Hilliard -
Randy Bush -
Rich Kulawiec -
Sam Thomas -
Shane Ronan -
Tom Beecher -
William Herrin