From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bytemark.thekelleys.org.uk (bytemark.thekelleys.org.uk [IPv6:2001:41c8:51:46b:feff:ff:fe00:3310]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id E0F1321F27D for ; Thu, 24 Apr 2014 04:28:11 -0700 (PDT) Received: from [213.205.230.167] (helo=[192.168.150.151]) by bytemark.thekelleys.org.uk with esmtpa (Exim 4.80) (envelope-from ) id 1WdHoy-0003gK-QL; Thu, 24 Apr 2014 11:28:06 +0000 Message-ID: <5358F53A.3050501@thekelleys.org.uk> Date: Thu, 24 Apr 2014 12:27:54 +0100 From: Simon Kelley User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Aaron Wood References: <5357E336.6070406@thekelleys.org.uk> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: dnsmasq-discuss , cerowrt-devel Subject: Re: [Cerowrt-devel] [Dnsmasq-discuss] more dnssec failures X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 11:28:12 -0000 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.