On Mar 10, 2015, at 9:34 AM, Paul Hoffman <paul.hoff...@vpnc.org> wrote:
> On Mar 10, 2015, at 8:46 AM, David C Lawrence <t...@akamai.com> wrote: >> >> Paul Hoffman writes: >>> On Mar 10, 2015, at 6:25 AM, Yunhong Gu <g...@google.com> 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 dnsop@ietf.org... 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
