Draft on using SRV records to locate whois servers

[Jim Reid wrote:]

> Below is a draft of the document Gerhard, Linus and Marcos have been
> working on. It's been circulated to the list for discussion. Marcos

thank you folks for bringing this up. I'm sure this is a good idea and
will fill a long standing gap.

Find some comments, questions and suggestions below.

> 0. Definitions
> 
> The key words "MUST", "SHOULD", and "RECOMMENDED" in this document are
> to be interpreted as described in [RFC 2119]. Other terms used in this
> document are defined in the DNS specification, [RFC 1034].

Here's a rough version of a longer problem statement:

Whois servers are used to locate administrative, technical and security
contacts for given IP addresses, domain names or other network objects
associated with an organisation, e.g. AS numbers. While usually Top Level
Domain (TLD) registries run a whois server, there is no generic name for it
and it may not even be obvious that the TLD registry's whois server is the
right one to ask, ince there are TLDs where registration takes place under
specialised second level domains (e.g. UK, AT).
The Regional Internet Registries (RIR) [reference, anyone?] also provide whois
service as part of their coordination task. Again, there is no easy uniform way
to find out which RIR is responsible for a particular address or address range.
All this can be solved by central "master" or "meta" whois servers, which keep
track of all new and changing servers and refer to the DNS registries' or
RIRs' whois servers (there are also omniscient clients, like "SuperWhois").

{XXX Bill Manning also had a DNS based AS-number directory}

This document proposes an approach which eliminates the need for a central
master repository and works down to lower levels in the hierarchy.

It is the intent to locate a whois server as close to the target (in terms
of hierarchy) as possible, while preserving the opportunity to locate
higher level servers for escalation purposes.

> 1. Format
> 
> The general format of DNS SRV records is documented in RFC 2782:
> 
>    _Service._Proto.Name TTL Class SRV Priority Weight Port Target
> 
> 
> Therefore the simplest format of an SRV record to locate a whois server
> is:
> 
>    _whois._tcp     IN   SRV   0 0 43 whois.nic.example.
> 
> 
> [RFC 1700] foresees the possibility of a whois service over UDP. Common
> use is TCP but nothing would prevent from analogously setting the _Proto
> field to the value _udp.

RFC 1700 has been superseded by RFC 3232, so I'd suggest to cite either that
or the IANA URL, as you do later [IANA-NUM]. 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.

> The symbolic name of the service is defined as "whois" (case
> insensitive), which is the most familiar name, though it is also called
> "nicname" in [RFC 954].

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.

> Priority and Weight have a value of 0 in the example above just for
> readability purposes.
> 
> It is RECOMMENDED to use the port number 43, as specified in [RFC 1700]
> or [IANA-NUM].

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.

> If there is a whois server running for a specific domain, such an SRV
> record can be defined. When used for looking up information about a
> domain, whois clients can do DNS lookups for SRV records, and can use
> the retrieved target information to point their whois queries
> accordingly. This kind of client is called "SRV-cognizant" or
> "SRV-aware" whois client.

So, does this mean the SRV RR has to be owned by the domain you are interested
in or by its parent? See below for a suggestion of a hierarchical approach.

> It is imaginable that this functionality could be extended for other
> purposes (like inetnum or handle lookup), but this remains open for a
> future discussion.

See below for a suggestion for inetnum lookup.

> As defined in [RFC 2782] the client SHOULD abort if it finds a record
> defined like:
> 
>    _whois._tcp     IN   SRV   0 0 0 .

While this copies the definition from RFC 2782, I do not think the client is
expected to abort (i.e. terminate) should this condition be met. Instead,
only the SRV processing is aborted. IIRC this case was introduced to be able
to explicitly state the absence of a particular service (or all services via
a wildcard) as opposed to just having no SRV RR.

> The given SRV record is valid for the zone where it appears. This means
> that it does not provide any information on subdomains or zones below;

This may result in a contradiction: If it's valid for the zone, it is
also valid for subdomains of the zone apex. And, it costs additional
work to find out which zone one actually resides in. And does this mean
_whois._tcp.DE leads to a whois server which has no knwledge about
Uni-Bielefeld.DE (subdomain and delegated zone in this case)?

> it is a onelevel information. Search for subdomains MUST behave like
> conventional DNS search algorithms.

"conventional" algorithms depend on local search lists, while here you want
searching along the domain name subject to the later whois query.
In addition, conventional DNS search should not extend beyond domain names
within local control (from the queriers point of view) [RFC 1535], while
that is what you explicitly want here.
However, it still could be abused (see security considerations).

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.

  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.

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

  The SRV RRs then could point to a (group of) whois server inside the
  organisation using the domain name ("weird.example"), to the registry,
  a registrar's whois server or a web hosters whois server.

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.

This scheme could be extended to cover inetnum lookups (only the IPv4 case is
outlined here):

  For locating contacts for IPv4 addresses clients should ask in the
  IN-ADDR.ARPA DNS subtree, starting at the domain name representing the
  full address, e.g.:

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

Opinions?

> There is no definition of which target should be used as a default for
> an SRV-cognizant whois client if no whois server could be discovered by
> means of SRV records. The use of a default whois server is local
> dependent.

In the absence of an appropriate SRV entry, the client MAY try
"whois".<domain> (see RFC 2219);
However, security implications should be payed attention to.

> 5. Security Considerations
> 
> The same security considerations as defined in [RFC 2782] should apply.
> There is no discussion on security, data protection and privacy relating
> to the contents of the whois server in this paper. This is the
> responsibility of the whois server operator and has nothing to do with a
> mechanism that describes how whois servers can be reached.

Use of the DNS search algorithm can lead to 2 problems:
1) By using DNS query logging an organisation could find out who is issuing
   whois queries about them even without operating a whois server themselves

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.

-Peter