From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bytemark.thekelleys.org.uk (bytemark.thekelleys.org.uk [213.138.109.107]) (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 96EFA21F565 for ; Thu, 8 Jan 2015 10:07:54 -0800 (PST) Received: from [213.205.251.104] (helo=[192.168.87.210]) by bytemark.thekelleys.org.uk with esmtpa (Exim 4.80) (envelope-from ) id 1Y9HUs-0004tC-Pl; Thu, 08 Jan 2015 18:07:50 +0000 Message-ID: <54AEC775.7070101@thekelleys.org.uk> Date: Thu, 08 Jan 2015 18:07:49 +0000 From: Simon Kelley User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Dave Taht 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> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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 18:08:23 -0000 -----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. 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=dnsmasq.git;a=commit;h=5782649ad95382dd558df97b33b64e854d8789fb is a possible candidate. > 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. 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’t 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’d know that we’ve 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 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 =i31t -----END PGP SIGNATURE-----