Development issues regarding the cerowrt test router project
 help / color / mirror / Atom feed
From: "Török Edwin" <edwin+ml-cerowrt@etorok.net>
To: cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] Full blown DNSSEC by default?
Date: Sun, 13 Apr 2014 10:51:40 +0300	[thread overview]
Message-ID: <534A420C.4020102@etorok.net> (raw)
In-Reply-To: <CAA93jw41jCuc2UN0rB6WQdVz2qzOtEcoCS-Pm6czwLDU59uXqA@mail.gmail.com>

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.

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

Best regards,
--Edwin



  reply	other threads:[~2014-04-13  7:51 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-13  4:26 Dave Taht
2014-04-13  7:51 ` Török Edwin [this message]
2014-04-13 15:04   ` Dave Taht
2014-04-13 10:05 ` Toke Høiland-Jørgensen
2014-04-13 14:57   ` Dave Taht
2014-04-13 17:59   ` Chuck Anderson
2014-04-13 23:24     ` Dave Taht
2014-04-14  9:29       ` Aaron Wood
2014-04-17 21:01       ` Simon Kelley
2014-04-17 21:19         ` Dave Taht
2014-04-20 14:01     ` Chuck Anderson
2014-04-20 15:16       ` Valdis.Kletnieks
2014-04-20 15:41         ` Chuck Anderson
2014-04-13 16:16 ` dpreed
2014-04-13 16:40   ` Dave Taht
2014-04-13 17:57     ` Toke Høiland-Jørgensen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=534A420C.4020102@etorok.net \
    --to=edwin+ml-cerowrt@etorok.net \
    --cc=cerowrt-devel@lists.bufferbloat.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox