[Cerowrt-devel] cerowrt-3.10.36-4 released

Sebastian Moeller moeller0 at gmx.de
Thu Apr 10 15:06:26 EDT 2014

Hi Dave,

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

> On Thu, Apr 10, 2014 at 8:18 AM, Robert Bradley
> <robert.bradley1 at gmail.com> wrote:
>> On 10/04/2014 15:32, Toke Høiland-Jørgensen wrote:
>>> Robert Bradley <robert.bradley1 at gmail.com> writes:
>>>> - I had to add my cable modem configuration address to the BCP38
>>>> exception list (  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
>>> 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 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' ''
> 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 at 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 at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel

More information about the Cerowrt-devel mailing list