In message <23a55564-aaf1-4786-9663-c38a019c9...@vpnc.org>, Paul Hoffman writes : > On Jul 5, 2015, at 6:16 PM, Mark Andrews <ma...@isc.org> wrote: > > > > > > In message <b3fdac88-1da8-4be3-9d75-115386f7d...@vpnc.org>, Paul Hoffman wr > ites > > : > >> Greetings. This is a WG LC review of draft-ietf-dnsop-cookies, which I had > no > >> t looked at carefully in some time. In short: it looks great, the document > is > >> complete and easy-to-read, and we probably should have done this nearly a > de > >> cade ago when Donald started the work. > >> > >> Substantial: > >> > >> In Sections 4.1 and 4.2, it says that the cookies MUST NOT be the same for > al > >> l recipients. This should be SHOULD NOT, to match the SHOULDs above. If an > im > >> plementation does a stupid and uses the same cookies everywhere, it is no > wor > >> se off for it, it just isn't getting as much protection as expected. (If I > 'm > >> wrong about that latter bit, then the reason for the MUST NOT should be gi > ven > >> in both sections.) > >> > >> Section 5.4 seems unnecessary and possibly harmful. Why have an additional > me > >> ans to detect support other than "ask any question, even one that is going > to > >> get a REFUSED or NXDOMAIN answer"? The new mechanism will wreak havoc on t > oo > >> ls that are watching DNS requests, for no real reason. I propose that this > se > >> ction be removed, or replaced with a simply "if you want to know whether t > he > >> server supports cookies, ask anything". > > > > "Wreak havoc" is a little bit over dramatic. If the tools can't > > handle QCOUNT == 0 they are already broken. This is the Internet > > and the tools should be expecting to get total garbage packets. > > Not sending QCOUNT == 0 won't help them. QCOUNT == 0 is potentially > > useful for other things. Existing nameservers mostly return FORMERR > > though Google's nameservers (8.8.8.8) just drop the query despite > > it being a legitimate RFC 103[45] query. We looked to see if we > > needed a Updates RFC 103[45] and as far as we can tell we don't. > > 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? 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. "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. > > Additionally this is just the equivalent of syn / syn ack / ack at > > the DNS/UDP level. I'm yet to extend dig to do this but it is on > > my to do list (dig +get-cookie-first (defaulting on) looks like a > > good option name). "dig +cookie" will be on by default so that > > broken EDNS option behaviour by servers is made visible and it more > > closely matches what recursive servers supporting COOKIE will do. > > It sounds like you want this protocol to purposely cause problems for servers > that are not implemented the way you want. A less brittle design would not d > o that. It will cause zero problems for servers. All the issues fall on the clients. This is true of using new EDNS options and/or when sending qcount == 0. The problem is not exercising the new code paths from the very begining. For example no one exercised/tested EDNS version negotiation in the wild and now everyone is afraid to go to EDNS(1). That said I ran a EDNS recursive server for months that sent EDNS(1) queries and for the most part there were few issues. > So, I again propose that this part of the new protocol be removed because it > is unnecessary and possibly harmful. -- 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
