So you're thinking it's more likely that we'll get folks to understand this new type, that's designed to frustrate QTYPE=* queries in a more-or-less graceful way, than it is to convince them to stop making QTYPE=* queries in the first place?
Don't get me wrong -- I would actually *applaud* the definition of a new RR type (and possibly, a new meta-type to go along with it) that was designed to facilitate a controlled ability to fetch all RRsets for a given name, in a single query. That would be forward progress, in my opinion. But to create a new RR type solely for the purpose of making an RFC 1034/1035-defined feature of DNS less useful than it would otherwise be? I see that as going backwards, verging on Luddite. What's next? A new RR type to "gracefully" frustrate senders of MX queries, because we consider SRV a more general mechanism for accomplishing the same thing? That's a hell of a way to evolve a protocol, creating new RR types specifically to render old QTYPEs or RR types useless... - Kevin -----Original Message----- From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Florian Weimer Sent: Thursday, March 12, 2015 12:30 PM To: Tony Finch Cc: Evan Hunt; dnsop; Wessels, Duane; Paul Vixie Subject: Re: [DNSOP] CloudFlare policy on ANY records changing * Tony Finch: > I also tried a stupid hack to send an ANY RR in the response. BIND's > resolver treats this as a FORMERR and returns SERVFAIL to the client. What about introducing a new non-meta RR type for this purpose? It would not increase the response size by much. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop