Draft on using SRV records to locate whois servers

On Wed, 1 May 2002, Brad Knowles wrote:

> At 3:18 PM +0100 2002/05/01, James Raftery wrote:
>
> >  Without SRV records, if I wish to use whois to talk to a server named
> >  whois.isp.net I should lookup the A record of whois.isp.net and
> >  contact that host.

Yes.

> >  With SRV I should lookup the SRV of _whois._tcp.whois.isp.net and
> >  contact the host specified by the A record owned by the SRV target.

No.

> 	Not correct.  Think about mail and the MX record.  You don't want
> to send mail to user at a.mx.aol.com, you want to send mail to
> user at aol.com.  So, you look up the MX records for aol.com.

Yes and no.  The main difference (as I understand it and how I feel it
should work) is that a search for an MX is an one level search; you try to
find MX records for the domain 'aol.com', not the parent ('.com') or any
children ('www.aol.com').

Most of this is similar to the SRV-specific information in the draft
below, although the idea (using SRV records for whois) has been
independently suggested by a number of people.

http://www.ietf.org/internet-drafts/draft-hall-ldap-whois-01.txt

A search for a whois server for a given record should start at the level
that you want to find, and work down to the root until a match _that makes
sense_ is found.

To find a whois server for the domain, foobar.example.com, you would
attempt to find SRV records for the following (in order):

	_nicname._tcp.foobar.example.com
	_nicname._tcp.example.com
	_nicname._tcp.com

( Note qualification by Patrik in dns-wg session, the protocol name
  recorded by IANA is 'nicname', not 'whois'. )

When you find a match from one of the above that makes sense, you then
lookup the address record for the whois server, and contact it as per
normal semantics, eg:

	_nicname._tcp.foobar.example.com	(no match)
	_nicname._tcp.example.com IN SRV 0 0 43	whois.example.com

	whois.example.com IN A 192.168.192.168

	whois -h whois.example.com foobar.example.com

In the case that example.com's whois service is, shall we say, less than
optimum, then you could also look for a record:

	_nicname._tcp.com

(although the only information that you'd expect to get there is
 registration details for 'example.com', not 'foobar.example.com')

You could also apply this to the reverse, eg:

	_nicname._tcp.3.2.1.193.in-addr.arpa
	_nicname._tcp.2.1.193.in-addr.arpa
	_nicname._tcp.1.193.in-addr.arpa
	_nicname._tcp.193.in-addr.arpa IN SRV 0 0 43 whois.ripe.net

( or at any point in the chain )

-- 
                             Bruce Campbell                            RIPE
                   Systems/Network Engineer                             NCC
                 www.ripe.net - PGP562C8B1B                      Operations