Strange DNSsec failure [was incorrectly sent Thursday night]

Mark Elkins mje at posix.co.za
Sat Apr 13 07:02:20 UTC 2019


Works fine for me?     - unless its been fixed in  the meantime. This is 
stock standard bind. Nothing funny at all on both the query machine and 
the DNSSEC aware resolver. Both run the same version of BIND.

$ dig  mx1.comcast.net

; <<>> DiG 9.12.3-P4 <<>> mx1.comcast.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12395
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 02a3b8dbc350ae44457cdec05cb1874ac246b4103d9a2461 (good)
;; QUESTION SECTION:
;mx1.comcast.net.        IN    A

;; ANSWER SECTION:
mx1.comcast.net.    300    IN    A    96.114.157.80

;; Query time: 244 msec
;; SERVER: 192.96.24.72#53(192.96.24.72)
;; WHEN: Sat Apr 13 08:52:58 SAST 2019
;; MSG SIZE  rcvd: 88

You can see from the query time this was a fresh lookup and not cached.

On 2019/04/13 04:59, frnkblk at iname.com wrote:
> 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
>
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-- 
Mark James ELKINS  -  Posix Systems - (South) Africa
mje at posix.co.za       Tel: +27.128070590  Cell: +27.826010496
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za



More information about the bind-users mailing list