On 10/04/2014 18:29, Dave Taht wrote: > On Thu, Apr 10, 2014 at 8:18 AM, Robert Bradley > 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