[Ietf-not43] DNS servers in WHOIS output

[Eric A. Hall]

I'm updating the LDAP-WHOIS specification, and have an open issue that
needs addressing. See the following text, and the question at bottom.


10.3.	Nameserver Attributes

WHOIS servers for DNS domains have historically provided information about
the DNS servers associated with a domain, such as providing the hostnames
and IP addresses of the DNS servers which have been delegated authority
over a particular domain.

However, this information has typically been provided as a reflection of
the registration process, and has not been provided as a beneficial part
of the WHOIS service in particular. Users who have needed to find and
review DNS information have typically known to use DNS for this function,
and have had no motivation to use WHOIS for this purpose.

Furthermore, providing this information in the LDAP-WHOIS model is
somewhat problematic, since it is difficult to integrate the DNS data into
LDAP cleanly. The best design for such a service would entail an auxiliary
object class for the inetDnsDomain object class which provided resource
record attributes, and which stored NS and the associated A resource
records as directory objects. While such a structure would provide
multiple benefits to multiple problems, it seems imprudent to pursue this
approach for the single short-term objective of caching delegation name
servers.

For this reason, attributes for this information are not provided in the
LDAP-WHOIS service. Instead, users and application developers are
encouraged to develop practices for querying the DNS zones for information
related to DNS. However, if this information is absolutely required,
server operators MAY provide it as unstructured data in the
inetGeneralComments free-text attribute (possibly using a name:address
pair for each server).


There are a couple of questions to ask here. First of all, how accurate is
that assesment? My own experience is that DNS is the best place to debug
DNS problems. If a domain isn't delegated in the parent, who cares what
WHOIS says? Conversely, any servers which may be listed in WHOIS are
likely to answer, but who cares if they answer if the DNS delegation is
broken? In that regard, any DNS data which may be provided in WHOIS is
useless, for all practical purposes. By the same token, we don't expect
that the zone delegation will give us WHOIS date, so why do we need to
expect that the WHOIS data should give us the DNS delegation? Show me how
it could be otherwise, if you believe as much.

Secondarily, the principle reason that ANY such data has ever been
included with the WHOIS information is because WHOIS+DNS is required for
registration INPUT. However, as argued above, WHOIS+DNS is NOT required
for output.

In light of that argument, it is worth noting that the LDAP-WHOIS service
is neither designed nor intended to function as a registry interface. As
such, there is no compelling reason I can think of for including DNS data
in the WHOIS output, other than ~"we have always done it that way."

Now then, having said all of that, it is possible to include DNS data in
the WHOIS output, and to do so in a format which is programmatically
parsable, which is to spend a fair number of cycles on a schema for
resource records in general. This will be required sooner or later anyway,
so its not a huge issue to do it sooner. However, I would rather not
inflate the initial deployment requirements too much. Furthermore,
providing this information also carries a certain responsibilty to discuss
where the data comes from, the security risks from failing to secure the
data, and so forth. It really raises the first-step bar dramatically, and
this is something I would rather avoid.

So, is DNS information such as NS RRs and the glue A RRs something that
people really need, or is it just something that people expect because its
always been there, but it isn't absolutely required.

Comments please

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/