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. > 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. --Paul Hoffman _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
