On 13 November 2017 at 10:55, Paul Vixie <p...@redbarn.org> wrote: > > > Matthew Pounsett wrote: > >> >> >> On 13 November 2017 at 06:52, John Kristoff <j...@depaul.edu >> <mailto:j...@depaul.edu>> wrote: >> >> REFUSED does not seem ideal to me either, but what if anything might >> be >> better is probably ripe discussion in a new draft. >> >> It makes perfect sense to me. REFUSED is an indication that the querier >> has been blocked from asking that question (or receiving the answer they >> requested) by configuration, as distinct from a broken configuration >> preventing them from getting that answer (SERVFAIL). >> > > why is this nor a broken configuration? >
It's my understanding that SERVFAIL indicates that the server sending the RCODE–or in the case of a recursive response, the upstream authoritative server–has a broken configuration. I don't believe SERVFAIL indicates "you followed a lame delegation." As far as I'm aware, we don't have a clearly defined signal for that, which is why many implementations chose to use REFUSED in that case. > > ... Given that upward >> referrals have obvious problems (There is no protocol or process to tell >> a TLD operator "I am not authoritative for that delegation someone else >> asked you to point at me") it seems to me that REFUSED is the only >> obvious choice for indicating that an authoritative-only server is not >> authoritative for anything at or below the QNAME. >> > > i strongly disagree. this is not an administrative denial scenario. see, > again: > > > http://www.circleid.com/posts/20120111_refusing_refused_for_sopa_pipa/ > > I haven't got the time this morning to search release notes, but I'm fairly sure that in 2012, when you wrote that article, current versions of BIND were already handing out REFUSED to indicate "I'm not authoritative for that." At the very least it began doing that not long after. If that were a problem, given BIND's market share, we should be seeing widespread brokenness, but I don't think we are–none that's making it from my support department to me or to our hostmaster@ accounts, at any rate.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
