Re: [DNSOP] Waiting for DNSSEC...

[Mukund Sivaraman <[e-mail]>]

On Fri, Nov 02, 2018 at 02:30:15PM -0400, Viktor Dukhovni wrote:
> [ Was: Fundamental ANAME problems
>   Dropped In-Reply-To:, to ensure a new thread. ]
> 
> On Fri, Nov 02, 2018 at 06:28:52PM +0100, Måns Nilsson wrote:
> 
> > > I'll defer to other people, but it seems to me that anything that depends on
> > > recursive DNS servers being updated isn't a realistic solution.  We're still
> > > waiting for DNSSEC, after all.
> > 
> > Be as pessimistic as you like, but in Sweden, more than 80% of the ISP
> > resolvers validate. The DNS can change, at a sometimes glacial speed,
> > but it does change.
> 
> I rather think that updates DNSSEC-capable software are not the
> bottleneck for DNSSEC.  The real bottleneck is disincentives to
> signing in the form of difficult to use tools, and barriers to KSK
> enrollment and rollover at registrars.
> 
> To move DNSSEC adoption higher, CDS/CDNSKEY/... need to be supported
> by most registries and the signing and key rollover tooling needs
> to become less brittle and more user-friendly.
> 
> Updates of ZSKs are still too manual.  For example, BIND's "auto-dnssec
> maintain" should be able to automatically generate new ZSKs on
> master server from time to time, completely without user intervention.

There is a part-protocol part-tooling issue in DNSSEC. A mistake in
configuration (operator) or software bug (developer) is capable of
making validation of answers unusable (DoS) for a long period of time.

* It takes time to diagnose and find out what the issue is that suddenly
  caused domains to be unresolvable. Whether it is a configuration
  error, or if the signing software had a bug.

* Once the error is diagnosed, if it is a implementation bug, the
  operator's hands are effectively tied in doing anything about it for
  some time as they rely on that particular software
  implementation. Such implementation bugs show themselves randomly. By
  that, I mean once there is a working system that has been tested and
  deployed by an operator, signing bugs show up while in use. I can
  point out at least 2 such major signing bugs in the past year.

* Whether an implementation bug or a configuration bug, caching effects
  mean that records in a zone are unresolvable for at least some time
  (unlike with other protocols such as TLS where a fix immediately takes
  effect).

However automated DNSSEC has become, such all-or-nothing issues are
still present (as of this year). There may be some implementation
changes recommended to react quickly to such problems.

Even though that sounds negative, I think an end-to-end authentication
system like DNSSEC is necessary in today's world of interference. The
success of DNSSEC that can be recognized today is not that it is in
popular use, but that it is available to be used by anyone who wants it.

		Mukund