Ding-ding-ding -- issuing "rndc flushname ." did the trick, Mark.
I'd encourage this troubleshooting tip to be documented in one of those
how-to guides. I don't think waiting for a TTL is a good idea if most
queries are failing with "bad cache hit".
Frank
-Original Message-
From: Mark A
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 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.n
Just saw this posted on twitter, too, from this morning:
https://twitter.com/janger/status/1116738060199186432
Frank
-Original Message-
From: bind-users On Behalf Of
frnk...@iname.com
Sent: Friday, April 12, 2019 10:00 PM
To: bind-users@lists.isc.org
Subject: Strange DNSsec failure [was
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 On Behalf Of
frnk...@iname.com
Sent: Friday, April 12, 2019 10:08 PM
To: bind-users@lists.isc.org
Subject: RE: Strange DNSsec fa
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
.
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 On Behalf Of Mark Elkins
Sent: Saturday, April 13
6 matches
Mail list logo
