Strange DNSsec failure [was incorrectly sent Thursday night]

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Strange DNSsec failure [was incorrectly sent Thursday night]

frnkblk
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

RE: Strange DNSsec failure [was incorrectly sent Thursday night]

frnkblk
Just saw this posted on twitter, too, from this morning:
https://twitter.com/janger/status/1116738060199186432

Frank

-----Original Message-----
From: bind-users <[hidden email]> On Behalf Of
[hidden email]
Sent: Friday, April 12, 2019 10:00 PM
To: [hidden email]
Subject: Strange DNSsec failure [was incorrectly sent Thursday night]

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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

RE: RE: Strange DNSsec failure [was incorrectly sent Thursday night]

frnkblk
In reply to this post by frnkblk
And this forum post:
https://forums.xfinity.com/t5/Email-Web-Browsing/Unable-to-resolve-comcast-n
et-DNS/td-p/3213070

Frank

-----Original Message-----
From: bind-users <[hidden email]> On Behalf Of
[hidden email]
Sent: Friday, April 12, 2019 10:08 PM
To: [hidden email]
Subject: RE: Strange DNSsec failure [was incorrectly sent Thursday night]

Just saw this posted on twitter, too, from this morning:
https://twitter.com/janger/status/1116738060199186432

Frank

-----Original Message-----
From: bind-users <[hidden email]> On Behalf Of
[hidden email]
Sent: Friday, April 12, 2019 10:00 PM
To: [hidden email]
Subject: Strange DNSsec failure [was incorrectly sent Thursday night]

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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

RE: RE: Strange DNSsec failure [was incorrectly sent Thursday night]

frnkblk
In reply to this post by frnkblk
It looks like running with +trace results in a 15+ second timeout, whether
it's to the local resolver or Google, whether I specify IPv4 or not.


mail1:~# dig mx1.comcast.net +trace @127.0.0.1

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> mx1.comcast.net +trace @127.0.0.1
;; global options: +cmd
.                       433139  IN      NS      a.root-servers.net.
.                       433139  IN      NS      h.root-servers.net.
.                       433139  IN      NS      f.root-servers.net.
.                       433139  IN      NS      g.root-servers.net.
.                       433139  IN      NS      e.root-servers.net.
.                       433139  IN      NS      c.root-servers.net.
.                       433139  IN      NS      j.root-servers.net.
.                       433139  IN      NS      k.root-servers.net.
.                       433139  IN      NS      b.root-servers.net.
.                       433139  IN      NS      m.root-servers.net.
.                       433139  IN      NS      d.root-servers.net.
.                       433139  IN      NS      l.root-servers.net.
.                       433139  IN      NS      i.root-servers.net.
;; Received 508 bytes from 127.0.0.1#53(127.0.0.1) in 5 ms

net.                    172800  IN      NS      e.gtld-servers.net.
net.                    172800  IN      NS      d.gtld-servers.net.
net.                    172800  IN      NS      k.gtld-servers.net.
net.                    172800  IN      NS      c.gtld-servers.net.
net.                    172800  IN      NS      l.gtld-servers.net.
net.                    172800  IN      NS      i.gtld-servers.net.
net.                    172800  IN      NS      a.gtld-servers.net.
net.                    172800  IN      NS      b.gtld-servers.net.
net.                    172800  IN      NS      m.gtld-servers.net.
net.                    172800  IN      NS      f.gtld-servers.net.
net.                    172800  IN      NS      g.gtld-servers.net.
net.                    172800  IN      NS      h.gtld-servers.net.
net.                    172800  IN      NS      j.gtld-servers.net.
;; Received 490 bytes from 192.33.4.12#53(192.33.4.12) in 19 ms

comcast.net.            172800  IN      NS      dns101.comcast.net.
comcast.net.            172800  IN      NS      dns102.comcast.net.
comcast.net.            172800  IN      NS      dns103.comcast.net.
comcast.net.            172800  IN      NS      dns104.comcast.net.
comcast.net.            172800  IN      NS      dns105.comcast.net.
;; Received 358 bytes from 2001:500:d937::30#53(2001:500:d937::30) in 15255
ms

mx1.comcast.net.        300     IN      A       96.114.157.80
;; Received 49 bytes from 68.87.85.132#53(68.87.85.132) in 32 ms

mail1:~#

mail1:~# dig -4 mx1.comcast.net +trace @127.0.0.1

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> -4 mx1.comcast.net +trace @127.0.0.1
;; global options: +cmd
.                       433072  IN      NS      j.root-servers.net.
.                       433072  IN      NS      m.root-servers.net.
.                       433072  IN      NS      c.root-servers.net.
.                       433072  IN      NS      f.root-servers.net.
.                       433072  IN      NS      k.root-servers.net.
.                       433072  IN      NS      d.root-servers.net.
.                       433072  IN      NS      h.root-servers.net.
.                       433072  IN      NS      l.root-servers.net.
.                       433072  IN      NS      e.root-servers.net.
.                       433072  IN      NS      g.root-servers.net.
.                       433072  IN      NS      b.root-servers.net.
.                       433072  IN      NS      i.root-servers.net.
.                       433072  IN      NS      a.root-servers.net.
;; Received 508 bytes from 127.0.0.1#53(127.0.0.1) in 13 ms

