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 D360721F1EC for ; Wed, 23 Apr 2014 08:59:02 -0700 (PDT) Received: from [31.118.224.38] (helo=[192.168.150.151]) by bytemark.thekelleys.org.uk with esmtpa (Exim 4.80) (envelope-from ) id 1WczZS-0001Lt-Kt; Wed, 23 Apr 2014 15:58:51 +0000 Message-ID: <5357E336.6070406@thekelleys.org.uk> Date: Wed, 23 Apr 2014 16:58:46 +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: Dave Taht , Aaron Wood , dnsmasq-discuss References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 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: Wed, 23 Apr 2014 15:59:03 -0000 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 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.