> On 26 Jan 2023, at 19:00, Otto Moerbeek <o...@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 
> 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

Attachment: signature.asc
Description: Message signed with OpenPGP

Pdns-users mailing list

Reply via email to