Strange DNSsec failure [was incorrectly sent Thursday night]

frnkblk at frnkblk at
Sat Apr 13 02:59:34 UTC 2019

I've had DNSsec validation on our non-public resolvers for a year or two --
virtually no issues ... until Thursday.  First hint was that I couldn't get
the AAAA for  Later in the day our monitoring system
alerted me to email in our outbound queue that could not deliver to

If I perform a dig with DNSsec validation turned off then I can resolve
Comcast's FQDNs.  Here are their two MX records:

mail1:~# dig +cd @ +short
mail1:~# dig +cd @ +short
mail1:~# dig @ | grep status
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 21243
mail1:~# dig @ | grep status
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 18695

Not sure why five of our DNSSec-validating DNS servers are choking on domains.  If I flush the cache or restart the server it works
until the resource record counts down to zero, after which I get a SERVFAIL.

Problem ones: BIND 9.8.4-rpz2+rl005.12-P1 (on Debian, Debian package).
Working one: BIND 9.11.0-P2 <id:9713922>

Any ideas?

None of the public resolvers I regularly test against (Google, OpenDNS,
Quaad9) are having any issues with the Comcast FQDNs that I tested.

None of the other signed zones that our monitoring system uses
(,, have
an issue.


More information about the bind-users mailing list