[Dnsmasq-discuss] [Cerowrt-devel] Problems with DNSsec on Comcast, with Cero 3.10.38-1/DNSmasq 4-26-2014
simon at thekelleys.org.uk
Thu Jan 8 16:34:11 GMT 2015
-----BEGIN PGP SIGNED MESSAGE-----
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
There are other DNSSEC fixes in there too, Check the changelog.
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 .
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
-----END PGP SIGNATURE-----
More information about the Dnsmasq-discuss