On Sun, Apr 13, 2014 at 12:51 AM, Török Edwin <[email protected]> wrote: > On 04/13/2014 07:26 AM, Dave Taht wrote: >> I am delighted that we have the capability now to do dnssec. >> >> I am not surprised that various domain name holders are doing it >> wrong, nor that some ISPs and registrars don't support doing it >> either. We are first past the post here, and kind of have to expect >> some bugs... >> >> but is the overall sense here: >> >> A) we should do full dnssec by default, and encourage users to use >> open dns resolvers like google dns that support it when their ISPs >> don't? > > There are people who don't use Google DNS due to privacy concerns. > Given the choice between not using DNSSEC, and using Google's DNS they might > prefer not having DNSSEC.
Good point. Well there is also dnscrypt and opendns. There's a (broken) dnscrypt packaging attempt in ceropackages. > >> >> B) or should we fall back to the previous partial dnssec >> implementation that didn't break as hard, and encourage folk to turn >> it up full blast if supported correctly by the upstream ISP? >> >> C) or come up with a way of detecting a broken upstream and falling >> back to a public open resolver? >> >> Is there a "D"? > > There are some tests described here, and a 'dynamic fallback' technique in > section 5: > http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-roadblock-avoidance-00 > > I think the 'dynamic fallback' can be described in short as: try to use > upstream DNS resolver, > and if you don't get the DNSSEC metadata that you expected, *then* eventually > fallback to iterating from Root for that metadata. Which only works for a full blown local resolver. In the dnsmasq case the switch would have to be another open dns resolver. We could iterate over a list of open dns resolvers to find the best one. > So then A/AAAA/TXT/NS/etc. records would be answered by upstream, and only > for the DNSSEC metadata you would need to iterate > (and you could cache that, or stop iterating if you realize the zone is > unsigned as per section 5.1.1) Maybe there could be a "dnssec-fallback-resolver" setting in dnsmasq, that it could fall back to if a known-not-to-resolve-properly domain can't do a proof of non-existence properly? bork.bork.bork.bork.example.org > Best regards, > --Edwin > > > _______________________________________________ > 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
