Hi Dave,
On Apr 10, 2014, at 19:29 , Dave Taht <[email protected]> wrote: > On Thu, Apr 10, 2014 at 8:18 AM, Robert Bradley > <[email protected]> wrote: >> On 10/04/2014 15:32, Toke Høiland-Jørgensen wrote: >>> Robert Bradley <[email protected]> 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 >> [email protected] >> 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 > [email protected] > https://lists.bufferbloat.net/listinfo/cerowrt-devel _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
