On 8/19/16, 13:24, "william manning" <[email protected]> wrote:
>First off, I take exception to the use of the word "dangerous". AXFR isn't >dangerous, it's just the best way to do the job. If there are other query >types that are better (or only) can be done over TCP, then so be it. But they >aren't per se dangerous. Dangerous is in the eye of the beholder. I had in mind the critiques that ANY queries were dangerous (with some operators already curtailing them). AXFR isn't dangerous, but it is restricted to TCP because of a different need, the need to maintain ordering of the segments. >End of the day, this question is fundamentally one of which side knows best >what the application is looking for, the resolver or the server? That's the root cause of the work here. In 2009 or so I recall an IAB draft document on DNS that urged an end to "curving the DNS" to applications. My response was that the only evidence to date was the MX record's inclusion of the A record in the response - harking back to the origin of domains in email arguably driving the definition of the DNS as a protocol. (Forgive a lot of hand waving, I do have another draft that covers that in more formal detail.) The DNS has, historically, for better or worse, remained neutral towards the applications that use it. I suspect that the fear was that if the DNS helped one protocol out, it might harm another, so we've kept an even keel. I'm not saying that we must remain that way, just that this is the historical record. The problem with now defining what additional record sets belong to certain queries is that we make handling unknown record types murky. Perhaps we can have a subset of RR type codes that are set aside for types with additional section expectations - I just can't imagine writing future-proofed code in that case. So maybe that's a stupid idea. (Not the first one today.) I'm open to other solutions. I'm just giving a historical perspective. What can go in EDNS0 or into "session" state is an open topic, as an example.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
