In message <55daa47d-bc41-4416-a7f1-bd21c9dc7...@vpnc.org>, Paul Hoffman writes : > On Jul 6, 2015, at 8:02 AM, Mark Andrews <ma...@isc.org> wrote: > >> It really doesn't matter if they are "already broken" in your view: > what matt > >> ers is creating a protocol that doesn't unnecessarily cause damage to > the DNS > >> . > > > > How can a intrinsically hop-by-hop "extension" "damage" the protocol? > > Because there are lots of other systems that watch either end. A logger > that expects a query is the one I am most concerned about, but there are > probably others as well. I understand that you feel "they are broken and > we shouldn't care about them". I care about avoiding broken things if we > can get the same functionality.
qcount == 0 can be used to probe for lots of things, including but not limited to determining if a server is up as there are servers that fail to respond to qnames they do not serve but do respond to qcount == 0 queries. Just sending a COOKIE option will break some system somewhere. Worrying too much about breaking things leaves you paralysed. I would have said COOKIE + EDNS(1), to get into well defined behaviour for unknown options, but there wasn't enough benefit to doing it at too many systems drop EDNS(1) queries rather that send back BADVERS. That is not to say we shouldn't do a EDNS version jump for something else. Adding qcount == 0 later would also be worse than doing it now as there would be nothing tying the two changes together. > > It either works for the client/server pair or it doesn't just the > > same as sending a NSID option either works or it doesn't or sending > > a IQUERY either works or it doesn't. This is all client driven. > > But watched by other system. > > > "extension" because it is already permitted. > > > >>> As for sending a random query you then have to deal with all the > >>> different behaviours for sending a query to a server which is not > >>> expecting the QNAME on top of discovering if COOKIE is supported. > >> > >> Why? As I described above, it is fine if the QNAME is nonsense to the > server: > >> it will still answer with the cookie. > > > > And it complicates the code handling the responses. > > Not at all! You fully covered (and I think correctly so) all the cases of > queries that get non-zero RCODE responses still getting the server cookie. I covered all the cases of a well behaved servers. There are non well behaved servers (or firewall server combos) out there that don't even meet RFC 1034 / RFC 1035 minimums of responding. See the example above. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
