Re: draft-manning-dnssvr-criteria-01.txt

[Robert Elz <[e-mail]>]

    Date:        Sun, 5 May 1996 22:47:34 -0700
    From:        Paul A Vixie <[e-mail]>
    Message-ID:  <[e-mail]>

    This isn't a misfeature of BIND, and your
    own draft-ietf-dnsind-clarify-01.txt (section 3 and especially
    section 3.1) enshrine the same thing that
    draft-manning-dnssvr-criteria-01.txt is trying to say.

I would never have thought that.   It is a little more that way
in the -01 version, the first sentence is certainly on the same
topic.   But point number 4 is "Singly homed (only one interface)"
which has nothing to do with draft-ietf-dnsind-clarify-01.txt at
all, which (where it is relevant) actually presumes that DNS
servers may have multiple interfaces.

I'd always thought that the reason for the single interface
requirement was to keep the packet sizes down, so multiple A
records would not have to be included.   If that is really what
is behind this, then it would be better to actually state the
requirement in terms of the packet size that will be geenrated
in response to a NS query, 3 servers with 3 interfaces each is
clearly OK, but 9 servers with three interfaces each might be
too much.

In that regard, a potential server for "." with three interfaces
(actually advertised) would not be a good idea, but a 3
interface server for some other TLD might be just fine.

Further, it would help a lot if the reasons for the various
qualifications were given, instead of just stating them.

Eg: point 3 "Dedicated host".   I saw a comment by someone else
in the past couple of days (sorry, I forget who) who had assumed
that this requirement was because of load on the server - and that
a big enough server may be able to cope easily with both the DNS
and other work.   I had assumed this requirement was for security
reasons - preventing other work lowers the chances of a bug in some
other service allowing an intruder to corrupt the DNS.

Without knowing which of those is correct it is very hard to
judge whether the qualification is needed or not.  Further, once
published, not knowing why something has been required makes it
very difficult for an organisation considering running a TLD to
decide whether or not that particular qualification is one that
really should be followed through with, or whether they can afford
to ignore it in their circumstances.

    therefore I believe we ought to trim the current document down
    to just the things that are true of the "." servers.

Most of the earlier points that I sent Bill, which he may have
lost, or something, would be satisfied by that.   Explanations
just why the list includes the points it does would still help.

In any case, since Bill has now said that a new draft is coming,
perhaps we should all just defer further discussion (at least on
the IETF list) until, at least, after that appears?

kre