[Cerowrt-devel] cerowrt-3.10.36-4 released
robert.bradley1 at gmail.com
Fri Apr 11 08:34:05 EDT 2014
On 10/04/2014 18:29, Dave Taht 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:
>>> 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?
I added the route via Luci's web interface for it (Network/Static
Routes), using interface ge00 and target 192.168.100.1. The other
settings were left at their defaults (netmask 255.255.255.255, gateway
blank, metric 0, MTU=1500). I verified it via SSH and "ip -4 route show".
The command line equivalent to the resulting route would be "ip route
add 192.168.100.1 dev ge00 proto static" with or without an explicit
"scope link" appended.
> 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
> to /etc/dnsmasq.conf in this release.
> I do forsee this (and dnssec in general) causing massive problems in
> 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 18.104.22.168 doesn't bother me much, except in places
> where that is blocked too.
> 1) You can specify your dns servers in /etc/config/network, and disable fetching
> your providers's addresses via adding
> option 'dns' '22.214.171.124 126.96.36.199'
> option 'peerdns' '0'
> to the ge00 declaration. This will do the right thing to resolv.conf.auto.
I tested that just now and it's working well with no resolv.conf funny
business. On the benchmarking side, it's not a good quantitative result
but the resolution latency via Google DNS doesn't feel that much slower
than the non-validated ISP results. Using dig to pull A records for the
RIR websites, I noticed that validation seems to increase the uncached
query time up to 10-fold compared to a similar +cdflag query, but is
very much distance-dependent. For example, www.arin.net went from 27ms
to 210ms, but the ping RTT to their name servers is:
> 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
I found that just disabling the dnssec-check-unsigned line is enough to
get DNS working again.
> 3) Of course, I advocate pestering your provider to enable dnssec, (and ipv6)
I agree, but I'm not expecting any rush for the major ISPs here to
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 899 bytes
Desc: OpenPGP digital signature
More information about the Cerowrt-devel