draft-whois-srv-02.txt

Hi,

we have now changed our first version and have incorporated a lot of
comments which were made during/after the last RIPE meeting.
Please feel free to discuss and send any comments.
We will try to move this paper forward.

regards,
Gerhard






draft-whois-srv-02.txt


Linus Corin
Marcos Sanz
Gerhard Winkler

                                                           1 July 2002

            Using DNS SRV records to locate whois servers


Status of this Memo

This document is a draft on the usage of the DNS SRV RR for the location
of whois servers.


Abstract

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, since there are TLDs where registration takes place under 
specialised second level domains (e.g. UK, AT).
The Regional Internet Registries (RIR) also provide whois service as part
of their coordination task.

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.

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.

This situation can be improved by using DNS SRV records and
SRV-cognizant whois clients.

This document deals with domain information only and it describes how
DNS SRV records should be used but it does not define any search strategies
(this will be discussed in a additional document).


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


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:

   _nicname._tcp     IN   SRV   0 0 43 whois.nic.example.


[IANA-NUM] 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.
Nevertheless this document deals with the TCP case only.

The symbolic name of the service is defined as "nicname" (case
insensitive), because it is defined in [RFC 954] in this way; though the most
familiar name is "whois".

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 [IANA-NUM].
SRV-cognizant whois clients SHOULD interoperate with traditional
whois servers which are in place right now.


2. Usage

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.

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


3. Restrictions

The service record functionality is meant as an extension to the
existing whois service and not as a new service.

In the absence of a whois protocol whose specification calls for the use
of other weighting information, the field Weight in the SRV record keeps
the standard meaning specified in [RFC 2782].

As defined in [RFC 2782] the client SHOULD abort if it finds a record
defined like:

   _nicname._tcp     IN   SRV   0 0 0 .


This means the SRV processing should be aborted at that level. But
nothing avoids the client to search for other SRV records above or under
that level. This behavior should be scope of search strategies.

The given SRV record does not provide any information about the
existance/absence of a service with the same name on subdomains or zones
below or above.
The search behavior of the client must be defined as it should be independant
from conventional DNS search algorithms defined by searchlists.

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


4. Authority

There is no authority which defines who should run a whois server,
though it is usual that the TLD registry runs a whois service for the
zone where it is authoritative.

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.


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.

A client developer must be aware that DNS search algorithms can lead to
this problem: By using DNS query logging an organisation could find out
who is issuing whois queries about them even without operating a whois
server themselves.


6. References

[RFC 954]     NICNAME/WHOIS
[RFC 1034]    Domain names - concepts and facilities
[RFC 2119]    Key words for use in RFCs to Indicate Requirement Levels
[RFC 2782]    A DNS RR for specifying the location of services (DNS SRV)
[IANA-NUM]    www.iana.org: Directory of General Assigned Numbers


7. Authors' Addresses

Linus Corin
Telia International Carrier
4th Floor, 330 High Holborn 
WC1V 7QY 
London, United Kingdom
linus at telia.net

Marcos Sanz
DENIC eG
Wiesenhuettenplatz 26
D-60329 Frankfurt/Main, Germany
sanz at denic.de

Gerhard Winkler
Vienna University Computer Center / NIC.AT
Universitaetsstrasse 7
A-1100 Vienna, Austria
gerhard.winkler at univie.ac.at




-- 
Gerhard Winkler                    |  E-Mail: gerhard.winkler at univie.ac.at
Vienna University Computer Center  |
Universitaetsstrasse 7             |  Tel: +43 1 4277 14035
A-1010 Vienna, Austria             |  Fax: +43 1 4277 9140