[Cerowrt-devel] more dnssec failures

[Cerowrt-devel] more dnssec failures

[Aaron Wood]

[-- 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 --]

Re: [Cerowrt-devel] more dnssec failures

[Dave Taht]

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

Re: [Cerowrt-devel] [Dnsmasq-discuss] more dnssec failures

[Simon Kelley]

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.

Re: [Cerowrt-devel] [Dnsmasq-discuss] more dnssec failures

[Robert Bradley]

[-- 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 --]

Re: [Cerowrt-devel] [Dnsmasq-discuss] more dnssec failures

[Robert Bradley]

[-- 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 --]

Re: [Cerowrt-devel] [Dnsmasq-discuss] more dnssec failures

[Aaron Wood]

[-- 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 --]

Re: [Cerowrt-devel] [Dnsmasq-discuss] more dnssec failures

[Robert Bradley]

[-- 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 --]

Re: [Cerowrt-devel] [Dnsmasq-discuss] more dnssec failures

[Dave Taht]

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

Re: [Cerowrt-devel] [Dnsmasq-discuss] more dnssec failures

[Simon Kelley]

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
>>
> 
> 
> 

Re: [Cerowrt-devel] [Dnsmasq-discuss] more dnssec failures

[Aaron Wood]

[-- 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 --]

Re: [Cerowrt-devel] [Dnsmasq-discuss] more dnssec failures

[Simon Kelley]

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.

Re: [Cerowrt-devel] [Dnsmasq-discuss] more dnssec failures

[Aaron Wood]

[-- 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 --]

Re: [Cerowrt-devel] [Dnsmasq-discuss] more dnssec failures

[Dave Taht]

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