Where/Why has DNS gone wrong?
slides-dedrws-wherewhy-has-dns-gone-wrong-00

For your consideration:

Where/Why has DNS gone wrong?

DNSSEC has largely failed. Although it works from a strictly technical
perspective, it has flopped. There are three main reasons for this market
failure:

1) The business incentives are perverse and the cost/benefit analyses don’t
make sense.

Signing incurs costs and introduces new risks. The benefits are unclear or
non-existent, except when TLD registries offer discounts for signed
delegations. And although ICANN can compel new gTLDs to use DNSSEC, that
doesn’t extend to the delegations in those gTLDs.

Validation introduces extra costs and risks too, also with poor or unclear
benefits. Almost no major ISPs do DNSSEC validation, though there are 2 or 3
exceptions.

Signers don't really benefit from signing, validators do. And validators
don’t benefit (much) from validation, those signing do. Or might do.

2) There are still no killer apps or compelling use cases

DANE seemed to be the last chance to get widespread adoption and use of DNSSEC.
It hasn’t happened yet. Maybe STIR will eventually drive uptake of DANE and
bring about increased use of DNSSEC.

3) DNSSEC is hard

It adds complexity to routine DNS operations and administration. This is not
well understood and rarely documented properly. DNSSEC tools for signing and
troubleshooting tend to be crude, clumsy or both. Rolling KSKs is difficult, as
is managing keys. There are few protocols or tools to help and there’s a lack
of a common set of procedures/protocols across registries and registrars to
make this work smoothly. These problems have largely been ignored. So DNSSEC
festers.

There are also some problems with the DNSSEC protocol. For example the lack of
a clear error code to indicate a validation failure is a serious shortcoming
and some corner case replay attacks are possible. Clients can’t easily tell
the difference between a SERVFAIL because of a DNSSEC validation problem or
some other reason. In fact they can’t tell the difference between a genuine
or a spoofed SERVFAIL response. That wouldn’t be the case if DNSSEC offered
transaction/message integrity rather than just data integrity. Oops.

The last mile issues and the lack of decent APIs are still to be resolved in
any meaningful way. [res_mkquery() and friends are 25+ years old!!] DoT and DoH
might solve the former. But these introduce their own baggage and problems.

With all that background, DNSSEC (and DNS) protocol development has largely
been shunned by key stakeholders such as vendors, major ISPs and registrars.
They’ve just not seen this as relevant to their business. Or they’ve been
unable to make progress and have given up.

But it gets worse. The IETF’s efforts on DNS and DNSSEC have not kept pace
with today’s problems and policy concerns - like privacy and GDPR. So ad-hoc
solutions like DoH emerge which (sort of) address some of these issues. But
they introduce even bigger concerns such as the aggregation and centralisation
of DNS/DoH service amongst a very small number of powerful, dominant players.
And once again, key stakeholder groups are rarely part of the discussion.
History might well be repeating itself with DoH - like when TLD registries
realised late in the day that DNSSEC-bis was unacceptable because of zone
enumeration and the IETF had produced a protocol that a significant chunk of
the DNS community was never going to deploy.

Of course protocols that emerge are by definition a result of those who
participate. The IETF can’t reasonably be expected to consider the views of
those who don’t show up or fail to voice their concerns. Even so, introducing
some form of impact analysis into the standardisation process might be
worthwhile. By way of example, the dprive WG is proposing to work on DoT
between resolving and authoritative DNS servers because it will offer better
privacy and security. However the WG has not consulted operators of busy
authoritative servers about whether this is a good idea or not, what the
operational impacts might be or if they would deploy this if/when an RFC gets
published.

The IETF attitude to new DNS features is sometimes inconsistent.
ECS-Client-Subnet got waved through because it documented a common practice by
some CDNs. Yet Response Policy Zones, another widely used DNS feature, failed
to get picked up by the IETF. Views are widely used, not just in BIND, but this
isn’t documented in an RFC. This inconsistent behaviour is harmful because it
encourages the adoption of proprietary (or undocumented) solutions that make
interoperability more difficult. It might one day lead to forum shopping.

DNS has been around for a long time. But why has the IETF never come up with a
name server management/control protocol? Why does every major DNS
implementation ship with its own management tool and protocol? Why is there no
provisioning protocol for adding/removing zones from authoritative DNS servers?
Could/should the WGs be directed to work on these problems?

Who’s going to fix these concerns? How?
--
Dedr-pc mailing list
Dedr-pc@iab.org
https://www.iab.org/mailman/listinfo/dedr-pc