Re: [Cerowrt-devel] Full blown DNSSEC by default?

[Dave Taht <dave.taht@gmail.com>]

On Sun, Apr 13, 2014 at 12:51 AM, Török Edwin
<edwin+ml-cerowrt@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
>> 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
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel



-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article