Putting an End to Workarounds for Broken Software

Published: Thu 07 June 2018
Last updated: Tue 17 December 2024

The specification of the DNS protocol and its extensions in the IETF, the implementation of the protocol standards and its compliance, and the interoperability between DNS name server implementations give rise of complex interdependencies. For one, the IETF standards sometimes allow room for different interpretations resulting in slightly varying behavior in the implementation of the DNS standards. And sometimes there are different operational realities to be addressed, resulting in different decisions. But for all, the open-source DNS software developers address interoperability between their implementations, and make sure that the users of the DNS software can rely on the correct behaviour of the individual DNS name servers (authoritative and recursive).

Unfortunately, a substantial amount of effort and code is spent to cope with broken DNS software implementations. With broken DNS software, we mean software that does not comply with the standards in any interpretation and just fails to behave properly. The net effect is that the open-source DNS software developers have to deal with the errors and ignorance of the broken DNS implementations. Put differently: we have to pay a price in time and code complexity for the errors of other parties that don't bother to resolve their incorrect implementation.

EDNS Extension Support

To signal the start of a joint effort to reduce the code necessary to implement workarounds in their DNS software, a group of open-source DNS software developers will discontinue a support for dealing with broken EDNS support.

From February 1st, 2019 new releases of DNS software from CZ.NIC, ISC, NLnet Labs, and PowerDNS will drop support and code for the workaround of non-compliance problems with EDNS standard as specified in RFC 6891.

EDNS is a mechanism to include optional information in DNS messages. It is not mandatory to implement. The DNS standards provides implementations with a way to signal their lack of EDNS support. However, some implementations choose to react in non-standard ways when provided with EDNS messages, requiring workarounds for interoperation. We have deliberately selected to remove these workarounds to send a clear signal instead of causing a major disruption.

Related links:

general news