jim at rfc1035.com
Mon Jul 26 13:52:47 UTC 2010
On 26 Jul 2010, at 10:54, Jay Daley wrote:
>>> And may I take opportunity to remind people of "_nicname._tcp SRV"
>>> to locate WHOIS servers.
>> Why? There are plenty of other ad-hoc ways of locating whois
>> servers already. Adding another seems pointless. Most registries
>> provide a link to their whois service on their home page. IANA
>> publish the names of the whois servers for those TLDs who provide
>> this service. Then there are generic whois lookup services like
> Because this mechanism gets the location data direct from the
> horse's mouth.
Unlike a DNS lookup of whois.registry.TLD or whois.nic.TLD or...
>> A standardised naming convention for locating whois servers would
>> be of marginal use at best. [And why only whois servers? Why not
>> provide SRV records for the TLD's DNS,
> DNS? Eh?
> If anyone wants to then they can with an A record.
Just as they already do with whois... Even though it would be lovely
if web browsers looked for SRV records.
>> and EPP servers too?]
> because there is no public access to EPP servers so no need for a
> public advert.
You miss the point Jay. The question I was asking was why single out
whois as a special case that's worthy of a funky name and SRV record?
Those other registry services are just as deserving of an SRV record,
if not more so. The load balancing and priority features of SRV
records could be particularly useful to EPP clients. And I'm fairly
sure registries put names for their EPP servers in the DNS, even if
they do keep the boxes away from general public access. So adding an
SRV record will be no big deal when the EPP box already has a CNAME or
A an AAAA.
>> Besides, as everyone knows, criminals *always* put their contact
>> details in whois because ICANN makes them.
Not really. IMO whois is mostly useless and long overdue for a mercy
killing. So rather than help to prolong its existence and encourage
its use, registries would be better served developing a method of
providing registrant data that met local needs and was compatible with
prevailing privacy and data protection law. We both know from first
hand that whois does not do that Jay. OTOH, I understand perhaps
better than anyone else on this list why the path of least resistance
is to keep well away from the toxic swamp that is whois reform.
>> The long-dead draft-sanz-whois-srv-01.txt didn't get very far the
>> last time it was discussed. So what's changed to make it more
>> likely to gain acceptance now?
> You may not have noticed but it has pretty good community acceptance
> already. Try a few of your favourite TLDs to see.
Well I tried them all because every TLD is a favourite. :-) Only 29
out of 288 TLDs have these _nicname._tcp.$TLD SRV records. 248 TLDs
return NXDOMAIN. This doesn't quite meet a reasonable definition of
"pretty good community acceptance". Your mileage may vary.
FWIW, 154 TLDs don't have entries at $TLD.whois-servers.net. A bunch
of the ones that do exist there are iffy. Over 20 are CNAMEs for the
RIPE NCC whois server.
So to summarise, there are quite a few ad-hoc schemes for finding
whois servers. None appear to dominate. [Though I'll bet on google
being the favourite.] They may well have incorrect or conflicting
information. In short, it's a mess. I doubt anyone has the appetite or
energy to fix it. Unless IETF or some registry club like CENTR come up
with a public standard that can be assimilated into a universally
accepted registry BCP or something like that. I wouldn't hold my
More information about the dns-operations