-----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 > <[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----- _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
