Reducing the Complexity of the DNS

Is increasing complexity inevitable?

The worldwide DNS system is very stable and scalable, but the software underlying it is extremely complex. At ISC we kind of enjoy mastering the intricacies of the DNS. BIND’s most enduring competitive strength may even be our feature-completeness. However, we know that complexity is really the enemy of stability and performance.

ISC has long endeavored to make BIND 9 a ‘reference implementation’ of the IETF DNS standards, but in recent years we have been hearing from our users that more is not always better. Our colleague Bert Hubert from PowerDNS coined the term “the DNS Camel” in a presentation at an IETF DNS Operations working group meeting, in which he protested that the Internet community should stop increasing the complexity of DNS software implementations by constraining the impulse to create additional Internet Standards for the DNS.

How did the DNS become so complicated?

• The Domain Name System - and the BIND 9 software implementation - was first developed at a time when the Internet infrastructure was very different than it is today. Some BIND 9 options reflect that earlier architecture. The dial-up options probably fit into that category, although it is possible they are still useful in some of the more remote corners of the Internet. Soon, additional new network transport protocols, including HTTPS, TLS, and possibly QUIC will further complicate the DNS.
• In the early days of BIND, multi-user operating systems were more heterogenous. BIND implemented some low-level features that were missing in some of the operating systems of the time, even implementing assembly code to adapt to OS variants. Modern operating systems have since obsoleted the named implementations of those features. We are remediating that complexity with refactoring, such as the recent refactoring in BIND 9.16 to use the libuv library in place of named network code. While adopting other open source components simplifies the BIND 9 code, it does not necessarily simplify the situation for packagers and operators, as the issues that have arisen with availability of libuv have shown.
• The pressures of combatting increasing abuse have spawned many additional features to make the DNS more resilient. Examples in BIND include Response Rate Limiting, Fetches per Server, Response Policy Zones, DNS cookies, Refuse ANY, Pre-fetch and Access Control Lists.
• At the same time, the DNS has scaled up as the Internet use has grown exponentially. This has brought multi-processor systems with multithreaded high performance software, and constant streams of zone updates with incremental zone transfers, and TTL limits.
• Modern innovations like Content Delivery Networks, Software as a Service platforms, special DNS filtering services and other marketing imperatives have driven a plethora of new features, like CNAMES, EDNS Client-Subnet Identifier, and NXDOMAIN redirection.

Is it possible to reduce software complexity?

Of course it is possible!

Reducing the complexity of BIND 9 requires a combination of refactoring and simplifying obsolete code, and removing obsolete features. The BIND 9 development team has invested quite a bit of effort since 2017 in rewriting some functions, but we haven’t yet removed many features. ISC has published a process for removing features from BIND 9; per that policy we first will ask for user input when we propose to remove a supported feature. We have actually removed a few features, but as you can see from the 980-line long list of options in BIND 9 there are still an enormous number of features remaining.

What kind of features are easy candidates for removal?

• ISC participates in DNS Flag Day, an effort to remove complexity due to workarounds to adapt to incompatible implementations. These can require that named supervise communications and catch non standards-compliant messages and adjust to them with exceptional behavior.
• We have been removing code that was explicitly added to enable specific obsolete operating systems, such as ULTRIX and Windows 32-bit.
• Some features were added with the intent that they would be a transitional bridge as new technology was phased in; for example, the DNSSEC Look-aside Validator was planned as a transition feature during the early adoption of DNSSEC. Multiple features were added to ease the introduction of IPv6. There is always going to be a debate about when these transitions end, but these features are clearly fair game.
• A few features have proven to be inadvisable. For example, we have removed support for some insecure encryption algorithms (DNSSEC Algorithms 1, 3, 6, and 12, aka RSAMD5, DSA, DSA-NSEC-SHA1, and ECC-GOST.)

Fed up with complexity? Help us identify little-used features and options to remove!

At ISC we will continue to retire features that we think are obsolete. However, it is much harder to remove features than you might think. For any given feature you think is useless, there is someone on the Internet using it. You can help by identifying features you don’t use, or that you think are inadvisable.

Survey

Our colleagues at CZ.NIC are running a survey of open source DNS operators to try to determine which features are really in widespread use, and which can perhaps be decremented with little impact. Please help open-source vendors by providing feedback in their survey.

If you don’t want to complete the whole survey, consider at least answering the question about remote telemetry. If we had some data about what features are actually in use, that would be invaluable.

If you can’t be bothered with a survey at all, consider suggesting some of your favorite lame duck features as candidates for removal by emailing the bind-users list.