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

Aaron Wood woody77 at gmail.com
Thu Apr 24 08:33:20 EDT 2014


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.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20140424/bee76ef5/attachment-0002.html>


More information about the Cerowrt-devel mailing list