tl;dr: I am thinking of the "principle of least surprise", for the use case of interactive "dig" users.
Here's why: Asking ANY to a recursive resolver, the expected behavior is "whatever is in the cache" (which could be a subset of the real RRsets, and possibly empty even though RRs exist on corresponding auth servers). No-error, no-data in this circumstance would not be unexpected, and would not be a cause for concern. Asking ANY to an auth server, the expected behavior is "everything at this node". At 3am, when investigating a problem with a domain, if I unwittingly type "ANY" as the type, I don't want to have to think about or remember that the behavior changed, and that the "no-error, no-data" answer really means "deprecated". I would be happy if the differential behavior were "refused" or "notimpl", in this specific corner case (RD=1, to an auth server). Maybe that compromise is sufficient? It would still accomplish Olafur's goal. Brian On Wed, Mar 11, 2015 at 2:00 AM, Paul Vixie <p...@redbarn.org> wrote: > > > Brian Dickson <brian.peter.dick...@gmail.com> > Wednesday, March 11, 2015 11:13 AM > On Sun, Mar 8, 2015 at 2:55 PM, Brian Dickson < > brian.peter.dick...@gmail.com> wrote: > >> Hey, everyone, >> > [snip] > >> "dig"-friendly. >> > > Okay, thinking about this a bit more... > Recursive vs authoritative, RD=0 vs RD=1. > > In all combinations of the above, do the "new thing", except for one > corner case: > if(RD==1 && I_AM_AUTHORITY) then > do_ANY > > (Which happens to be the default if someone uses "dig" against an auth > server). > > > djb doesn't want QTYPE=ANY deprecated in any form. > > olafur doesn't want to "do_ANY", under any conditions. > > so i'm baffled by why you're offering this alternative? > > -- > Paul Vixie >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
