DNS RFCs: The Elephant in the Room – Part 1

DNS goes back a long way, it is more than 25 years old and is one of the most used, attacked, and implemented protocols by far. Needless to say, it has some security implications and risks attached to it too. Most of them are well documented and discussed, but one of them seems to be overlooked: RFCs (and DRAFTS)

What is an “RFC”

The Internet Engineering Task Force (IETF) maintains and has a process for approving Request-for-Comments (RFC). Solely to create internet standards and how to implement/use them.

Note: This does include non-internet networks and most of these are adopted on many if not all types of networks.

What is a “DRAFT”

Drafts are pre-determined documents with suggestions, advice and other related topics to be elevated or “approved” to become an accepted RFC. In general, it is considered inappropriate to rely on DRAFTs for reference purposes or implement the topics described (but that rule is sadly not a golden standard anymore).

DNS is Important

The Domain Name System (DNS) is the most used protocol on Networks, by far! It sits in front of any transaction or “intent” of any service, application, or operation. NO DNS means NO Business and everything will be affected with degraded quality or availability. This is on every level imaginable of networking including its devices/users. The impact can and will be HUGE! So taking care of DNS appropriately is a must.

Note: It also works the other way around: A rock solid, quick, and safe DNS provides amazing user experiences, makes networks/applications smooth/fast/accessible, and enables/unlocks all kinds of statistics and data on network/user intent, behavior, and usage. Which in turn can be used to report on (visibility/observability), or to feed and enrich your security ecosystem improving your security posture. To repeat: Taking care of DNS appropriately is a MUST!

DNS has the most RFCs and Drafts attached to it of ALL protocols

As of August 2022, there are 297 Approved RFCs and 2327 Drafts (unapproved). This is a huge amount. Reading (and understanding) them alone would take a lifetime (well, maybe not, but it is a huge undertaking).

In this DNS RFCs series, we try to bare the impact of all of this on DNS, the risk and security implications, and how to deal with it to make sure DNS becomes and stays this stable factor in networks as we are accustomed to.

How DNS RFCs Historically was created:

In the early days of DNS, most if not all RFCs were written by DNS experts driving the Internet. They were more aimed to help the Internet and the World to make things smooth, fast, stable, and decentralized. The number of RFCs written per year was low. This accounts for the first 100-150 or so RFCs that were written by the DNS Gods. This went on for the first 20 years or so and was a pretty stable factor.

… And now

Lately, the number of RFCs and Drafts is increasing rapidly and now it looks like two-thirds of all RFCs are either written by non-DNS-experts to fulfill their purposes. Mostly (but not always)  commercially based and under false likelihoods of privacy, security, tracking, and centralization (see Web3, DNS-Over-*, Encryption, Crypto, etc.). 

This means that in some cases, security is pushed to the background, and in a lot of cases used to obfuscate the real purpose and pretty much go beyond the (original) purpose of protocol. Checking out the credentials or authority of these RFC/DRAFT creators becomes an added task and becomes more and more difficult as well. It adds to the complexity.

Approved or Not is the question:

Drafts can have a huge impact on DNS operations as parties building DNS engines (and DNS Clients) choose to implement drafts before the resulting RFC gets approved. Most of the time drafts tend to change a lot on how a particular DNS function needs to work/operate as part of new insights and working out the kinks. This means that the final and approved RFCs most if not all of the time have changed from what the drafts depicted. This has a huge impact on “DNS Clients” (apps, web-browsers, services, etc) and has a disruptive effect, breaking DNS usage/working. All of this results in downtime and the unavailability of critical services or applications.

Note: To clarify, lots of the DNS Drafts lately got implemented by the writers (of the Draft) that operate the DNS service themselves (Cloudflare is a good/big example), even before the Draft was approved as RFC. This means that users take a risk on a service that can change and because of it breaks and impacts business, or features are just not supported which can result in degradation of service/usage.

There is quite some critique on the IETF RFC approval process, which adds to the equation. Mainly some RFCs are not always approved by a person that is a specialist on the subject matter and relies on trust or other people to do so or help out and is deemed not transparent enough. This creates an issue of how to deal with RFCs in general and can be considered a risk. We don’t see any real adverse effects because of this (yet), but we do see the uplift of DNS RFCs that (in our opinion) should not be approved by their function, but should be assessed for the adverse effect it can have on DNS infrastructures. But that is a whole different discussion.

Read Part 2 here!