Re: [Cerowrt-devel] cerowrt-3.10.36-4 released

[Dave Taht <dave.taht@gmail.com>]

On Thu, Apr 10, 2014 at 8:18 AM, Robert Bradley
<robert.bradley1@gmail.com> wrote:
> On 10/04/2014 15:32, Toke Høiland-Jørgensen wrote:
>> Robert Bradley <robert.bradley1@gmail.com> writes:
>>
>>> - I had to add my cable modem configuration address to the BCP38
>>> exception list (192.168.100.1).  This gets used for nothing except
>>> configuration and checking the modem logs so this is understandable.  I
>>> also end up adding a static route anyway since if Internet breaks, I
>>> need a route to the modem...
>> If you add a 'scope link' route on the wan interface, the BCP38 code
>> *should* pick this up automatically and add an exception. Would be cool
>> if you could test this :)
>
> Just tested this now and it works fine. :)

How did you add scope link?

>
>>> - dnsmasq's default of dnssec-check-unsigned broke my DNS, since my
>>> ISP servers do not support DNSSEC. In that case, everything winds up
>>> as failing.
>> That's an interesting failure mode. FWIW you can point it at
>> 8.8.8.8/8.8.4.4 instead if you want dnssec verification :)
>
> I was tempted to leave it as-is, but tested it now with a custom
> /tmp/resolv.conf.manual file and it also works well with added DNSSEC
> checks.

As if working around the time problem was not headache enough...

I note that until now the dnssec implementation was NOT doing negative
proofs (proofs of non-existence of a signature), as I added
dnssec-check-unsigned
to /etc/dnsmasq.conf in this release.

dnssec
dnssec-check-unsigned

I do forsee this (and dnssec in general) causing massive problems in
environments
that muck with dns. I have no idea as to how prevalent this problem is.

I'd like for it to not fail silently, but fall back to non-dnssec behavior
in some way that gives the user a chance to figure out why their
network isn't working
and who to point a finger at.

Automagically falling back to 8.8.8.8 doesn't bother me much, except in places
where that is blocked too.

Anyway.

1) You can specify your dns servers in /etc/config/network, and disable fetching
your providers's addresses via adding

option 'dns' '8.8.8.8 4.4.4.4'
option 'peerdns' '0'

to the ge00 declaration. This will do the right thing to resolv.conf.auto.

Another thing the above is useful for if you have working ipv6 via
dhcppd, you will
get the ipv6 dns servers from upstream and use those only.... (otherwise dnsmasq
will choose the "best" upstream and generally chooses the ipv4 one)

2) Alternatively, you can disable dnssec by commenting it out in
/etc/dnsmasq.conf

3) Of course, I advocate pestering your provider to enable dnssec, (and ipv6)
also.

I would like to obsolete resolve.conf.auto in favor of  some of the new
options to dnsmasq -(-revaddr and another I forget), which will make resolving
multi-homed and dns through vpns saner and easier

4) I'd like to benchmark the impact of the non-existence proofs...

>
> --
> Robert Bradley
>
>
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>



-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article