Scott Nicholas scott.nicholas at scottn.us
Fri Sep 11 12:05:59 UTC 2020

I was hoping someone's experience could save me as I've spent too much time
down this rabbit hole.

Primary nameserver is behind a cache/proxy on enterprise network such that
all external traffic hits this. Zone went bogus. I blame policy but on
further inspection 2/3 proxys had differing TTL between the DNSKEY and it's

I dove into RFC but not yet the code. I believe any security aware system
would throw out the DNSKEY with the RRSIG.

I suspect that the signature hit the absolute time, got a fresh copy, and
the DNSKEY stuck around another 2 days (1 week TTL). Now if the system
wasn't security aware, I'm not sure how the TTL became unmatched but I can
see that it could happen. I guess?

The questions

- is this system broken?
- can I work around it with creative policy / TTL
- can explain other cases these can get unmatched TTL?

A low TTL would minimize it but appliance doesn't allow direct
configuration for DNSKEY TTL.

Thanks for your input
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20200911/b683e9ec/attachment.htm>

More information about the bind-users mailing list