I remember a much older version of this mechanism, but I imagine many are not. It isn't until quite a bit into the document where the reader is really given any idea about what DNS cookies are or how they work. This might be annoying to the reader, because especially in section two that describes various threats, there are numerous statements about how DNS cookies might help mitigate these threats. I'd suggest a succinct summary of what DNS cookies are or do, more than "they are a "transaction security mechanism" in the introduction.
Section 2.1.2,, second to last sentence reads in part: ""The computational or communications burden caused by such requests may not dependent on a forged IP source address [...]" In the first part, I think there is a missing verb "be" between "not" and "dependent". Section 2.1.2, last sentence reads in part: "Use of DNS cookies should enables a server to reject forged queries from an off path attack with relative ease and before [...] " Remove the word "should". I'd also recommend removing phrase "with relative ease and ", since that is largely superfluous and subjective. Something to consider mentioning in section 3 is TCP-AO. I don't think it has ever been widely deployed outside of BGP services, but TCP-AO (IETF RFC 5925) is an option and might be perhaps worth mentioning that is is, but only for TCP and has not seen deployment in the DNS, even on a limited basis where TSIG has often been used for things like AXFR/IXFR between slaves and masters. The ASCII cookie option figures 1 and 2 look a little awkward with that 2 byte hole following the error code. Maybe it would be better to draw it as 16-bit aligned as IETF RFC 6891 does? The statements at the end of sections 4.1 and 4.2 conclude similarly: "A client MUST NOT use the same Client Cookie value for queries to all servers." "A server MUST NOT use the same Server Cookie value for responses to all clients." The obvious logical question would be, but it is OK to use the same cookie for "some" of them? The nomenclature of BADCOOKIE is misleading since a missing server cookie for an initial request is in no way "bad", but perfectly legitimate. This is minor, but it might be syntactically preferable to use better descriptors. Lastly, a couple of random thoughts... should cookies received be available to logging systems or collected by passive DNS systems for analysis and debugging? As implicitly described in 5.2.3, there is a risk of making a DDoS attack a little worse when cookies are implemented. If cookies become widely deployed, servers might want to return a TC=1 response if there is a cookie OPT but no server cookie present for that bootstrapping query. John _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
