Subject: [Ietf-not43] DNS servers in WHOIS output

From: [email-masked] (Eric A. Hall)
Date: Wed, 06 Feb 2002 21:13:50 -0600

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/

---

From: [email-masked] (Stig Venaas)
Date: Thu, 7 Feb 2002 08:06:08 +0100

> records as directory objects. While such a structure would provide

I have a simple schema that might be of use (used for storing zones
in LDAP), but I guess the hardest part isn't the schema it self, but
all the related issues you listed.

> registration INPUT. However, as argued above, WHOIS+DNS is NOT required

Agree with this and the text I deleted above.

> always been there, but it isn't absolutely required.

I think the latter.

>From our standpoint, the idea is (was?) that the output from
traditional WHOIS should look like the registration forms. This
might help in some cases, but I'm not sure how important that is.
I think it's just as well to leave it out.

Stig

---

From: [email-masked] (Andrew Newton)
Date: Thu, 7 Feb 2002 11:16:27 -0500

> in the WHOIS output, other than ~"we have always done it that way."
[..snip..]
> always been there, but it isn't absolutely required.

I think you are making a bigger deal out of this than necessary.
The intention of WHOIS as it relates to why NS records are duplicated
there is to be a place to go when DNS isn't functioning properly.
Such things as cache poisoning, incorrect master/slave relationships,
etc... can cause this.  And yes, I have used it for troubleshooting.

But since this is for troubleshooting and nobody is saying to do
backup resolution out of WHOIS or LDAP (atleast I hope not!), it
isn't necessary to reproduce the DNS infomation verbatim.  So breaking
this out into separate NS and A records seems to be overdoing it
a bit.

-andy

-- 
Andrew Newton
VeriSign Applied Research
[email-masked]

---

From: [email-masked] (Andrew Newton)
Date: Thu, 7 Feb 2002 11:46:30 -0500

On Thu, Feb 07, 2002 at 10:38:54AM -0600, Eric A. Hall wrote:
> 
> So read-only replication is okay. Alright, replication from what then?
> Does it replicate from DNS where it is the most valuable for diagnostic
> purposes, or does it replicate from the registration database? Although
> these should be the same thing they won't always be. Updates which go into
> DNS the next day, for example, will have different values in the two
> systems. Which one to use?

Well, if it is being used for troubleshooting, I would only use the
values out of WHOIS when DNS isn't working (and let's be clear,
for finding the problem, not as an automated back-up resolution
process).  It also depends on the
registry as to the accuracy of WHOIS vs. DNS and the latency between
updates.

-andy

---

From: [email-masked] (Eric A. Hall)
Date: Thu, 07 Feb 2002 10:38:54 -0600

If we do this, how does the data need to be defined? Clearly we want
information to be programmatically parsable for maximum leverage (not as
an out-of-band way to do DNS, but to allow clients to perform routine
tasks on the data, such as querying the servers for the SOA of the zone,
to see if it actually exists). This requires a schema for DNS RRs, if we
want to do it right.

Also, if we're going to do that, shouldn't we also look at providing
routing information with the IP networks?

---

From: [email-masked] (Eric A. Hall)
Date: Thu, 07 Feb 2002 11:09:46 -0600

> values out of WHOIS when DNS isn't working (and let's be clear,

Okay. We can also make use of the various Modifed* operational attributes
to show when/who the changes were made, which will let people know if
there is some lag between the registration view and the DNS view.

I'll start looking at the attributes needed for this.

ps--I'm of the opinion that this information is absolutely necessary to
deployment. People will scream if a useless feature is no longer
available, which will hinder deployment, so I will give them the useless
feature. I just wanted to confirm that it is in fact useless.

---

From: [email-masked] (Bruce Campbell)
Date: Thu, 7 Feb 2002 21:35:30 +0100 (CET)

> > this out into separate NS and A records seems to be overdoing it

tab or 'known character' seperated for preference please.

> purposes, or does it replicate from the registration database? Although

'Most valuable' for diagnostic purposes would be to use the same,
authoritative source that the zone files are generated from.  In most
cases, this is the Registration database.

Regards,

-- 
                             Bruce Campbell                            RIPE
                   Systems/Network Engineer                             NCC
                 www.ripe.net - PGP562C8B1B                      Operations