Development issues regarding the cerowrt test router project
 help / color / mirror / Atom feed
From: Dave Taht <dave.taht@gmail.com>
To: Simon Kelley <simon@thekelleys.org.uk>
Cc: dnsmasq-discuss <dnsmasq-discuss@thekelleys.org.uk>,
	"cerowrt-devel@lists.bufferbloat.net"
	<cerowrt-devel@lists.bufferbloat.net>,
	Anders Kaseorg <andersk@mit.edu>
Subject: Re: [Cerowrt-devel] Problems with DNSsec on Comcast, with Cero 3.10.38-1/DNSmasq 4-26-2014
Date: Thu, 8 Jan 2015 11:52:23 -0800	[thread overview]
Message-ID: <CAA93jw7wyGGhE6kQYe8E9Mia6vk1FJXmkfUvYWP0eRoMs2jpUw@mail.gmail.com> (raw)
In-Reply-To: <54AEC775.7070101@thekelleys.org.uk>

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



-- 
Dave Täht

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

  reply	other threads:[~2015-01-08 19:52 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-28 16:55 Jim Gettys
2014-04-28 17:03 ` Dave Taht
2014-04-28 18:37   ` Dave Taht
2014-04-28 18:56     ` Dave Taht
2014-04-28 19:32       ` [Cerowrt-devel] [Dnsmasq-discuss] " Simon Kelley
2014-04-28 19:45         ` Aaron Wood
2014-04-28 23:24         ` Phil Pennock
2014-04-29 13:22           ` Simon Kelley
2014-04-29 20:57             ` Phil Pennock
2014-04-30 17:26               ` Dave Taht
2014-05-01 18:37                 ` Simon Kelley
2014-05-01 20:26                   ` Rich Brown
2014-05-01 22:27                     ` Dave Taht
2014-05-02 14:30                       ` Sebastian Moeller
2014-05-01 18:35               ` Simon Kelley
2014-05-02 16:40                 ` James Cloos
2014-10-03  9:28             ` [Cerowrt-devel] " Anders Kaseorg
2014-10-03 17:28               ` Valdis.Kletnieks
2014-10-03 21:35                 ` Anders Kaseorg
2014-10-04 21:45               ` Anders Kaseorg
2015-01-08 16:34                 ` Simon Kelley
2015-01-08 17:44                   ` Dave Taht
2015-01-08 18:07                     ` Simon Kelley
2015-01-08 19:52                       ` Dave Taht [this message]
2015-01-09  8:52                         ` Dave Taht
2015-01-09 15:36                           ` Simon Kelley
2015-01-09 16:49                           ` Simon Kelley
2015-01-09 21:34                             ` Dave Taht
2015-01-10 15:37                               ` Simon Kelley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAA93jw7wyGGhE6kQYe8E9Mia6vk1FJXmkfUvYWP0eRoMs2jpUw@mail.gmail.com \
    --to=dave.taht@gmail.com \
    --cc=andersk@mit.edu \
    --cc=cerowrt-devel@lists.bufferbloat.net \
    --cc=dnsmasq-discuss@thekelleys.org.uk \
    --cc=simon@thekelleys.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox