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 9B57021F201 for ; Sat, 26 Apr 2014 12:45:14 -0700 (PDT) Received: from [213.205.230.227] (helo=[192.168.150.151]) by bytemark.thekelleys.org.uk with esmtpa (Exim 4.80) (envelope-from ) id 1We8X3-0002D3-NN; Sat, 26 Apr 2014 19:45:05 +0000 Message-ID: <535C0CB5.7070506@thekelleys.org.uk> Date: Sat, 26 Apr 2014 20:44:53 +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 , David Reed References: <1398528012.36628423@apps.rackspace.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dnsmasq-discuss , cerowrt-devel Subject: Re: [Cerowrt-devel] [Dnsmasq-discuss] Had to disable dnssec today 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: Sat, 26 Apr 2014 19:45:14 -0000 On 26/04/14 17:20, Aaron Wood wrote: > David, > > With two of them (akamai and cloudflare), I _think_ it's a dnsmasq > issue with the DS records for proving insecure domains are insecure. > But Simon Kelley would know that better than I. > The result of the analysis of the akamai domain was that there's a problem with the domain (ie it's an akamai problem) See the post in the Cerowrt list by Evan Hunt for the origin of this conclusion. There's a dnsmasq issue to the extent that dnsmasq uses a different strategy for proving that a name should not be signed than other nameservers (dnsmasq works bottom-up, the others can work top-down, since they are recursive servers, not forwarders.) This means that dnsmasq sees the akamai problem, whilst eg unbound happens not to. I plan to see if dnsmasq can be modified to improve this. I'm not sure of cloudflare has been looked at in detail, but my impression was that it's the same as akamai. > With BofA, I'm nearly certain it's them, or an issue with one of > their partners (since the domain that fails isn't BofA, but > something else): > > (with dnssec turned off): > > ;; QUESTION SECTION: ;sso-fi.bankofamerica.com. IN A > > ;; ANSWER SECTION: sso-fi.bankofamerica.com. 3599 IN CNAME > saml-bac.onefiserv.com. saml-bac.onefiserv.com. 299 IN CNAME > saml-bac.gslb.onefiserv.com. saml-bac.gslb.onefiserv.com. 119 IN A > 208.235.248.157 > > And it's the saml-bac.gslb.onefiserv.com host that's failing (see > here for debug info): > > http://dnssec-debugger.verisignlabs.com/sso-fi.bankofamerica.com > > -Aaron > > > On Sat, Apr 26, 2014 at 6:00 PM, wrote: > >> Is this just a dnsmasq issue or is the DNSSEC mechanism broken at >> these sites? If it is the latter, I can get attention from >> executives at some of these companies (Heartbleed has sensitized >> all kinds of companies to the need to strengthen security >> infrastructure). >> >> >> >> If the former, the change process is going to be more tricky, >> because dnsmasq is easily dismissed as too small a proportion of >> the market to care. (wish it were not so). >> Given it's less than a month since the first DNSSEC-capable dnsmasq release, anything other than small market share would be fairly miraculous! Cheers, Simon.