Re: Draft on using SRV records to locate whois servers

[James Raftery <]

Hi,

I have two points to make on the draft. They relate to the SRV owner
name as envisaged by this draft and to the requirements for SRV
targets.


Firstly, this draft appears to use different semantics for the domain
name of an SRV RR than those in RFC2782. My reading of 2782 is that the
``name'' portion of the RR owner (i.e. the name component of
_service._protocol.name) is analogous to the server name the client
wants to contact.

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.

If I were the operator of a whois server whose published name was
``whois.isp.net'' I might have the following in the isp.net zone to
support that second scenario:

$ORIGIN isp.net.
_whois._tcp.whois	IN	SRV	10 0 43 dbserver.isp.net.
			IN	SRV	20 0 43 dbbackup.isp.net.
dbserver		IN	A	10.10.10.1
dbbackup		IN	A	10.20.20.1

SRVs are for adding indirection (amongst other features) to the
names people type into browser address bars, MUA configurations
and -h options to their whois clients.

This draft changes the semantic meaning of the SRV ``name'' when used
in a whois context to be ``a whois query string, or a domain above it
in the DNS tree''.

2782 says if you want to contact host foo for service X over protocol Y,
then lookup "_X._Y.foo IN SRV". This draft says if you want to send a
query ABOUT foo to a whois server, lookup "_whois._tcp.foo IN SRV". The
semantic meaning of ``foo'' has changed and that change is not explicitly
stated. I would like it to be.


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

_whois._tcp.customer.com.	IN	SRV	10 0 43 dbserver.isp.net.
				IN	SRV	20 0 43 dbbackup.isp.net.


As an aside, when this was first mooted some years ago I wrote a
SRV-aware whois client which implemented the mechanism is this draft.
Recently I decided it made much more sense to have a SRV whois client
that used SRVs in the way I think 2782 intended. My client does SRV
processing on the ``server name''. Since this draft appeared I
integrated both modes of operation. The support for this draft is
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

Written in perl, requires Net::DNS. More testing would be great as would
comments.

Example:

 whois-srv -h whois.denic.de www.foo.de

will do
- SRV query for _whois._tcp.whois.denic.de and contact the target
- If no SRV, do A query for whois.denic.de -- i.e. act as a normal client

 whois-srv -W -h whois.denic.de www.foo.de

will do
- SRV query for _whois._tcp.www.foo.de and contact the target
- If no SRV, contact target of the _whois._tcp.foo.de SRV
- If no SRV, contact target of the _whois._tcp.de SRV
- If no SRV, do A query for whois.denic.de -- i.e. act as a normal client


Regards,
james