Anyone else noticing that the .pro TLD is failing for some things, and their WHOIS registry appears to be unavailable?
I appear to be able to resolve, but whois times out, and we're getting reports that mail isn't going through for some folks with this TLD.
Anyone else noticing that the .pro TLD is failing for some things, and their WHOIS registry appears to be unavailable?
The delegation from the root to PRO, and the PRO name servers themselves, seem to be working.
I appear to be able to resolve, but whois times out, and we're getting reports that mail isn't going through for some folks with this TLD.
The address records for whois.dotproregistry.net are missing.
Doug
Well, it depends how you find the .pro whois servers, and I am pleased
that my recent changes to FreeBSD whois handle this case OK.
If you use pro.whois-servers.net aka whois.registrypro.pro the connection
times out. (It is sad that the often excellent whois-servers.net doesn't
work as well as it used to.)
If you use whois.nic.pro then it works. (This is the standard name
required for new gTLDs.)
If you follow the referral from whois.iana.org to whois.afilias.net then
it works.
More on whois at http://fanf.livejournal.com/140505.html
Tony.
Joseph,
Thanks for the update. However the current state of things is not good ... My Ubuntu host tries to use whois.dotproregistry.net, which has no address records. FreeBSD by default uses pro.whois-servers.net, which resolves to whois.registrypro.pro (which has an A record), but never returns with any data (arguably worse than failing immediately with an obvious error).
If it were me, I would have done the following:
1. Reach out to the OS vendors and the folks at whois-servers.net with information that the proper host name for your whois service is changing. Include a drop-dead date of 3 years in the future for the old names to stop working.
2. Place a CNAME at the two (or more?) old host names so that the service will continue to work in the meantime.
The CNAME costs you nothing, and while I agree that it should be able to be removed at some point in the future, having things not work at all in the short term is not the right approach.
It's also not realistic to expect folks to be able to chase this down on their own ... anyone familiar with using whois on the command line has most assuredly grown accustomed to the convenience of having it "just work," as it has for the last decade or so. While people certainly *can* go back to the "good old days" of having to hunt down each registry's whois server individually, it's hard to think of that as the best approach.
Is there some reason that the above can't be/hasn't been done that I'm missing?
Doug
Additionally 'whois' is free form text. Whois doesn't include a
AI to workout what this free form text means so, no, there isn't a
actual referral for a whois application to use.
Additionally we should be publishing where the whois server for the
tld is in the DNS. whois applications could be looking for this
then falling back to other methods.
e.g.
_whois._tcp.pro. srv 0 100 43 whois.afilias.net.
If we want machines to follow referrals we have to provide them in
appropriate forms.
Mark
Additionally 'whois' is free form text. Whois doesn't include a
AI to workout what this free form text means so, no, there isn't a
actual referral for a whois application to use.
I'm not affiliated, but there are a couple of companies that normalize
whois data. It's a whackamole game, but it sucks less than trying to
do it yourself.
Additionally we should be publishing where the whois server for the
tld is in the DNS. whois applications could be looking for this
then falling back to other methods.e.g.
_whois._tcp.pro. srv 0 100 43 whois.afilias.net.
If we want machines to follow referrals we have to provide them in
appropriate forms.
That's a great idea.
Royce
Worst comes to worst there's a python based whois client called pwhois that lets you dump whois data into json
--srs
Brilliant, wish I'd thought of it 
Doug
Additionally 'whois' is free form text. Whois doesn't include a
AI to workout what this free form text means so, no, there isn't a
actual referral for a whois application to use.
Yes, the whois data format is bullshit, but there are only a few simple
referral patterns in use, so in practice following referrals works OK.
Additionally we should be publishing where the whois server for the
tld is in the DNS.
_whois._tcp.pro. srv 0 100 43 whois.afilias.net.
That would be nice, but in practice the requirement is a whois.nic.TLD
host rather than a SRV record. And we don't really need yet another way
to find whois servers - we already have more than enough.
Tony.
_whois._tcp.pro. srv 0 100 43 whois.afilias.net.
A swell idea, but unfortunately the idea of putting SRV records in
gTLD zones makes heads at ICANN explode. For RDAP there's a registry
at IANA but it's not populated yet and it's not obvious that registries
will be any more diligent about updating it than they are for the WHOIS
entries in the TLD database.
If we want machines to follow referrals we have to provide them in
appropriate forms.
<domain.whois-servers.net is OK but not updated very often.
I've set up <domain>.ws.sp.am (that's ws for Whois Server) which is
updated every day from a variety of sources so it's pretty accurate.
It's had the right server for pro.ws.sp.am all along.
R's,
John
Hey, that's fantastic!
Feature request: could you provide a human- and machine-readable one-stop
extract at the top-level page (ws.sp.am) ?
Royce
I've set up <domain>.ws.sp.am (that's ws for Whois Server) which is
updated every day from a variety of sources so it's pretty accurate.
It's had the right server for pro.ws.sp.am all along.
Hey, that's fantastic!
Feature request: could you provide a human- and machine-readable one-stop
extract at the top-level page (ws.sp.am) ?
I can make a web page, but not sure what you mean by one-stop extract. If you mean a proxy that will do the whois lookups, no, because it'd get abused and I'd get rate limited.
R's,
John
Definitely not a proxy request - I know exactly what that would mean.
The goal would be to provide a unified list of the servers for each
TLD, to help people who cannot change their whois client for
administrative/political/inertia reasons, but have control over their
whois.conf, a la:
https://superuser.com/questions/758647/how-to-whois-new-tlds
So in an ideal world:
- a top-level landing page that would explain briefly what it's for, and
- a link from that top-level page to the whole list, in regex-aware,
whois.conf-compatible format
Royce
- a link from that top-level page to the whole list, in regex-aware,
whois.conf-compatible format
What uses whois.conf? Not the whois on my FreeBSD or Mac.
Or you can just use this shell script:
#!/bin/bash
WHOISHOST=${1##*.}.ws.sp.am
exec whois -h $WHOISHOST $*
R's,
John
Hai!
whois.conf-compatible format
What uses whois.conf? Not the whois on my FreeBSD or Mac.
Or you can just use this shell script:
#!/bin/bash
WHOISHOST=${1##*.}.ws.sp.am
exec whois -h $WHOISHOST $*
I just a slightly different one but still my fav one... jwhois
Has a whois.conf style list.
Bye,
Raymond.
It would be extra super helpful if every entry were a wildcard, so you
could look up (say) example.com.ws.sp.am and get a CNAME for the right
whois server. The reason for this is that the relevant whois server is not
always keyed off just the TLD, and sometimes the TLD doesn't provide a
referral. A particular case I know of is ac.uk vs. uk. You could have
*.uk.ws.sp.am. CNAME whois.nic.uk.
*.ac.uk.ws.sp.am. CNAME whois.ja.net.
Then I could look up cambridge.ac.uk.ws.sp.am and
cambridge.net.uk.ws.sp.am and get the right pointer in each case with a
single DNS lookup.
Tony.