Subject: [dnsop] WGLC for draft-ietf-dnsop-serverid-04.txt

From: David Meyer <[email-masked]>
Date: Fri, 1 Apr 2005 12:23:40 -0800

Folks

	This note starts the WG Last Call for comments on
	draft-ietf-dnsop-serverid-04.txt, "Identifying an
	Authoritative Name Server". It can be found on   
	
	ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsop-serverid-04.txt

	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. 

	This Last Call will end on 15 Apr 2005 at 1400 PST (UTC/GMT-8).

	Thanks,

	Dave & Rob

---

From: Pekka Savola <[email-masked]>
Date: Tue, 5 Apr 2005 15:50:10 +0300 (EEST)

> 	not you believe that this document is ready to go to the

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

---

From: Peter Koch <[email-masked]>
Date: Tue, 05 Apr 2005 16:18:46 +0200

> 	draft-ietf-dnsop-serverid-04.txt, "Identifying an

This document is heading Informational status, I guess. Here are some minor
nits:

o The hostname.bind mechanism not only works for authoritative (for what?)
  servers but regardless of the set of zones served (if any at all). It's not
  clear to me why the scope is restricted here (just see that Pekka's making
  the same point).

o Given that the draft addresses "authoritative" servers and that it suggests
  the querying magic be part of a normal DNS query, what should a 'recursive
  server' do once it sees this type of query?

o In 4.2 it's OK to say a CLASS *or* top level domain, because we want neither

o The list of requirements should address scaling, i.e. is this new query
  to be issued for (manual) debugging only or should one be able to activate
  it by default on a resolver/recursive server? What impact on load and/or
  packet size may it have (the query/response should not force anyone to TCP)?

o Security considerations could add that no one should trust the magic ID
  returned, especially not to weigh one response more than another. It's
  not a security measure and does not provide for authenticity. However,
  it might be useful to be able to apply signatures to the ID.

o "hostname.bind" should be consistently written and ISC's CI police might
  want to review section 3.

-Peter
.

---

From: Bruce Campbell <[email-masked]>
Date: Tue, 5 Apr 2005 18:33:47 +0200 (CEST)

> 	ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsop-serverid-04.txt

With regards to 3.2.1 and 4.1 of this document (identification being
in-band with the query), what would be the reasons _against_ suggesting
that implementations be able to deal with multiple queries within a single
packet, ie:

	www.example.com/IN/A
	magic.server.identifier.string/CH/TXT

and get back a single packet containing answers to both queries.

The initial reasons that I can come up with are:

	*) Answering multiple queries is not implemented at present on
	   most nameserver implementations.

	*) The meaning of flags becomes confused.

	*) When debugging a resolving nameserver, where is the answer
	   to the identification string originated from?

--==--
Bruce.
.