[Cerowrt-devel] Full blown DNSSEC by default?
dave.taht at gmail.com
Sun Apr 13 11:04:35 EDT 2014
On Sun, Apr 13, 2014 at 12:51 AM, Török Edwin
<edwin+ml-cerowrt at etorok.net> 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
> 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.
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:
> 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?
> Best regards,
> Cerowrt-devel mailing list
> Cerowrt-devel at lists.bufferbloat.net
More information about the Cerowrt-devel