On 13 November 2017 at 11:28, Paul Vixie <p...@redbarn.org> wrote: > > ... 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. I don't think that word means what you think it means. Lack of concern for a non-problem is not complacency. The rest of us still see spoofed-source DDoS attacks, and they're a frequent topic of discussion in the networking and DNS communities, so even someone who doesn't see them on their network should still be aware that they happen. I have seen no similar discussion of REFUSED-generated chaos in recursive servers. If someone is seeing such brokenness, they haven't brought it to dnsop@, or dns-operations@, or an OARC or NANOG meeting. If someone is seeing such brokenness, hopefully they'll speak up so that we can advise the authoritative implementations to change their behaviour again. I use the plural there deliberately. I referenced BIND above because that was the implementation I was most familiar with at the time the behaviour changed ... but it does seem to be the consensus among the authoritative implementors that REFUSED is the correct response. It wouldn't be the first time that a majority of implementations settled on a behaviour that didn't strictly follow the specification because it was necessary for good inter-operation. Perhaps someone who was present for an implementer's internal discussion about replacing upward referrals could comment on the reasoning, and what (if any) collaboration occurred between the authoritative and recursive implementations at the time.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
