Strange DNSsec failure [was incorrectly sent Thursday night]

[frnkblk at iname.com]

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 dns.comcast.net.  Later in the day our monitoring system
alerted me to email in our outbound queue that could not deliver to
comcast.net.

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 mx1.comcast.net @127.0.0.1 +short
96.114.157.80
mail1:~# dig +cd mx2.comcast.net @127.0.0.1 +short
68.87.20.5
mail1:~# dig  mx1.comcast.net @127.0.0.1 | grep status
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 21243
mail1:~# dig  mx2.comcast.net @127.0.0.1 | grep status
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 18695
mail1:~#

Not sure why five of our DNSSec-validating DNS servers are choking on
comcast.net 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
(www.dnssec-or-not.net, dnssec-name-and-shame.com, www.opendnssec.org) have
an issue.

Frank