From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 8663F21F297 for ; Thu, 24 Apr 2014 09:03:51 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id r20so1345833wiv.3 for ; Thu, 24 Apr 2014 09:03:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=FWFWFy14VtakIrHkr7St+YokripTSmvVWjh/p3SK6wY=; b=ty5yM5DTxRdvnVPC14KILxM4BQ5XTEm5zQ9TnI+iCGNVdYES43TSHbpUsn2gIrdXBL 3esCxt/gTBMgx1RypXcjo1UgXD2jnb0bN6T3gVlaE4z4oxz6wlvKF/wMDo725U79N/WH WdtGvn7GdEEEi9yzRIvvkbEX211mskluqeNdKteyVzDupc5JHL3iDs6n37Alg91DiEJj tatWQHwf9CdBfEP5N1vVT1l1OGr4w20RqLels6X+RfAy2Jn1QYgGbbSRvkckwxhsA/mP Q/2Y6hskaZOW3mJ/ft/t5/5F9i74H3sZXkFAR4EKiTonlEMK2L17aDQZCLSyrdoAH+Te aoRA== MIME-Version: 1.0 X-Received: by 10.180.37.178 with SMTP id z18mr7234685wij.46.1398355429587; Thu, 24 Apr 2014 09:03:49 -0700 (PDT) Received: by 10.216.207.82 with HTTP; Thu, 24 Apr 2014 09:03:49 -0700 (PDT) In-Reply-To: References: <5357E336.6070406@thekelleys.org.uk> <5358F53A.3050501@thekelleys.org.uk> Date: Thu, 24 Apr 2014 09:03:49 -0700 Message-ID: From: Dave Taht To: Aaron Wood Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 16:03:52 -0000 What does unbound or bind do? On Thu, Apr 24, 2014 at 5:35 AM, Aaron Wood 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 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 >> wrote: >>> >>> On 24/04/14 11:49, Aaron Wood wrote: >>> >>> > >>> >> Dnsmasq does the DS query next because the answer to the A query com= es >>> >> back unsigned, so dnsmasq is looking for a DS record that proves thi= s >>> >> 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 t= he >>> >> broken DS, whilst dnsmasq does. >>> >> >>> >> That's as good an analysis as I can produce right now. Anyone who ca= n >>> >> 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 lik= e >>> > 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 SERVFAI= L >>> 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. >>> >>> >>> >> > --=20 Dave T=C3=A4ht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_= indecent.article