[DNSOP] CloudFlare policy on ANY records changing

["Wessels, Duane" <[e-mail]>]

On Mar 10, 2015, at 9:34 AM, Paul Hoffman <[e-mail]> wrote:

> On Mar 10, 2015, at 8:46 AM, David C Lawrence <[e-mail]> wrote:
>> 
>> Paul Hoffman writes:
>>> On Mar 10, 2015, at 6:25 AM, Yunhong Gu <[e-mail]> wrote:
>>>> So the problem is, why NOTIMP? REFUSED sounds like a better choice. 
>>> 
>>> +1. "REFUSED" exactly describes what is going on.
>> 
>> One down side there, however, is that REFUSED as understood by
>> resolvers commonly has the semantic currently that the name is not
>> hosted by the server at all.  What used to be root referrals for lame
>> delegations is now REFUSED to minimize response size.
> 
> If a resolver is sending an ANY before it sends its actual request, that could be a problem. However, they shouldn't be doing that.
> 
> It is likely that any response we think of (even no response at all) will cause some deployed resolvers to get the wrong idea. Having said that, it is perfectly reasonable for an operator to not want to reply to an ANY, given the unclarity of what it is expected to send back and the opportunity for malicious intelligence gathering. So us saying "if you want to do this, use that" at least will cause future versions of things that relied on ANY to know what they are getting.
> 
> Also: this should probably one of the three threads on [e-mail]...


As Paul suggests, I'll attempt to redirect the conversation to dnsop.

Does it make sense to define an Extended RCODE for additional signaling?
e.g.  "REFUSED_BECAUSE_QTYPE_ANY"

If you want to respond to ANY with NOTIMP/REFUSED, would you also
be willing to include an OPT RR in your response (when appropriate)?

DW