Matthew Pounsett wrote:
On 13 November 2017 at 10:55, Paul Vixie <p...@redbarn.org <mailto:p...@redbarn.org>> wrote: > 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.
someone asking you an RD=0 question about a zone you're not authoritative for indicates a misconfiguration somewhere. this is what SERVFAIL is for, because at the signalling level, it tells the client that no possible query about that name can succeed, and it ought to stop sending questions like that to this server. it's no different in principle from "i'm out of disk space, so i can't fetch the zone, so even though i'm supposed to be a secondary, i can't do it right now."
> 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.
the implication of REFUSED is that if someone else asked this question, we might be able to answer. so if BIND is doing what you say, it's wrong.
... 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.
yikes! you remind me of the guy who said on nanog a few years back that since he wasn't seeing spoofed-source ddos attacks any more, we should all stop worrying about them.
your lived experience can be cause for concern, but never for complacency. -- P Vixie _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
