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

[Sebastian Moeller <moeller0@gmx.de>]

Hi Dave,


On Apr 10, 2014, at 19:29 , Dave Taht <dave.taht@gmail.com> wrote:

> 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'

	Thanks a lot. This (plus a restart) actually got DNS and hence "the internet" working again (on a german deutsche trelekom ADSL line with cerowrt as secondary router after the dt supplied one).


> 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
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel