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