[dns-operations] _nicname._tcp

[Geoffrey Sisson]

jim at rfc1035.com (Jim Reid) wrote:

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

There's no standard for this.  There's a history of of ccTLDs using
whois.nic.TLD, but this cannot be applied uniformly across all TLDs as
in many cases nic.TLD will have already been delegated to a third party.

Note also that draft-sanz-whois-srv isn't about TLDs only, e.g.:

    _nicname._tcp.co.uk. SRV 0 0 43 whois.nic.uk.

    _nicname._tcp.co.za. SRV 0 0 43 whois.coza.net.za.

    _nicname._tcp.uk.net. SRV 0 0 43 whois.centralnic.com.

    _nicname._tcp.nic.uk. SRV 0 0 0 .

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

I don't see why SRV RRs for EPP wouldn't work, but I don't think it makes
sense to conflate the problem space of a service used by millions with
the problem space of a service used by a few thousand.

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

Not bad for an -01 draft that expired six years ago.

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

What does this have to do with draft-sanz-whois-srv?

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

Wouldn't draft-sanz-whois-srv serve as a basis for this?

Geoff