net.                    172800  IN      NS      m.gtld-servers.net.
net.                    172800  IN      NS      e.gtld-servers.net.
net.                    172800  IN      NS      d.gtld-servers.net.
net.                    172800  IN      NS      j.gtld-servers.net.
net.                    172800  IN      NS      b.gtld-servers.net.
net.                    172800  IN      NS      a.gtld-servers.net.
net.                    172800  IN      NS      g.gtld-servers.net.
net.                    172800  IN      NS      k.gtld-servers.net.
net.                    172800  IN      NS      l.gtld-servers.net.
net.                    172800  IN      NS      c.gtld-servers.net.
net.                    172800  IN      NS      f.gtld-servers.net.
net.                    172800  IN      NS      h.gtld-servers.net.
net.                    172800  IN      NS      i.gtld-servers.net.
;; Received 490 bytes from 192.33.4.12#53(192.33.4.12) in 17 ms

comcast.net.            172800  IN      NS      dns101.comcast.net.
comcast.net.            172800  IN      NS      dns102.comcast.net.
comcast.net.            172800  IN      NS      dns103.comcast.net.
comcast.net.            172800  IN      NS      dns104.comcast.net.
comcast.net.            172800  IN      NS      dns105.comcast.net.
;; Received 358 bytes from 192.54.112.30#53(192.54.112.30) in 15264 ms

mx1.comcast.net.        300     IN      A       96.114.157.80
;; Received 49 bytes from 68.87.85.132#53(68.87.85.132) in 41 ms

mail1:~#

mail1:~# dig mx1.comcast.net +trace @8.8.8.8

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> mx1.comcast.net +trace @8.8.8.8
;; global options: +cmd
.                       168863  IN      NS      m.root-servers.net.
.                       168863  IN      NS      b.root-servers.net.
.                       168863  IN      NS      c.root-servers.net.
.                       168863  IN      NS      d.root-servers.net.
.                       168863  IN      NS      e.root-servers.net.
.                       168863  IN      NS      f.root-servers.net.
.                       168863  IN      NS      g.root-servers.net.
.                       168863  IN      NS      h.root-servers.net.
.                       168863  IN      NS      a.root-servers.net.
.                       168863  IN      NS      i.root-servers.net.
.                       168863  IN      NS      j.root-servers.net.
.                       168863  IN      NS      k.root-servers.net.
.                       168863  IN      NS      l.root-servers.net.
;; Received 228 bytes from 8.8.8.8#53(8.8.8.8) in 26 ms

net.                    172800  IN      NS      a.gtld-servers.net.
net.                    172800  IN      NS      b.gtld-servers.net.
net.                    172800  IN      NS      c.gtld-servers.net.
net.                    172800  IN      NS      d.gtld-servers.net.
net.                    172800  IN      NS      e.gtld-servers.net.
net.                    172800  IN      NS      f.gtld-servers.net.
net.                    172800  IN      NS      g.gtld-servers.net.
net.                    172800  IN      NS      h.gtld-servers.net.
net.                    172800  IN      NS      i.gtld-servers.net.
net.                    172800  IN      NS      j.gtld-servers.net.
net.                    172800  IN      NS      k.gtld-servers.net.
net.                    172800  IN      NS      l.gtld-servers.net.
net.                    172800  IN      NS      m.gtld-servers.net.
;; Received 490 bytes from 198.97.190.53#53(198.97.190.53) in 110 ms

comcast.net.            172800  IN      NS      dns101.comcast.net.
comcast.net.            172800  IN      NS      dns102.comcast.net.
comcast.net.            172800  IN      NS      dns103.comcast.net.
comcast.net.            172800  IN      NS      dns104.comcast.net.
comcast.net.            172800  IN      NS      dns105.comcast.net.
;; Received 358 bytes from 2001:500:d937::30#53(2001:500:d937::30) in 15268
ms

mx1.comcast.net.        300     IN      A       96.114.157.80
;; Received 49 bytes from
2001:558:100e:5:68:87:72:244#53(2001:558:100e:5:68:87:72:244) in 72 ms

mail1:~#



Frank

-----Original Message-----
From: bind-users <[hidden email]> On Behalf Of
[hidden email]
Sent: Friday, April 12, 2019 11:39 PM
To: [hidden email]
Subject: RE: Strange DNSsec failure [was incorrectly sent Thursday night]

And this forum post:
https://forums.xfinity.com/t5/Email-Web-Browsing/Unable-to-resolve-comcast-n
et-DNS/td-p/3213070

Frank

-----Original Message-----
From: bind-users <[hidden email]> On Behalf Of
[hidden email]
Sent: Friday, April 12, 2019 10:08 PM
To: [hidden email]
Subject: RE: Strange DNSsec failure [was incorrectly sent Thursday night]

Just saw this posted on twitter, too, from this morning:
https://twitter.com/janger/status/1116738060199186432

Frank

-----Original Message-----
From: bind-users <[hidden email]> On Behalf Of
[hidden email]
Sent: Friday, April 12, 2019 10:00 PM
To: [hidden email]
Subject: Strange DNSsec failure [was incorrectly sent Thursday night]

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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Strange DNSsec failure [was incorrectly sent Thursday night]

Mark Elkins
In reply to this post by frnkblk
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, [hidden email] 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
> [hidden email]
> https://lists.isc.org/mailman/listinfo/bind-users

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

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

RE: Strange DNSsec failure [was incorrectly sent Thursday night]

frnkblk
I'm wondering if it's been fixed ... I flushed the DNS cache on the problem servers again later this morning and now it's staying good, even after TTL.  We'll see if it stays that way.

Thanks,

Frank

-----Original Message-----
From: bind-users <[hidden email]> On Behalf Of Mark Elkins
Sent: Saturday, April 13, 2019 2:02 AM
To: [hidden email]
Subject: Re: Strange DNSsec failure [was incorrectly sent Thursday night]

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, [hidden email] 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
> [hidden email]
> https://lists.isc.org/mailman/listinfo/bind-users

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

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users