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

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