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

[Robert Bradley <robert.bradley1@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3271 bytes --]

On 10/04/2014 18:29, Dave Taht 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:
>>> 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
> 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.

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:

u.arin.net: 25ms
v.arin.net: 30ms
ns1.arin.net: 100ms
ns2.arin.net: 160ms

> 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

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)
> also.

I agree, but I'm not expecting any rush for the major ISPs here to
support either!

-- 
Robert Bradley



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]