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.
>>
>>
>>
>>
>
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
