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(a)telia.net
Marcos Sanz
DENIC eG
Wiesenhuettenplatz 26
D-60329 Frankfurt/Main, Germany
sanz(a)denic.de
Gerhard Winkler
Vienna University Computer Center / NIC.AT
Universitaetsstrasse 7
A-1100 Vienna, Austria
gerhard.winkler(a)univie.ac.at
James,
thanks for your feedback.
> 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.
>
> 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.
Let's say that isp.net (gosh, they really exist) do not know about RFC2219
and run their whois service under the alias foobar.isp.net. How should an
SRV-cognizant whois client ever come to the idea of looking up an SRV of
the form "_whois._tcp.blafasel.isp.net"? This is precisely the problem that
we want to get rid of and with that interpretation of RFC2782 we are
reintroducing it again.
> Secondly, I feel a reminder that the target of an SRV must have an A RR
> is in order. Taking my isp.net example, above, again. If I controlled
> customer.com and wanted to use the mechanism in this draft to publish
> the fact that customer.com is in isp.net's whois server I cannot use:
>
> _whois._tcp.customer.com. IN SRV 10 0 43 whois.isp.net.
>
> as ``whois.isp.net'' does not have an A RR. I must ``undo'' the
> name indirection desired by isp.net and instead publish the following
> RRs (and keep them up to date):
Right, the reminder about the A RR is in order. On the other hand, this way
of "undoing the indirection" and trying to keep it up to date is not very
practical. Does somebody have any ideas on that?
> referred to as ``wacky mode'' - no offence is intended :-) If anybody
> wants to play with it, it's at
>
> http://romana.now.ie/software/srv-whois
I really must be wacky, I cannot find it! :-P
Regards,
Marcos
