> This note starts the WG Last Call for comments on > 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 . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
