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:[email protected]] 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
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
