Draft on using SRV records to locate whois servers

At 3:11 PM +0200 2002/04/28, Peter Koch wrote:

>                                                Anyway, the whois protocol
>  is not defined for UDP transport regardless of what "assigned numbers"
>  says about port number assignment. The document should clearly say that
>  it deals with the TCP case only.

	Agreed.  We should only talk about TCP and not mention UDP.

>  So, did one want to allow both? I'd stick with "whois", unless there is
>  demand to not only select the service based on the on-the-wire protocol
>  but also based on the data format (e.g. "ripe-whois" vs. "generic-whois").
>  However, I doubt that this granularity would ease deployment.

	We could mention both "whois" and "nicname", with the observation 
that the latter is an older, deprecated alias, and SHOULD NOT be used.

>  The document mainly talks about client behaviour, so this recommendation
>  regarding the server's port number seems a bit out of focus to me.
>  And, it's not needed for interoperability since one purpose of SRV RRs is
>  giving an administrator the opportunity of using non default ports.

	I think we can mention the standard practice of running whois on 
port 43, but I definitely agree that one of the best things about SRV 
records is that they allow us to move things to other ports.

>  I'd think the search is the key feature in locating the whois server and
>  an algorithm should be described, e.g.
>
>    A whois query for "www.deep.weird.example" will lead to the following
>    DNS queries for SRV RRs:
>
>    _whois._tcp.www.deep.weird.example
>        _whois._tcp.deep.weird.example
>             _whois._tcp.weird.example
>                   _whois._tcp.example
>
>    Always ask for the complete name first, including the leaf element, then
>    walk up the DNS tree until either a SRV RRSet is found or the TLD is
>    reached.

	Agreed.  In the absence of a searchlist, the standard recursive 
search algorithm should be applied.

>    Clients MAY continue the search after they've found a match. However, to
>    avoid unnecessary load on the DNS root servers, a client MUST NOT ask
>    for a whois server for the root domain, i.e. it MUST NOT issue queries
>    for _whois._tcp.

	Now this I don't understand.  We can query for NS records all the 
way up to the root zone, and there can be a whois server for the root 
zone -- it may only define delegation data for the TLDs, but this is 
still valid information).  I don't understand why we should never 
query for this data, given that it should be the very last query in 
the sequence (and first match wins).

>    The "stop indicator" (i.e. single member RRSet "SRV 0 0 0 .") does not
>    stop the search but makes the algorithm skip this node.

	Good.

>  Question remains what to ask the whois server. If a match is found for
>  _whois._tcp.example, should the server be asked for the full name
>  www.deep.weird.example or just the smallest suffix needed for differentiation
>  ("weird.example")? Are all whois servers capable of "closest match"?
>  And how to deal with the fact that whois servers have no standardized way to
>  indicate they do not know a key queried for.

	I believe that we should use a similar recursive algorithm for 
what is looked up in the whois server, just as we do for finding out 
which whois server is appropriate.  So, we would first look up 
www.deep.weird.example, and if that's not defined we would then look 
up deep.weird.example, and then weird.example, etc....

>    A whois query for 192.168.1.1 leads to DNS SRV queries for (in that order):
>
>     _whois._tcp.1.1.168.192.IN-ADDR.ARPA
>       _whois._tcp.1.168.192.IN-ADDR.ARPA
>         _whois._tcp.168.192.IN-ADDR.ARPA
>             _whois._tcp.192.IN-ADDR.ARPA
>                 _whois._tcp.IN-ADDR.ARPA (*)
>                         _whois._tcp.ARPA (*)
>
>    The queries marked with (*) could probably be omitted, since they are not
>    supposed to lead to an answer (there's no central inetnum whois server).

	The last two queries are sub-optimal, yes.  We could (and should) 
recommend that people avoid making these queries in their clients, 
for obvious performance reasons.  However, I would not rule them out 
entirely -- what if we're looking up information that is only 
contained within the top-level IPv4 or IPv6 registry, and therefore 
we really would want to query _whois._tcp.IN-ADDR.ARPA or even 
_whois._tcp.ARPA.

>  2) An (malicious) organisation could use SRV RRs to misdirect whois requests.
>     For example, a spamhaus using "spamhaus.example" could direct whois
>     queries to their own whois server containing no or false information or
>     even worse, innocent targets. For this reason, whois clients should be
>     able to start the search above the leaf or particular inner nodes upon
>     request.

	I would go so far as to say that whois clients should query for 
both the level of the query as well as the level of the parent of the 
query, by default.  We can see this behaviour on the horizon already, 
and we should be prepared for it now.

-- 
Brad Knowles, <brad.knowles at skynet.be>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
     -Benjamin Franklin, Historical Review of Pennsylvania.