[Cerowrt-devel] Problems with DNSsec on Comcast, with Cero 3.10.38-1/DNSmasq 4-26-2014

[Dave Taht]

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 <simon at thekelleys.org.uk> wrote:
> -----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’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
>
> 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
> =CehB
> -----END PGP SIGNATURE-----



-- 
Dave Täht

thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks