Subject: [DNSOP] Waiting for DNSSEC...

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 2 Nov 2018 14:30:15 -0400

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

If a zone's parent supports CDS, the same should be possible with
KSKs, but now the server would need to poll the parent zone
periodically to determine whether it can proceed with the key
rollover.  Regardless of CDS support, generating the new KSK and
incorporating it into the zone apex DNSKEY RRset should also be
something that the nameserver can handle internally.  It then
remains only for either CDS, or a manual action by the user to
upload the corresponding DS RRs, to complete the process.

Users *should not* have to run any manual key generation or key
rollover steps, unless they are sophisticated enough to want more
control.

All the magic incantations I have to invoke to keep my zone signed
and rotate keys periodically are I expect a big part of the reason
why many operators shy away from deployment.  With the relevant
bits automated, and a zone audit tool to report whether automated
re-signing is happening in a timely manner as expected, operating
a DNSSEC-signed zone can be no harder than operating one that is
not.  If more zones are signed, the resolvers will come along, they
often already are capable of doing validation, it just needs to be
turned on.

Yes, the ISP-provided CPE router/DNS resolvers will be the long
tail of the adoption curve...  But the ISPs first need to see that
a large fraction of zones are signed, and that those zones are
operating reliably, so that enabling validation is safe and useful.
This gets back to the incentives for the authoritative zones.

-- 
	Viktor.

---

From: Mukund Sivaraman <[email-masked]>
Date: Sat, 3 Nov 2018 11:05:02 +0700

> 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

---

From: Tony Finch <[email-masked]>
Date: Mon, 5 Nov 2018 18:30:45 +0000

> > to become less brittle and more user-friendly.

Yes!

> > master server from time to time, completely without user intervention.

Knot DNS's automated key handling is quite a lot further ahead in
usability. It's a great example.

> making validation of answers unusable (DoS) for a long period of time.

I hope that better automation will make it harder to make mistakes,
especially since the automation should includes checks to prevent bad
configurations from screwing things up. Bugs notwithstanding :-)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Plymouth: South 5, increasing 6 or 7, perhaps gale 8 later. Moderate or rough.
Rain at times. Good, occasionally poor.

---

From: Petr Špaček <[email-masked]>
Date: Fri, 30 Nov 2018 10:11:36 +0100

> usability. It's a great example.

Details for reference:

https://www.knot-dns.cz/docs/2.7/html/configuration.html#dnssec-automatic-ksk-management

or here

http://ripe75.ripe.net/wp-content/uploads/presentations/123-CDNSKEY-FRED-KNOT-RIPE75.pdf

(including the registry side)

> configurations from screwing things up. Bugs notwithstanding :-)

Automation will certainly help, e.g. with problems like
http://smoogespace.blogspot.com/2017/09/fedora-project-outage-rca-dns-outage.html

-- 
Petr Špaček  @  CZ.NIC