From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::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 35A9E21F5A7 for ; Thu, 8 Jan 2015 11:52:24 -0800 (PST) Received: by mail-oi0-f43.google.com with SMTP id i138so8958728oig.2 for ; Thu, 08 Jan 2015 11:52:24 -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=fO5DmuH5vsk2EqYErhhOqQ2NE5TegXYj1WmYjkez8fM=; b=uBwHrscmN7FQU74mL15LgUrb8bjXbZS98DCHcsXr1VrR+Lsd7PDxZmW7vDUYQjd4LR RE68at6/tgFOTUdo40+wKzgyxS7OD2jHKDbJWqIxQMgMl9CudrUyVGGQJFgCltvlp1Uo lMY2fld3Sr21llI5HuUplTBne0dm3PiSyxL1nO3jPLWo61mXNibdV0EuyTVE/XW8F/Vf LwukqVbQrODJOMLziqGxvm9FKyoZgAgFFrlCrTRBC4aHUAPsOkOWS0AoMa9FKzY3K4tv IT8U36Jpsis+MBADpZKd/j7AwcPK+rCTzIx+ycEyFMGpzPsG2/9tBla9SIHIGTwFRUSJ YQ5g== MIME-Version: 1.0 X-Received: by 10.202.199.80 with SMTP id x77mr6463531oif.12.1420746743866; Thu, 08 Jan 2015 11:52:23 -0800 (PST) Received: by 10.202.169.209 with HTTP; Thu, 8 Jan 2015 11:52:23 -0800 (PST) In-Reply-To: <54AEC775.7070101@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> <54AEC775.7070101@thekelleys.org.uk> Date: Thu, 8 Jan 2015 11:52:23 -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 19:52:53 -0000 OK, I built this latest dnsmasq as a test for cerowrt-3.10-50 users: login to the router cd /tmp wget http://snapon.lab.bufferbloat.net/~cero2/dnsmasq/dnsmasq-full_2.73-3_a= r71xx.ipk opkg install ./dnsmasq-full_2.73-3_ar71xx.ipk (ignore the warnings about not overwriting several files) I did a few tests on the former dnssec problematic sites and everything looked kosher. As for the variety of the dnssec testing web sites.... about half seem down or mis-behaving. Sigh. the ongoing costs of keeping core internet test tools going strikes again... In an orgy of self-flagellation, and *only because I have native ipv6* I also turned off dns queries over ipv4 entirely (this is option peerdns '0' in /etc/config/networks on cerowrt's ge00 config), and will pound on it a few days/weeks. I send this email prior to actually trying that, however.... On Thu, Jan 8, 2015 at 10:07 AM, Simon Kelley wro= te: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > > > On 08/01/15 17:44, Dave Taht wrote: >> 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) > > ds.test-ipv6.com is still showing the same behaviour it was back in > April (!) as far as I can see. My bad. The "modern openwrt" I am behind does not have the dnsmasq-full package installed. > Queries to test-ipv6.com (which is what > tripped up Jim in the first place) work fine on the latest dnsmasq, > code, forwarding to 8.8.8.8 > >> >> Is there another site that demonstrates this problem? > > There were three in Aaron Wood's original posting (subject: Had to > disable dnssec today) > > - - Bank of America (sso-fi.bankofamerica.com) > - - Weather Underground (cdnjs.cloudflare.com) > - - Akamai (e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net) > > > All three work for me with the new code. I didn't try old dnsmasq, to > see if the repair was from that or the DNS configuration. > >> >> 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? >> > > http://thekelleys.org.uk/gitweb/?p=3Ddnsmasq.git;a=3Dcommit;h=3D5782649ad= 95382dd558df97b33b64e854d8789fb > > is a possible candidate. K. >> 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.) > > There shouldn't be any non backwards-compatible changes in dnsmasq to > bite you. Don't know about other stuff. So far so good. > > > Cheers, > > Simon. > > >> >> On Thu, Jan 8, 2015 at 8:34 AM, Simon Kelley >> wrote: 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 unsig= ned >>>>>> 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 > > iQIcBAEBCAAGBQJUrsduAAoJEBXN2mrhkTWiRLwP/2tUY2VLgehYWiAtBXcfjLMU > ZBPpRqwQmvXfypcXoqcZPvutDJCXPw4N/UGN3ole1eDCILBPQ6k8asujNLs0wZnN > m7/mrgS0JEWWSbVsqcTy3JgLh2TcGO0DG7LcOUKZX0VIbNwPVvG6Bv4eBk9afVJ1 > sXwxAzdPLoQ5RBnjBCcpcVqRijU5jFClsBXSPsg725xKr9LYh4ZmUJB4TIgHGS/D > UfywntWAvF2hhEZNAIdE6wenQmTlmnQ0mEJK9mn5OfKP3WnDyOlvTI7E3gZ/9gRc > qj+4QSjK31pCam3CoyCHLW8jEDy0/GkEWCCJt58ZelpZz7jh34aiPclalaRVGKNz > PcXiGnmoQnk7ZALaE8VqEEtLh5XLZ067QditsR89Syu8g1iwIOIDR4yJ2gN+0VKD > qs48K7FgxVX+DCpJjCoVfu9F0dWf3haeJetMchFw1WsJdVyIg1yBvc2x+3JD+j8j > idv196X1rb1P68ufGzFILwHcX9oWXDhKaYyZLSZnfPLAUq6is3bnTBY74SHrRYOw > gmPpZ0ysY+gVH7DAMhSViT5fsmUHzho8LLJ4gTuzYyrLAx91CamD6sX/cYXAXZ5t > RNSMp6jOiMV7N9/d1R8WTeX3b9lJ5dZHzql2ldllRhRvlCrb/Lx7+E1frn19dwGe > /cL5NcnFWYc5n32K8mTF > =3Di31t > -----END PGP SIGNATURE----- --=20 Dave T=C3=A4ht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks