Re: [Dnsmasq-discuss] [Cerowrt-devel] more dnssec failures
On Wed, Apr 23, 2014 at 5:58 PM, Simon Kelley si...@thekelleys.org.ukwrote: On 23/04/14 16:42, Dave Taht wrote: I will argue that a better place to report dnssec validation errors is the dnsmasq list. On Wed, Apr 23, 2014 at 8:31 AM, Aaron Wood wood...@gmail.com wrote: Wed Apr 23 15:13:05 2014 daemon.info dnsmasq[29719]: query[A] e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net from 172.30.42.99 Wed Apr 23 15:13:05 2014 daemon.info dnsmasq[29719]: forwarded e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net to 8.8.8.8 Wed Apr 23 15:13:05 2014 daemon.info dnsmasq[29719]: dnssec-query[DS] e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net to 8.8.8.8 Wed Apr 23 15:13:05 2014 daemon.info dnsmasq[29719]: forwarded e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net to 8.8.4.4 Wed Apr 23 15:13:05 2014 daemon.info dnsmasq[29719]: forwarded e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net to 8.8.8.8 Wed Apr 23 15:13:05 2014 daemon.info dnsmasq[29719]: reply e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net is BOGUS DS Wed Apr 23 15:13:05 2014 daemon.info dnsmasq[29719]: validation result is BOGUS Wed Apr 23 15:13:05 2014 daemon.info dnsmasq[29719]: reply e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net is 2.20.28.186 This one validates via verisign, however. Something strange in that domain. Turning off DNSSEC with the checking-disabled bit, the original A-record query is OK Dnsmasq does the DS query next because the answer to the A query comes back unsigned, so dnsmasq is looking for a DS record that proves this is OK. It's likely that Verisign does that top-down (starting from the root) whilst dnsmasq does it bottom up. Hence Verisign never finds the broken DS, whilst dnsmasq does. That's as good an analysis as I can produce right now. Anyone who can shed more light, please do. (And yes, please report DNSSEC problems on the dnsmasq-discuss list for preference.) This is still persisting (and it appears to be blocking a bunch of Apple software update functions). From your comments, Simon, it sounds like you think this is an Akamai issue, and should be reported to them? Thanks, Aaron ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [Cerowrt-devel] more dnssec failures
On 24/04/14 11:49, Aaron Wood wrote:
Dnsmasq does the DS query next because the answer to the A query comes
back unsigned, so dnsmasq is looking for a DS record that proves this is
OK. It's likely that Verisign does that top-down (starting from the
root) whilst dnsmasq does it bottom up. Hence Verisign never finds the
broken DS, whilst dnsmasq does.
That's as good an analysis as I can produce right now. Anyone who can
shed more light, please do.
(And yes, please report DNSSEC problems on the dnsmasq-discuss list for
preference.)
This is still persisting (and it appears to be blocking a bunch of Apple
software update functions). From your comments, Simon, it sounds like you
think this is an Akamai issue, and should be reported to them?
I'm not absolutely sure that this isn't also a dnsmasq problem, and
DNSSEC is still capable of surprising me, but I can't see how a SERVFAIL
answer to
dig @8.8.8.8 DS e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net
can not be either a Google ('cause it's their recursive server) or
Akamai problem.
Poking further, it looks like the authoritative name servers for that
zone are
; DiG 9.8.1-P1 @8.8.8.8 NS cn.akamaiedge.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 43031
;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;cn.akamaiedge.net. IN NS
;; ANSWER SECTION:
cn.akamaiedge.net. 299 IN NS n7cn.akamaiedge.net.
cn.akamaiedge.net. 299 IN NS n6cn.akamaiedge.net.
cn.akamaiedge.net. 299 IN NS n0cn.akamaiedge.net.
cn.akamaiedge.net. 299 IN NS n2cn.akamaiedge.net.
cn.akamaiedge.net. 299 IN NS n5cn.akamaiedge.net.
cn.akamaiedge.net. 299 IN NS n4cn.akamaiedge.net.
cn.akamaiedge.net. 299 IN NS n3cn.akamaiedge.net.
cn.akamaiedge.net. 299 IN NS n1cn.akamaiedge.net.
cn.akamaiedge.net. 299 IN NS n8cn.akamaiedge.net.
and all of those give sensible answers for
DS e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net
except n8cn.akamaiedge.net, which isn't responding, so I rather think
this may be a Google mess.
Or maybe it's Great Firewall induced breakage?
Cheers,
Simon.
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [Cerowrt-devel] more dnssec failures
Well, I'm seeing the same results as you are from here in Paris (using
Free.fr).
-Aaron
On Thu, Apr 24, 2014 at 1:27 PM, Simon Kelley si...@thekelleys.org.ukwrote:
On 24/04/14 11:49, Aaron Wood wrote:
Dnsmasq does the DS query next because the answer to the A query comes
back unsigned, so dnsmasq is looking for a DS record that proves this is
OK. It's likely that Verisign does that top-down (starting from the
root) whilst dnsmasq does it bottom up. Hence Verisign never finds the
broken DS, whilst dnsmasq does.
That's as good an analysis as I can produce right now. Anyone who can
shed more light, please do.
(And yes, please report DNSSEC problems on the dnsmasq-discuss list for
preference.)
This is still persisting (and it appears to be blocking a bunch of Apple
software update functions). From your comments, Simon, it sounds like
you
think this is an Akamai issue, and should be reported to them?
I'm not absolutely sure that this isn't also a dnsmasq problem, and
DNSSEC is still capable of surprising me, but I can't see how a SERVFAIL
answer to
dig @8.8.8.8 DS e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net
can not be either a Google ('cause it's their recursive server) or
Akamai problem.
Poking further, it looks like the authoritative name servers for that
zone are
; DiG 9.8.1-P1 @8.8.8.8 NS cn.akamaiedge.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 43031
;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;cn.akamaiedge.net. IN NS
;; ANSWER SECTION:
cn.akamaiedge.net. 299 IN NS n7cn.akamaiedge.net.
cn.akamaiedge.net. 299 IN NS n6cn.akamaiedge.net.
cn.akamaiedge.net. 299 IN NS n0cn.akamaiedge.net.
cn.akamaiedge.net. 299 IN NS n2cn.akamaiedge.net.
cn.akamaiedge.net. 299 IN NS n5cn.akamaiedge.net.
cn.akamaiedge.net. 299 IN NS n4cn.akamaiedge.net.
cn.akamaiedge.net. 299 IN NS n3cn.akamaiedge.net.
cn.akamaiedge.net. 299 IN NS n1cn.akamaiedge.net.
cn.akamaiedge.net. 299 IN NS n8cn.akamaiedge.net.
and all of those give sensible answers for
DS e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net
except n8cn.akamaiedge.net, which isn't responding, so I rather think
this may be a Google mess.
Or maybe it's Great Firewall induced breakage?
Cheers,
Simon.
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [Cerowrt-devel] more dnssec failures
And if I use Free.fr's servers, the DS resolves (I'm running CeroWRT
double-NAT behind a Freebox v6):
dig @192.168.1.254 DS e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net
; DiG 9.8.5-P1 @192.168.1.254 DS
e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 11369
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net. IN DS
;; AUTHORITY SECTION:
cn.akamaiedge.net. 1800 IN SOA n0cn.akamaiedge.net. hostmaster.akamai.com.
1398342840 1000 1000 1000 1800
;; Query time: 39 msec
;; SERVER: 192.168.1.254#53(192.168.1.254)
;; WHEN: Thu Apr 24 14:34:00 CEST 2014
;; MSG SIZE rcvd: 127
-Aaron
On Thu, Apr 24, 2014 at 2:33 PM, Aaron Wood wood...@gmail.com wrote:
Well, I'm seeing the same results as you are from here in Paris (using
Free.fr).
-Aaron
On Thu, Apr 24, 2014 at 1:27 PM, Simon Kelley si...@thekelleys.org.ukwrote:
On 24/04/14 11:49, Aaron Wood wrote:
Dnsmasq does the DS query next because the answer to the A query comes
back unsigned, so dnsmasq is looking for a DS record that proves this
is
OK. It's likely that Verisign does that top-down (starting from the
root) whilst dnsmasq does it bottom up. Hence Verisign never finds the
broken DS, whilst dnsmasq does.
That's as good an analysis as I can produce right now. Anyone who can
shed more light, please do.
(And yes, please report DNSSEC problems on the dnsmasq-discuss list
for
preference.)
This is still persisting (and it appears to be blocking a bunch of Apple
software update functions). From your comments, Simon, it sounds like
you
think this is an Akamai issue, and should be reported to them?
I'm not absolutely sure that this isn't also a dnsmasq problem, and
DNSSEC is still capable of surprising me, but I can't see how a SERVFAIL
answer to
dig @8.8.8.8 DS e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net
can not be either a Google ('cause it's their recursive server) or
Akamai problem.
Poking further, it looks like the authoritative name servers for that
zone are
; DiG 9.8.1-P1 @8.8.8.8 NS cn.akamaiedge.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 43031
;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;cn.akamaiedge.net. IN NS
;; ANSWER SECTION:
cn.akamaiedge.net. 299 IN NS n7cn.akamaiedge.net.
cn.akamaiedge.net. 299 IN NS n6cn.akamaiedge.net.
cn.akamaiedge.net. 299 IN NS n0cn.akamaiedge.net.
cn.akamaiedge.net. 299 IN NS n2cn.akamaiedge.net.
cn.akamaiedge.net. 299 IN NS n5cn.akamaiedge.net.
cn.akamaiedge.net. 299 IN NS n4cn.akamaiedge.net.
cn.akamaiedge.net. 299 IN NS n3cn.akamaiedge.net.
cn.akamaiedge.net. 299 IN NS n1cn.akamaiedge.net.
cn.akamaiedge.net. 299 IN NS n8cn.akamaiedge.net.
and all of those give sensible answers for
DS e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net
except n8cn.akamaiedge.net, which isn't responding, so I rather think
this may be a Google mess.
Or maybe it's Great Firewall induced breakage?
Cheers,
Simon.
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [Cerowrt-devel] more dnssec failures
What does unbound or bind do?
On Thu, Apr 24, 2014 at 5:35 AM, Aaron Wood wood...@gmail.com wrote:
And if I use Free.fr's servers, the DS resolves (I'm running CeroWRT
double-NAT behind a Freebox v6):
dig @192.168.1.254 DS e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net
; DiG 9.8.5-P1 @192.168.1.254 DS
e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 11369
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net. IN DS
;; AUTHORITY SECTION:
cn.akamaiedge.net. 1800 IN SOA n0cn.akamaiedge.net. hostmaster.akamai.com.
1398342840 1000 1000 1000 1800
;; Query time: 39 msec
;; SERVER: 192.168.1.254#53(192.168.1.254)
;; WHEN: Thu Apr 24 14:34:00 CEST 2014
;; MSG SIZE rcvd: 127
-Aaron
On Thu, Apr 24, 2014 at 2:33 PM, Aaron Wood wood...@gmail.com wrote:
Well, I'm seeing the same results as you are from here in Paris (using
Free.fr).
-Aaron
On Thu, Apr 24, 2014 at 1:27 PM, Simon Kelley si...@thekelleys.org.uk
wrote:
On 24/04/14 11:49, Aaron Wood wrote:
Dnsmasq does the DS query next because the answer to the A query comes
back unsigned, so dnsmasq is looking for a DS record that proves this
is
OK. It's likely that Verisign does that top-down (starting from the
root) whilst dnsmasq does it bottom up. Hence Verisign never finds the
broken DS, whilst dnsmasq does.
That's as good an analysis as I can produce right now. Anyone who can
shed more light, please do.
(And yes, please report DNSSEC problems on the dnsmasq-discuss list
for
preference.)
This is still persisting (and it appears to be blocking a bunch of
Apple
software update functions). From your comments, Simon, it sounds like
you
think this is an Akamai issue, and should be reported to them?
I'm not absolutely sure that this isn't also a dnsmasq problem, and
DNSSEC is still capable of surprising me, but I can't see how a SERVFAIL
answer to
dig @8.8.8.8 DS e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net
can not be either a Google ('cause it's their recursive server) or
Akamai problem.
Poking further, it looks like the authoritative name servers for that
zone are
; DiG 9.8.1-P1 @8.8.8.8 NS cn.akamaiedge.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 43031
;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;cn.akamaiedge.net. IN NS
;; ANSWER SECTION:
cn.akamaiedge.net. 299 IN NS n7cn.akamaiedge.net.
cn.akamaiedge.net. 299 IN NS n6cn.akamaiedge.net.
cn.akamaiedge.net. 299 IN NS n0cn.akamaiedge.net.
cn.akamaiedge.net. 299 IN NS n2cn.akamaiedge.net.
cn.akamaiedge.net. 299 IN NS n5cn.akamaiedge.net.
cn.akamaiedge.net. 299 IN NS n4cn.akamaiedge.net.
cn.akamaiedge.net. 299 IN NS n3cn.akamaiedge.net.
cn.akamaiedge.net. 299 IN NS n1cn.akamaiedge.net.
cn.akamaiedge.net. 299 IN NS n8cn.akamaiedge.net.
and all of those give sensible answers for
DS e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net
except n8cn.akamaiedge.net, which isn't responding, so I rather think
this may be a Google mess.
Or maybe it's Great Firewall induced breakage?
Cheers,
Simon.
--
Dave Täht
NSFW:
https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [Cerowrt-devel] more dnssec failures
I will argue that a better place to report dnssec validation errors is the dnsmasq list. On Wed, Apr 23, 2014 at 8:31 AM, Aaron Wood wood...@gmail.com wrote: Wed Apr 23 15:13:05 2014 daemon.info dnsmasq[29719]: query[A] e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net from 172.30.42.99 Wed Apr 23 15:13:05 2014 daemon.info dnsmasq[29719]: forwarded e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net to 8.8.8.8 Wed Apr 23 15:13:05 2014 daemon.info dnsmasq[29719]: dnssec-query[DS] e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net to 8.8.8.8 Wed Apr 23 15:13:05 2014 daemon.info dnsmasq[29719]: forwarded e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net to 8.8.4.4 Wed Apr 23 15:13:05 2014 daemon.info dnsmasq[29719]: forwarded e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net to 8.8.8.8 Wed Apr 23 15:13:05 2014 daemon.info dnsmasq[29719]: reply e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net is BOGUS DS Wed Apr 23 15:13:05 2014 daemon.info dnsmasq[29719]: validation result is BOGUS Wed Apr 23 15:13:05 2014 daemon.info dnsmasq[29719]: reply e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net is 2.20.28.186 This one validates via verisign, however. -Aaron ___ Cerowrt-devel mailing list cerowrt-de...@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel -- Dave Täht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [Cerowrt-devel] more dnssec failures
On 23/04/14 16:42, Dave Taht wrote: I will argue that a better place to report dnssec validation errors is the dnsmasq list. On Wed, Apr 23, 2014 at 8:31 AM, Aaron Wood wood...@gmail.com wrote: Wed Apr 23 15:13:05 2014 daemon.info dnsmasq[29719]: query[A] e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net from 172.30.42.99 Wed Apr 23 15:13:05 2014 daemon.info dnsmasq[29719]: forwarded e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net to 8.8.8.8 Wed Apr 23 15:13:05 2014 daemon.info dnsmasq[29719]: dnssec-query[DS] e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net to 8.8.8.8 Wed Apr 23 15:13:05 2014 daemon.info dnsmasq[29719]: forwarded e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net to 8.8.4.4 Wed Apr 23 15:13:05 2014 daemon.info dnsmasq[29719]: forwarded e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net to 8.8.8.8 Wed Apr 23 15:13:05 2014 daemon.info dnsmasq[29719]: reply e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net is BOGUS DS Wed Apr 23 15:13:05 2014 daemon.info dnsmasq[29719]: validation result is BOGUS Wed Apr 23 15:13:05 2014 daemon.info dnsmasq[29719]: reply e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net is 2.20.28.186 This one validates via verisign, however. Something strange in that domain. Turning off DNSSEC with the checking-disabled bit, the original A-record query is OK ; DiG 9.8.1-P1 +cd @8.8.8.8 a e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 45416 ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net. IN A ;; ANSWER SECTION: e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net. 19 IN A 23.195.61.15 ;; Query time: 112 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Wed Apr 23 16:52:06 2014 ;; MSG SIZE rcvd: 81 But a query for DS on the same domain, which is what dnsmasq does next, returns SERVFAIL, _even_with_ checking disabled. ; DiG 9.8.1-P1 +cd @8.8.8.8 ds e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 44148 ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net. IN DS ;; Query time: 149 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Wed Apr 23 16:52:30 2014 ;; MSG SIZE rcvd: 65 Dnsmasq does the DS query next because the answer to the A query comes back unsigned, so dnsmasq is looking for a DS record that proves this is OK. It's likely that Verisign does that top-down (starting from the root) whilst dnsmasq does it bottom up. Hence Verisign never finds the broken DS, whilst dnsmasq does. That's as good an analysis as I can produce right now. Anyone who can shed more light, please do. (And yes, please report DNSSEC problems on the dnsmasq-discuss list for preference.) Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [Cerowrt-devel] more dnssec failures
On 23/04/14 18:29, Dave Taht wrote: On Wed, Apr 23, 2014 at 10:18 AM, Aaron Wood wood...@gmail.com wrote: On Wed, Apr 23, 2014 at 6:44 PM, Robert Bradley robert.bradl...@gmail.com wrote: ; DiG 9.8.1-P1 +cd @8.8.8.8 a e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net snip rest of NOERROR response But a query for DS on the same domain, which is what dnsmasq does next, returns SERVFAIL, _even_with_ checking disabled. ; DiG 9.8.1-P1 +cd @8.8.8.8 ds e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net snip SERVFAIL response This looks identical to the *.cloudflare.com issue I had last week. In both cases, using Level 3's 4.2.2.2 instead of Google DNS works fine, and 8.8.8.8 returns SERVFAIL for DS lookups. This looks like a bug in Google's DNS servers as opposed to dnsmasq... A question about dnsmasq and multiple servers. If I listed both 4.2.2.2 and 8.8.8.8 in my dnsmasq configuration, how would dnsmasq behave in this case? would it query both for the DS? or just stick with the first server to start responding with an A-record? By default dnsmasq probes for a best upstream dns server periodically and uses that. subsequent queries needed to do DNSSEC validation of an initial answer are always sent to the same server which provided that answer. Simon. (I confess that I don't know the details of DNS very well) -Aaron ___ Cerowrt-devel mailing list cerowrt-de...@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
