About RIPE | Contact  | Search | Sitemap    
Homepage RIPE  
RIPE Community Mail Archives
search  
     
RIPE Navigation Ends
About RIPE Maillists
Maillists Archive
Global Lists
Non Active Lists
RIPE NCC Navigation Ends
Next Section
<<< Chronological >>> Author Index    Subject Index <<< Threads >>>

Draft on using SRV records to locate whois servers

  • From: Jim Reid < >
  • Date: Wed, 24 Apr 2002 06:26:22 -0700

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
will be giving a presentation on this at the WG meeting next week.
Please submit any comments to the authors or, better still, to the
mailing list.

draft-whois-srv-01.txt


Linus Corin
Marcos Sanz
Gerhard Winkler

                                                           24 April 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

There is no common whois database where all domain objects are stored.
Several TLDs run their own databases, which can be reached under
different network locations and, for the user, there is no easy way to
find the right whois server to answer their query by means of a simple
whois client.

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

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:

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

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

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


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 inetnum 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:

   _whois._tcp     IN   SRV   0 0 0 .


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;
it is a onelevel information. Search for subdomains MUST behave like
conventional DNS search algorithms.


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.


6. References

[RFC 954]     NICNAME/WHOIS
[RFC 1034]    Domain names - concepts and facilities
[RFC 1700]    Assigned Numbers
[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@localhost

Marcos Sanz
DENIC eG
Wiesenhuettenplatz 26
D-60329 Frankfurt/Main, Germany
sanz@localhost

Gerhard Winkler
Vienna University Computer Center / NIC.AT
Universitaetsstrasse 7
A-1100 Vienna, Austria
gerhard.winkler@localhost




  • Post To The List:
<<< Chronological >>> Author    Subject <<< Threads >>>
 

Next Section
     About RIPE | Site Map | LIR Portal | About the RIPE NCC | Contact | © RIPE Community. All rights reserved.
RIPE.NET Homepage LIR Portal RIPE Community