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

[Simon Kelley]

-----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
> <simon at thekelleys.org.uk> 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-----