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. 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. 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. If you want to play with a dig that supports +header-only it is available at https://source.isc.org [rock:~/git/bind9] marka% dig +cookie +header-only +qr @8.8.8.8 ; <<>> DiG 9.11.0pre-alpha <<>> +cookie +header-only +qr @8.8.8.8 ; (1 server found) ;; global options: +cmd ;; Sending: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50037 ;; flags: rd ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: 28f7b8576f571ca9 ;; QUESTION SECTION: ;; QUERY SIZE: 35 ;; connection timed out; no servers could be reached [rock:~/git/bind9] marka% [rock:~/git/bind9] marka% dig +cookie +header-only +qr @f.root-servers.net ; <<>> DiG 9.11.0pre-alpha <<>> +cookie +header-only +qr @f.root-servers.net ; (2 servers found) ;; global options: +cmd ;; Sending: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40527 ;; flags: rd ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: 5abce2514ce635b2 ;; QUESTION SECTION: ;; QUERY SIZE: 35 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 40527 ;; flags: qr rd; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; Query time: 407 msec ;; SERVER: 2001:500:2f::f#53(2001:500:2f::f) ;; WHEN: Mon Jul 06 10:27:28 EST 2015 ;; MSG SIZE rcvd: 23 [rock:~/git/bind9] marka% [rock:~/git/bind9] marka% dig +cookie +header-only +qr ; <<>> DiG 9.11.0pre-alpha <<>> +cookie +header-only +qr ;; global options: +cmd ;; Sending: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5967 ;; flags: rd ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: 64f2c6d5a5726046 ;; QUESTION SECTION: ;; QUERY SIZE: 35 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5967 ;; flags: qr rd; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: 64f2c6d5a57260466b74174c5599cc27d6979aa9b3385ad1 (good) ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mon Jul 06 10:30:31 EST 2015 ;; MSG SIZE rcvd: 51 [rock:~/git/bind9] marka% > Editorial: > > In Section 2.2, "the Dan Kaminsky attack" sounds like an attack by someone, n > ot described by someone. The parenthetical can probably be removed, or turned > into an informative reference from something that Dan wrote. > > In Section 5.2, second paragraph, "as before" is unclear. This probably means > "as if no COOKIE OPT option had been sent", but it should be explicit. > > Procedural: > > 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. > I continue to be concerned that draft-eastlake-fnv, which is likely to be use > d by implementations of cookies, is still just a draft, not an RFC. It's not > for this WG to do, but anyone implementing this draft should read that draft, > send comments, and let's get that published as well. > > --Paul Hoffman > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- 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
