[Pdns-users] pdns_recursor issue

Otto Moerbeek otto at drijf.net
Fri Jan 27 06:40:41 UTC 2023


On Thu, Jan 26, 2023 at 10:57:21PM +0100, Arien Vijn wrote:

> 
> > On 26 Jan 2023, at 19:00, Otto Moerbeek <otto at drijf.net> wrote:
> 
> [...]
> 
> > I expect the aggressive cache workaround to function.
> 
> It seems so indeed.
> 
> > What is happening is that a query of a non-existent type (e.g. AAAA)
> > for xdsl-c-serviceweb.gslb.kpn.com <http://xdsl-c-serviceweb.gslb.kpn.com/>
> > 
> > $ dig @ns1gslb.kpn.com.  xdsl-c-serviceweb.gslb.kpn.com <http://xdsl-c-serviceweb.gslb.kpn.com/> aaaa +dnssec
> > 
> > produces an NSEC3 record that denies all types except TXT and RRSIG:
> > 
> > cq026lgcduus730qu6cbhtrt7qpr2jnu.gslb.kpn.com <http://cq026lgcduus730qu6cbhtrt7qpr2jnu.gslb.kpn.com/>. 86400 IN	NSEC3 1 0 1 19623DE58C1E7E40 CQ026LGCDUUS730QU6CBHTRT7QPR2JNV TXT RRSIG
> > 
> > So when the A record expires and somebody has done an AAAA query in
> > between, the aggressive cache concludes that the wanted A record  does
> > not exists and not even asks the auth for it.
> > 
> > The after a cache wipe it works because when the (aggressive) cache is
> > empty for that zone, there is also no NSEC3 record denying anything.
> > 
> > So in the end this is a misconfigured domain. Completely disabling the
> > aggressive cache is a bit of a big hammer, you can also add an NTA for
> > the specific problem domain, something like:
> > 
> > addNTA('gslb.kpn.com <http://gslb.kpn.com/>', 'Invalid NSEC3 record served for xdsl-c-serviceweb.gslb.kpn.com <http://xdsl-c-serviceweb.gslb.kpn.com/>')
> > 
> > in your Lua config file. This effectively does disable DNSSEC for the
> > domain. And please also report this to KPN.
> 
> Thanks for the explanation! This is really useful because KPN pointed to our DNS= servers.
> 
> We also saw this with other (KPN hosted) 'gslb-domains', which also show no trouble anymore after disabling the
> aggressive cache. So, if we go the NTA-way then I am afraid that we'll have to add a series of NTAs then :/
> 
> At any rate, I am really glad with this explanation. I hope that KPN, and the parties they outsourced their DNS service to, wil appreciate this too :)
> 
> -- Arien

This gives background information and a link to a remedy to be
employed on the load balancer side.

https://en.blog.nic.cz/2019/07/10/error-in-dnssec-implementation-on-f5-big-ip-load-balancers/

	-Otto





More information about the Pdns-users mailing list