Hello, On Mon, 17 Jun 2024 10:22:24 +0100 Kirill A. Korinsky <kir...@korins.ky> wrote:
> On Mon, 17 Jun 2024 00:21:27 +0100, > J Carter <jordanc.car...@outlook.com> wrote: > > > > Well *I* quite agree. > > > > I would also suggest that as DNS functionality in nginx is strictly > > limited to resolving as client in quite a simplistic fashion, and nginx > > does not support DNSSEC, it makes little sense to hyper-strict about > > the DNSSEC extension bits in general regardless of what is written in > > the RFCs. > > > > Perhaps it would be better if the patch linked to in my previous > > response was bumped and reconsidered over your patch, as that would also > > ignore incorrectly set CD bit in addition to ignoring AD bit, which > > also appears to be a common issue with certain recursive resolvers. > > Well, the CD bit means that this response contains a response that fails > DNSSEC, but for some reason was sent back. > > I've checked unbound and it returns SERVFAIL in such case, or wit no CD bit > enabled if DNSSEC validation is off. > > Also, I've checked OpenBSD's unwind, which is libunbound-based, which has > the accept bogus option for forwarder to tolerate invalid DNSSEC. > > Finally, I've tested a random WiFi router running dnsmasq (confirmed by > fpdns) and it also returns SERVFAIL with broken DNSSEC. > > Do you have an example of zone and resolver that will set CD bit? > > -- > wbr, Kirill > _______________________________________________ It's caused by DNS Cache poisoning (either intentionally, or unintentionally), from a recursive resolver that caches CD bit but does not zero it if a non dns-sec query hits that cached response. I see unbound also has a ticket open for this: https://github.com/NLnetLabs/unbound/issues/649 _______________________________________________ nginx mailing list nginx@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx