[dns-operations] _nicname._tcp

[Jim Reid]

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  
>> uwhois.com.
>
> 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?
>
>> web
>
> 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.
>
> Irrelevant.

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  
breath...