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 > writes > : >> 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 given >> 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 too >> 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 the >> 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 matters is creating a protocol that doesn't unnecessarily cause damage to the DNS. > 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. > 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 do that. So, I again propose that this part of the new protocol be removed because it is unnecessary and possibly harmful. >> The third paragraph of Section 5.3 gives a new scenario in which TCP SHOULD b >> e used. Thus, I think this draft updates RFC 5966, and the draft should be ma >> rked as such, even if it is only for this one important part. Also, this para >> graph should refer to RFC 5966. > > RFC 5966 has "or for other operational reasons," which covers this. > Implementations have always been free to sent requests over TCP. > e.g. netstat has been using TCP rather than UDP for decades. Good catch. Ignore my request because 5966 already covers it. --Paul Hoffman _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
