* [Cerowrt-devel] more dnssec failures @ 2014-04-23 15:31 Aaron Wood 2014-04-23 15:42 ` Dave Taht 0 siblings, 1 reply; 13+ messages in thread From: Aaron Wood @ 2014-04-23 15:31 UTC (permalink / raw) To: cerowrt-devel [-- Attachment #1: Type: text/plain, Size: 995 bytes --] 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 [-- Attachment #2: Type: text/html, Size: 2844 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Cerowrt-devel] more dnssec failures 2014-04-23 15:31 [Cerowrt-devel] more dnssec failures Aaron Wood @ 2014-04-23 15:42 ` Dave Taht 2014-04-23 15:58 ` [Cerowrt-devel] [Dnsmasq-discuss] " Simon Kelley 0 siblings, 1 reply; 13+ messages in thread From: Dave Taht @ 2014-04-23 15:42 UTC (permalink / raw) To: Aaron Wood, dnsmasq-discuss; +Cc: cerowrt-devel 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 <woody77@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-devel@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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Cerowrt-devel] [Dnsmasq-discuss] more dnssec failures 2014-04-23 15:42 ` Dave Taht @ 2014-04-23 15:58 ` Simon Kelley 2014-04-23 16:44 ` Robert Bradley 2014-04-24 10:49 ` Aaron Wood 0 siblings, 2 replies; 13+ messages in thread From: Simon Kelley @ 2014-04-23 15:58 UTC (permalink / raw) To: Dave Taht, Aaron Wood, dnsmasq-discuss; +Cc: cerowrt-devel 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 <woody77@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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Cerowrt-devel] [Dnsmasq-discuss] more dnssec failures 2014-04-23 15:58 ` [Cerowrt-devel] [Dnsmasq-discuss] " Simon Kelley @ 2014-04-23 16:44 ` Robert Bradley 2014-04-23 17:16 ` Robert Bradley 2014-04-23 17:18 ` Aaron Wood 2014-04-24 10:49 ` Aaron Wood 1 sibling, 2 replies; 13+ messages in thread From: Robert Bradley @ 2014-04-23 16:44 UTC (permalink / raw) To: cerowrt-devel; +Cc: Dnsmasq-discuss [-- Attachment #1: Type: text/plain, Size: 2146 bytes --] On 23/04/2014 16:58, Simon Kelley wrote: > 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 <woody77@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 <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... -- Robert Bradley [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 899 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Cerowrt-devel] [Dnsmasq-discuss] more dnssec failures 2014-04-23 16:44 ` Robert Bradley @ 2014-04-23 17:16 ` Robert Bradley 2014-04-23 17:28 ` Robert Bradley 2014-04-23 17:18 ` Aaron Wood 1 sibling, 1 reply; 13+ messages in thread From: Robert Bradley @ 2014-04-23 17:16 UTC (permalink / raw) To: cerowrt-devel [-- Attachment #1: Type: text/plain, Size: 797 bytes --] On 23/04/2014 17:44, Robert Bradley wrote: > 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... Digging into this further, it looks like the issue occurs for domain names where an A record exists but a DS record does not. In the case where the A/AAAA record is non-existent, (e.g. dscc.akamaiedge.net.0.1.cn.akamaiedge.net. instead of e3191.<...> or non-existent.cloudflare.com), you get the expected NOERROR or NXDOMAIN response. It would be worth testing this on a non-dual-stacked host or a subdomain without related A/AAAA records too. -- Robert Bradley [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 899 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Cerowrt-devel] [Dnsmasq-discuss] more dnssec failures 2014-04-23 17:16 ` Robert Bradley @ 2014-04-23 17:28 ` Robert Bradley 0 siblings, 0 replies; 13+ messages in thread From: Robert Bradley @ 2014-04-23 17:28 UTC (permalink / raw) To: cerowrt-devel [-- Attachment #1: Type: text/plain, Size: 1024 bytes --] On 23/04/2014 18:16, Robert Bradley wrote: > On 23/04/2014 17:44, Robert Bradley wrote: >> 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... > Digging into this further, it looks like the issue occurs for domain > names where an A record exists but a DS record does not. In the case > where the A/AAAA record is non-existent, (e.g. > dscc.akamaiedge.net.0.1.cn.akamaiedge.net. instead of e3191.<...> or > non-existent.cloudflare.com), you get the expected NOERROR or NXDOMAIN > response. It would be worth testing this on a non-dual-stacked host or > a subdomain without related A/AAAA records too. Update 2: This seems like it may actually be IPv6related somehow! Testing with IPv4-only domains using Cloudflare for DNS did not seem to trigger the errors. -- Robert Bradley [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 899 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Cerowrt-devel] [Dnsmasq-discuss] more dnssec failures 2014-04-23 16:44 ` Robert Bradley 2014-04-23 17:16 ` Robert Bradley @ 2014-04-23 17:18 ` Aaron Wood 2014-04-23 17:29 ` Dave Taht 1 sibling, 1 reply; 13+ messages in thread From: Aaron Wood @ 2014-04-23 17:18 UTC (permalink / raw) To: Robert Bradley; +Cc: Dnsmasq-discuss, cerowrt-devel [-- Attachment #1: Type: text/plain, Size: 1079 bytes --] On Wed, Apr 23, 2014 at 6:44 PM, Robert Bradley <robert.bradley1@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? (I confess that I don't know the details of DNS very well) -Aaron [-- Attachment #2: Type: text/html, Size: 1987 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Cerowrt-devel] [Dnsmasq-discuss] more dnssec failures 2014-04-23 17:18 ` Aaron Wood @ 2014-04-23 17:29 ` Dave Taht 2014-04-23 19:04 ` Simon Kelley 0 siblings, 1 reply; 13+ messages in thread From: Dave Taht @ 2014-04-23 17:29 UTC (permalink / raw) To: Aaron Wood; +Cc: dnsmasq-discuss, cerowrt-devel On Wed, Apr 23, 2014 at 10:18 AM, Aaron Wood <woody77@gmail.com> wrote: > On Wed, Apr 23, 2014 at 6:44 PM, Robert Bradley <robert.bradley1@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. > > (I confess that I don't know the details of DNS very well) > > -Aaron > > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Cerowrt-devel] [Dnsmasq-discuss] more dnssec failures 2014-04-23 17:29 ` Dave Taht @ 2014-04-23 19:04 ` Simon Kelley 0 siblings, 0 replies; 13+ messages in thread From: Simon Kelley @ 2014-04-23 19:04 UTC (permalink / raw) To: Dave Taht, Aaron Wood; +Cc: dnsmasq-discuss, cerowrt-devel On 23/04/14 18:29, Dave Taht wrote: > On Wed, Apr 23, 2014 at 10:18 AM, Aaron Wood <woody77@gmail.com> wrote: >> On Wed, Apr 23, 2014 at 6:44 PM, Robert Bradley <robert.bradley1@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-devel@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cerowrt-devel >> > > > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Cerowrt-devel] [Dnsmasq-discuss] more dnssec failures 2014-04-23 15:58 ` [Cerowrt-devel] [Dnsmasq-discuss] " Simon Kelley 2014-04-23 16:44 ` Robert Bradley @ 2014-04-24 10:49 ` Aaron Wood 2014-04-24 11:27 ` Simon Kelley 1 sibling, 1 reply; 13+ messages in thread From: Aaron Wood @ 2014-04-24 10:49 UTC (permalink / raw) To: Simon Kelley; +Cc: dnsmasq-discuss, cerowrt-devel [-- Attachment #1: Type: text/plain, Size: 2264 bytes --] On Wed, Apr 23, 2014 at 5:58 PM, Simon Kelley <simon@thekelleys.org.uk>wrote: > 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 <woody77@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 [-- Attachment #2: Type: text/html, Size: 4090 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Cerowrt-devel] [Dnsmasq-discuss] more dnssec failures 2014-04-24 10:49 ` Aaron Wood @ 2014-04-24 11:27 ` Simon Kelley 2014-04-24 12:33 ` Aaron Wood 0 siblings, 1 reply; 13+ messages in thread From: Simon Kelley @ 2014-04-24 11:27 UTC (permalink / raw) To: Aaron Wood; +Cc: dnsmasq-discuss, cerowrt-devel 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Cerowrt-devel] [Dnsmasq-discuss] more dnssec failures 2014-04-24 11:27 ` Simon Kelley @ 2014-04-24 12:33 ` Aaron Wood [not found] ` <CALQXh-O4puZOB710+R2CcY3AEqTZhAJvU8YFsjjH3_xK1CdXvA@mail.gmail.com> 0 siblings, 1 reply; 13+ messages in thread From: Aaron Wood @ 2014-04-24 12:33 UTC (permalink / raw) To: Simon Kelley; +Cc: dnsmasq-discuss, cerowrt-devel [-- Attachment #1: Type: text/plain, Size: 2683 bytes --] 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 <simon@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. > > > > [-- Attachment #2: Type: text/html, Size: 4986 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <CALQXh-O4puZOB710+R2CcY3AEqTZhAJvU8YFsjjH3_xK1CdXvA@mail.gmail.com>]
* Re: [Cerowrt-devel] [Dnsmasq-discuss] more dnssec failures [not found] ` <CALQXh-O4puZOB710+R2CcY3AEqTZhAJvU8YFsjjH3_xK1CdXvA@mail.gmail.com> @ 2014-04-24 16:03 ` Dave Taht 0 siblings, 0 replies; 13+ messages in thread From: Dave Taht @ 2014-04-24 16:03 UTC (permalink / raw) To: Aaron Wood; +Cc: dnsmasq-discuss, cerowrt-devel What does unbound or bind do? On Thu, Apr 24, 2014 at 5:35 AM, Aaron Wood <woody77@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 <woody77@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 <simon@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 ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2014-04-24 16:03 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-04-23 15:31 [Cerowrt-devel] more dnssec failures Aaron Wood
2014-04-23 15:42 ` Dave Taht
2014-04-23 15:58 ` [Cerowrt-devel] [Dnsmasq-discuss] " Simon Kelley
2014-04-23 16:44 ` Robert Bradley
2014-04-23 17:16 ` Robert Bradley
2014-04-23 17:28 ` Robert Bradley
2014-04-23 17:18 ` Aaron Wood
2014-04-23 17:29 ` Dave Taht
2014-04-23 19:04 ` Simon Kelley
2014-04-24 10:49 ` Aaron Wood
2014-04-24 11:27 ` Simon Kelley
2014-04-24 12:33 ` Aaron Wood
[not found] ` <CALQXh-O4puZOB710+R2CcY3AEqTZhAJvU8YFsjjH3_xK1CdXvA@mail.gmail.com>
2014-04-24 16:03 ` Dave Taht
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox