DNS RFCs: The Elephant in the Room – Part 2

As stated in Part 1 of this series, DNS RFCs have a great impact on how DNS operates. It comes with a risk factor and can impact security. In this second part, we will continue to discuss the impact and provide some food for thought on how to deal with it.

DNS is a clear Favorite – Everyone, and I mean EVERYONE loves it!

DNS has had more than 25 years to mature, and with that, also the bad actors that want to attack and misuse it for malicious purposes. Through the early years, DNS was simple to attack/misuse, which helped force it to become a more mature, solid, and secure service. The complexity of building DNS results in more and more vectors, risks, and potentially more opportunities to attack and misuse. Due to its position and wide use, DNS is a huge favorite to be attacked and misused as well. And this has been historically proven! DNS is by far one of the most attacked and used for malicious services worldwide for a long time. And misuse is growing by the day.

To add: Currently, most if not all Malware/Ransomware, for the same reasons, relies or even depend on DNS to operate correctly. Therefore DNS is a good first line of defense (see “DNS is Important” in part 1, as it will see the malicious intent and already can start protecting networks before bad stuff happens.

That said, with all the approved RFC features, add-ons, and extensions on DNS, the payload and impact of when it gets attacked for example have wider implications than DNS alone as well, adding extra processing and utilization of more resources. It could be that the additional protocols (TLS, HTTPS, QUIC, etc) and their attached services that are used, can be impacted as well, including the platform or even knock-on effects down the chain of things. It is not DNS alone anymore in that respect. This is an added complexity.

Building a DNS engine that is “RFC Compliant” is a massive task

As seen above, keeping everything in account and building/testing a DNS engine is a massive task because of the sheer volume of regulation, rules, standards, and usage described in the RFCs. You need to be a specialist, not only technically, to do so. And we are not even talking about the required stability, security, and performance that needs to be done as well. It. is. Massive.

Note: Not ALL RFCs have to be implemented, of course, depending on the functions and features needed. As there are so many different DNS RFCs, it is difficult to pinpoint what a minimal set of RFCs should be, and this adds to the confusion.

RFCs are becoming a Security Threat:

Looking at the complexity of building a DNS engine/client and how it is utilized and attacked, the complexity is not helping make DNS safe. The uptick in the number of RFCs for purposes beyond stability, capacity, and security, mostly commercially driven, opens up another plethora of surfaces to use DNS for malicious or unfair usage and in some cases even easier to attack/disrupt.

Wait a minute! What about the RFCs that improve security?

This is a little bit of an eye-of-the-beholder I am afraid. The track record of Security RFCs for DNS is not too bad, but not great either (looking at you DNSSEC!). Lots of these are implemented but not used or under-utilized, or just too difficult to implement or conflict with other features. And, as it is so widely used, implementation and usage lag a lot (we are talking millions and millions of DNS servers, and billions of users/clients here).

Due to the “server and client” setup, it kind of depends that both being in line on this, and this is not the case. There is a lot of diversity, and it comes with risks and other scary stuff. This is one of the reasons that you need a capable DNS server that is purposely built to provide features/options to deal with these kinds of “facts of life” and be able to anticipate from a security angle. There are best practices to follow (funny enough, also described in RFCs of course), and implementations need to stay up-to-date as it is an ever-evolving/changing living thing.

RFCs are not a bad thing!

A good thing! You might have wondered if it looks like we are bashing RFCs here, we are NOT! It is more about understanding the sheer volume of RFCs that makes DNS very complex. It should be simplified to be more riskless and straightforward. We highly recommend reading this article on the need to do so and providing some direction as well.

So what is the Answer?

A couple of takeaways here are that when utilizing a DNS server/service or client, take one that has the pedigree and is supported by people who know what they are doing and have a pedigree as well. This can be open-source-based or a commercial solution/service. Check what you need from DNS and try to keep it as simple as possible but secure. Encryption is a big thing at the moment, but do you need it? Make sure you standardize the usage of DNS and include it in security plans as part of your security ecosystem/posture. DNS is important and the most used service on your network! Unbelievable, but DNS is overlooked and under-utilized a lot! Which comes at a cost.

The unique value brought by EfficientIP DNS solutions 

EfficientIP offers a purpose-built DNS with a huge pedigree doing it. We understand the RFCs and implement and complement them following a proven way of building and deploying them. This means stability, security and performance come as part of the job. More importantly, the pedigree, expertise, experience and deep know-how needed to weed through the pile of RFCs combined with the expertise of building DNS is unique and mandatory. On top of this, due to the sheer number of users and usage, providing feedback on cases and utilization feeds the know-how bucket, even more, helping make DNS even better.

Read Part 1 here