Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The ip_del_list file has old information #130

Open
PenelopeFudd opened this issue Jan 25, 2023 · 3 comments
Open

The ip_del_list file has old information #130

PenelopeFudd opened this issue Jan 25, 2023 · 3 comments

Comments

@PenelopeFudd
Copy link

Hello!

When I do whois 154.61.y.z (with my own ip filling in y and z), whois uses ip_del_list to pick a whois server to send the request to.
Alas, that address is in England, but the chosen whois server is Afrinic.

154.0.0.0/8 may have been broken up like netblocks 128.0.0.0/2, 192.0.0.0/8, 196.0.0.0/8 and 198.0.0.0/8, have been.

At any rate, the Afrinic server appears to be struggling with the load it's getting; it responds with a "temporary failure" error 95% of the time (estimated).

You might want to do one or more of these:

  • Take a look at 154.0.0.0/8 and see if it should be deleted/split in the ip_del_list file
  • Retest some or all of the entries in ip_del_list
  • Add code that retries requests at whois.arin.net if the first server can't help (i.e. gives an error or doesn't provide a redirection or an answer)

I've added ^154\. whois.arin.net to my /etc/whois.conf, but this likely affects more than just me.

Note: I'm using whois 5.5.13 on Fedora 35, but ip_del_list is the same as here.

Thanks!

@rfc1036
Copy link
Owner

rfc1036 commented Feb 10, 2023

Of course it is out of date: after the implementation of inter-RIR transfers the IP space is now fragmented and the relevant whois servers for a network cannot be reasonably decided by a small static list.

I am not sure of how this could be solved: listing ARIN for 154/8 for all I know could be as wrong as listing AFRINIC.

Maybe at this point -A should be the default, but I am not sure that I want to do that without first implementing some caching system.

It was also seriously stupid for AFRINIC to implement themselves lookups to other RIRs, because it makes the output of their server impossible to predict and causes excessive load on it.

@PenelopeFudd
Copy link
Author

I wouldn't phrase it as strongly as that, but yes, it was an expensive decision to be a recursive resolver: bandwidth in Africa isn't cheap.

WHOIS is responsible for just about the same amount of data as DNS (within a couple orders of magnitude), and as you mentioned, the fragmentation of the IP space makes lookups just as complicated.

The only thing preventing the wholesale transfer of WHOIS data into the DNS system is (I think) the size of the TXT records it would have to support. Perhaps if it just held pointers to the relevant WHOIS servers, that might work.

Alas, I suspect that any changes would need a committee and an RFC, so I'm pretty sure we're going to have the existing WHOIS protocol for years to come.

Cheers!

@z-image
Copy link

z-image commented Oct 30, 2023

so I'm pretty sure we're going to have the existing WHOIS protocol for years to come

Sorry about this maybe unrelated comment, but according to https://www.icann.org/resources/pages/global-amendment-2023-en 28 January 2025 has been decided as a sunset data for the WHOIS protocol.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants