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_ar71xx.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 <[email protected]> wrote: > -----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=dnsmasq.git;a=commit;h=5782649ad95382dd558df97b33b64e854d8789fb > > 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 >> <[email protected]> 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----- -- Dave Täht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
