Please review the document carefully, and send your
feedback to the list. Please also indicate whether or
not you believe that this document is ready to go to the
IESG.
First time I read this document. It's a great start, but requires still
a little bit of polish (one or two revisions) in particular wrt. spelling out the requirements to be more useful.
Below...
substantial -----------
Identifying an Authoritative Name Server
==> let's start with the name. It's not 100% clear what the focus of the
document is; identifying any name server (a recursive resolver included,
non-authoritative), or just identifying authoritative name servers. I
submit that we should do the former, so the title is too narrow.
(I didn't check whether elsewhere in the doc there is a need for adjusting)
==> further, the title could describe what the document actually does, maybe something like "Identifying the DNS Server: Requirements and Existing Conventions"
1. It requires an additional query to correlate between the answer
to a DNS query under normal conditions and the supposed identity
of the server receiving the query. There are a number of
situations in which this simply isn't reliable.
2. It reserves an entire class in the DNS (CHAOS) for what amounts
to one zone. While CHAOS class is defined in [RFC1034] and
[RFC1035], it's not clear that supporting it solely for this
purpose is a good use of the namespace or of implementation
effort.==> these need spelling out.
1) the last sentence probably refers to setups which are load balanced so
that one query can go on one host while the next could go to the another. This is an important consideration, worth stating out (maybe also where this
might happen and why)
2) As the specs already support multiple classes, this begs to question, "why is it a problem?" Implementations already have to support multiple classes (I guess) and I doubt it has anything to do with name space conservation. I guess it could have something to with DNSSEC being in a different class, but these issues should be explicitly spelled out.
....
1. The mechanism adopted MUST be in-band for the DNS protocol. That
is, it needs to allow the query for the server's identifying
information to be part of a normal, operational query. It SHOULD
also permit a separate, dedicated query for the server's
identifying information.==> "MUST be in-band" is not explicit enough because hostname.bind is also in-band (though maybe with different definition of "band"). I guess the main point is that the server identification request/reply MUST be piggybackable on regular DNS packets to avoid the disadvantage 1).
4. It should be possible to return a unique identifier for a server
without requiring the exposure of information that may be
non-public and considered sensitive by the operator, such as a
hostname or unicast IP address maintained for administrative
purposes.==> a bit more explicit description might not hurt. It is not clear to me at least how this kind of identifier would be useful if it's just a random blob (whatever the implementation decides to blurt out)? Also, it's not clear what you mean by "unicast IP address.. for admin purposes". Some kind of private back-end addresses? I'd assume that anycasting hosts would also have a stable, globally routable unicast address which could be returned (and which could be very useful for debugging purposes) here.
So, I guess the biggest thing is to consider what kind of information for
server identification the operators using this feature would like to get. I'd at least like to get a global unicast IP address which I could use to
query working/non-working server directly to test their behaviour for
debugging purposes.
semi-editorial --------------
==> the document includes MUST, SHOULD, etc. keywords, which are generally considered a bit inappropriate in a requirements document. I'd just downgrade them to the lower case, but if there's consensus to keep them, at least their use needs to be defined (e.g., with reference to RFC2119)
==> there is some amount of overlap with introduction and rationale (and introduction pretty closely follows the abstract). Introduction being as short as it is, I might consider compressing section 1 and 2 to one, eliminating the overlap and having nice and concise introduction and problem statement in one.
Software Consortium [BIND] support a way of identifying a particular server via the use of a standard, if somewhat unusual, DNS query.
==> s/standard/specific/ (let's not confuse this with anything standardized.. :)
[...] This mechanism, which is an extension of the BIND convention of using CHAOS class TXT RR queries to sub-domains of the "BIND." domain for version information, has been copied by several name server vendors.
For reference, the other well-known name used by recent versions of BIND within the CHAOS class "BIND." domain is "VERSION.BIND." A query for a TXT RR for this name will return an administratively defined string which defaults to the version of the server responding. This is, however, not generally implemented by other vendors.
==> large chunk of the text appears to be overlapping. Reword?
5. IANA Considerations
This document proposes no specific IANA action. Protocol extensions, if any, to meet the requirements described are out of scope for this document. Should such extensions be specified and adopted by normal IETF process, the specification will include appropriate guidance to IANA.
==> I don't think this needs to be in the final RFC, so I'd put in a note here like "RFC-editor: please remove prior to publication" or the like.
editorial ---------
==> I'd suggest using compact=no, subcompact=yes to compress to save the paper a bit :)
Recent versions of the commonly deployed Berkeley Internet Name Domain implementation of the DNS protocol suite from the Internet
==> how recent? Hasn't this been in there for a long time already?
3. It is simple to configure. An administrator can easily turn on
this feature and control the results of the relevant query.==> turn on? Isn't it on by default? Is the default setting implementation-specific? How about turning off if default to on?
-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
