From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (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 AE0B021F568 for ; Thu, 8 Jan 2015 09:44:01 -0800 (PST) Received: by mail-ob0-f171.google.com with SMTP id uz6so9289984obc.2 for ; Thu, 08 Jan 2015 09:44:00 -0800 (PST) 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=9zXBeNBZmy5Un4yun/SEJ89QiiJTy0fmjgFNwmlE6J8=; b=ej5HEWwbHKxdgNb+vZXnkviy8Vlbkh5MrTUHEFIz4DTFW84nVRJ/WjwnfgAu4RoUbf 6d+urHpc1mu2DiaoUyQj6uJmnjimBt+CIiNPppErd8VG9S017l8pkwZfjaJhaPNq/alt wNYyY7S58mi199zx2oubTSmyMg5WuCKlpk/sooNktx2GGnFzgu7SEdpY1EHy5aZP5LPm xa+WAeNEekF3PIzcpVSvPhHCJ5ICtaWw7hGvkN9l1ytPjG5pVEjZCMF3k1JqogwOgNcB r2ZSF4sHyGSeX4MjaZjFVVVGXxKBANq8zXQA8v8KvX6SVMrKzkQrR3fCz/suuxw0REVz DWpw== MIME-Version: 1.0 X-Received: by 10.202.215.212 with SMTP id o203mr6044891oig.85.1420739040223; Thu, 08 Jan 2015 09:44:00 -0800 (PST) Received: by 10.202.169.209 with HTTP; Thu, 8 Jan 2015 09:44:00 -0800 (PST) In-Reply-To: <54AEB183.7050000@thekelleys.org.uk> References: <535EACCB.7090104@thekelleys.org.uk> <20140428232459.GA55372@redoubt.spodhuis.org> <535FA793.8020502@thekelleys.org.uk> <542E6C43.9030002@mit.edu> <54AEB183.7050000@thekelleys.org.uk> Date: Thu, 8 Jan 2015 09:44:00 -0800 Message-ID: From: Dave Taht To: Simon Kelley Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: dnsmasq-discuss , "cerowrt-devel@lists.bufferbloat.net" , Anders Kaseorg Subject: Re: [Cerowrt-devel] Problems with DNSsec on Comcast, with Cero 3.10.38-1/DNSmasq 4-26-2014 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, 08 Jan 2015 17:44:29 -0000 Wow, this thread goes back a ways. Is ds.test-ipv6.com still configured wrong, and does it pass now? It passes for me (but I am behind a more modern openwrt box right now) Is there another site that demonstrates this problem? BTW: For a while there (on comcast), in production, I ran with pure ipv6 for dns (it reduced ipv4 nat pressure significantly!), but it hung after a few days and I never got back to it. Were any problems like this experienced and/or fixed for dnsmasq in the past 8 months or so? Anyway... enough incremental fixes have landed all across the board in openwrt, and the chaos calmer process seems to have settled down enough, to consider doing an entirely updated cerowrt based on 3.14 and pushing things like dnsmasq further forward... ... but I, personally, am still, not in the position to easily build and test a new dnsmasq package for cerowrt and have no funding or time for further development based on chaos calmer. Hopefully someone else in the openwrt or cerowrt world can take up the slack. I see that several bleeding edge sub-distros of openwrt have also emerged on their forums... (Yet.... I will still try to produce a test dnsmasq version from the cerowrt-3.10 tree but I doubt it would be safe to do an opkg update for it.) On Thu, Jan 8, 2015 at 8:34 AM, Simon Kelley wrot= e: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > OK, it's taken some time, but with this insight, I've recoded the > relevant stuff to look for the limits of the signed DNS tree from the > DNS root down. That's clearly the correct way to do it, and should > avoid the original problem here, caused by sending DNSSEC queries to > DNSSEC-unaware servers in the unsigned parts of the tree. > > This was quite a big change, and it could do with some serious > testing. Available now on the dnsmasq git repo, or as 2.73test3 in a > tarball. > > There are other DNSSEC fixes in there too, Check the changelog. > > > Cheers, > > Simon. > > > On 04/10/14 22:45, Anders Kaseorg wrote: >> On Fri, 3 Oct 2014, Anders Kaseorg wrote: >>>> secure no DS means that the original unsigned answer should be >>>> accepted, except that it shouldn't. There's no way to >>>> distinguish between secure lack of DS because we've reached an >>>> unsigned branch of the tree, and secure lack of DS because >>>> we're not at a zone cut, except if we know where the zone cuts >>>> are, and we don't. >>> >>> Having just looked through RFC 5155 for clues: isn=E2=80=99t that the >>> purpose of the NS type bit in the NSEC3 record? In this example, >>> DS university would give an NSEC3 record with the NS bit clear. >>> That signals that we should go down a level and query DS campus. >>> In this case we find a signed DS there. But if we were to find >>> an NSEC3 with the NS bit set, then we=E2=80=99d know that we=E2=80=99ve= really >>> found an unsigned zone and can stop going down. >> >> Aha: and this is exactly the answer given at >> http://tools.ietf.org/html/rfc6840#section-4.4 . >> >> Anders >> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQIcBAEBCAAGBQJUrrGDAAoJEBXN2mrhkTWitZ0P/1T8AaAAlcgI6Z9oDXBGKR+Q > gw0E0bUcmMsvOf5YepR4jqNqonMYBDEv5aSx4EG13LEYBdEekVjUWlakcTSFGCCH > r4bx91XmxZBBSjBM2UNRd4B/dGY34YydbjPFnV/Mmzv5FdUzmVxG3PRQ3E0EyyLp > Eczm+s0Dxz4pGzEINhFHZ6T8sByDeSjAb3adBNidofKFSevwIv/iOMOQJ5moQfem > VkY+azpFzSmpdeNpIU+uboMfcg4jhFpVU3WRr7umTmLc0KOus1j7ao9GxSujPQHo > S7q+IwSwKHUPMEeEmQh+j7yJ2seweGuqGl0quWkHaqGUIOh2C2E756qZfXeenUcv > ia00dcKmpCYi0Ay3nXdgIq91aRwc78GsR93MEBTuvJwDmAUDupsbZMdlA/3D6tOd > ZTREvBmxkFz/QYOo731N/JzdaflQeLUrNPIwRJKpYFW9caotiJ3EiihRGrqrjHBk > a7h8QXy8bQKxc3G0LLKlJNIkxApnNzG6YGSmD6t9bzRPn/sSqar0Ws0IIYd5nYDv > hB4ggfpHvrnEbke4lkfoEBLbJmFFcnSngJh7oDCMT6XEpqeUH7HT0RmYEncnbH1C > 9ZRpzUlzxyhZawjBbXWQBNmxhT2Z/KFYkLUkKMPnb060CBtn8DwlkZ22b2dqOvH8 > TeRUKySnx6ieH+55fjG4 > =3DCehB > -----END PGP SIGNATURE----- --=20 Dave T=C3=A4ht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks