Draft on using SRV records to locate whois servers

Thanks for your feedback, Peter. Find comments below.

On 28.04.2002 15:11 Peter Koch <pk at TechFak.Uni-Bielefeld.DE> wrote:

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

Nice ellaboration! We will incorporate it (maybe partially) in the next
version.

> The Regional Internet Registries (RIR) [reference, anyone?] also provide
whois

We already searched for references on that, but did not found any.

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

We explicitly left out such kind of remarks, since we wanted to limit the
draft to locating Whois servers for domain lookups. We are already
collecting ideas for an extension draft about recommended behaviour of
SRV-cognizant whois clients and remarks are very welcome.

> > 1. Format
[...]
> > [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

Overseen that, thanks. We will fix it for the next version.

> The document should clearly say that it deals with the
> TCP case only.

We thought we should just leave it open. Any other opinions on that?

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

We stick with "whois", as well.

One could even think of selecting the service based on the type of data to
be queried ("contact-whois", "domain-whois", ?) as Gerhard once observed,
but as you say, it is a compromise between hype features and ease of
deployment.

> > 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 you want client-server interoperability for the "thing" we call
"protocol whois" nowadays, you SHOULD set the port to 43. Any other value
would be correctly handled by SRV-cognizant clients, but those servers
would not be reachable by conventional clients.

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

Actually, there might be SRV RRs at several levels, and the loose
formulation tries on purpose not to address the issue at that point.

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

I would even add: the SRV processing should be aborted _at that level_.
Nothing avoids for the client to search for SRV above (or under) that
level. But we thought such refinements were out of scope at that moment and
were an issue for another draft, as already mentioned.

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

The formulation is indeed missleading. What about:
"The SRV record does not provide any information about the
existence/absence of a service with the same name on subdomains or zones
below".

> > 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 think this is a wording problem, as well. I will leave it to Gerhard,
since he authored that line.

> I'd think the search is the key feature in locating the whois server and
> an algorithm should be described, e.g.

That is a possible procedure. We take note.

> 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")?

Not asking for the full name could result in delivering an answer for a
question that was not asked.

> Are all whois servers capable of "closest match"?

No

> And how to deal with the fact that whois servers have no standardized way
to
> indicate they do not know a key queried for.

Once the server has been reached by means of SRV, contents transmitted are
not relevant the process.

> This scheme could be extended to cover inetnum lookups (only the IPv4
case is
> outlined here):
[...]
> Opinions?

Fine!

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

Thanks for the reference, we'll take a look at it.

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

Both are real good points. They directly depend upon the behaviour of the
SRV client, which is not determined here (top to bottom? bottom to top?
stop walking the tree after answer?). Nevertheless, I think 1) finds a
place in our draft, as a direct effect of the interaction between Whois and
DNS.

Regards,
Marcos