Blog

back to Blog Posts

Guidelines for a resilient DNS

It is essential that the DNS infrastructure is stable and fail-safe. This article summarises principles of how to set up a DNS infrastructure that is secure and resilient. By Michael Zach, CISO at Nic.at.

Abstract & introduction

The Domain Name System (DNS) is the basis for many services on the internet. It is necessary for numerous applications to find the IP address of the relevant service. These applications include, for example, the website of a company, its web-shop, e-mail communication or hostnames for internal services (e.g., SAP, databases, etc.). Therefore, it is essential that the DNS infrastructure is stable and fail-safe. This article summarises principles of how to set up a DNS infrastructure that is secure and resilient.

Separate internal infrastructure from public services

The “authoritative name servers” are the authoritative source for mapping domain names to IP-addresses. Those authoritative name servers must be public, as otherwise internet users cannot resolve the respective domain names. When these name servers are not available, domains cannot be resolved and access to resources will fail. For example, when the domain is used for e-commerce, failing DNS resolution will impact customers. When the domain is used for business e-mails, or to address business internal resources, the business is affected, and employees will not be able to do their jobs. This results in financial damage, operational challenges and impacts the image of the company.

Imagine your company is called “Example Ltd.”, you use www.example.com for your website, and @example.com for e-mail communication. For your internal resources you should consider using a dedicated domain name, like “example-infra.com” to address your network devices, servers, and internal services.

If using a dedicated domain name is not possible, for example, due to legacy issues, you should make sure that the domain name still resolves inside your company network, even if your public authoritative name servers are not available. For this, you could use a “split-DNS” configuration, or have dedicated internal authoritative name servers, and instruct your internal DNS resolvers to “forward” queries for your own domains to these internal authoritative DNS servers.

Location of authoritative DNS servers

When talking about distributed denial-of service (DDoS) targets, many people immediately think about the company’s website, as this is the best-known service. This is probably also the reason why many companies already have dedicated DDoS protection for their websites and web-shops. But attackers are smart and attack everything that may hurt the victim. Other targets include e-mail servers, authoritative name servers, the internet connection of the company and routers on the company’s network. So, all these targets must be addressed when considering DDoS protection.

Traditionally companies would connect their network to the internet with a firewall, configure a DeMilitarised Zone (DMZ) to host public services like the corporate website, and run an internal network for employees and internal services. DDoS attacks or an unexpectedly high number of simultaneous visitors targeting the company website would overload the internet connection and network of the company. As a result, most businesses now host their websites outside of the company networks. Yet, many still self-host the DNS and e-mail in their network. Hence, a dedicated attack against the authoritative name servers will traverse the company’s internet connection, the internal networks and possibly several firewalls.

Even if the name server can handle the attack, the internet connection may suffer, firewalls may get overloaded and the whole company network may suffer, making it difficult for employees to do their job. Conversely, an attack against some other parts of the company’s network may overload the internet connection and reduce or even block communication with the authoritative name servers. While in the latter scenario the company’s web-shop will still work fine, internet users will barely be able to reach the web-shop due to the failing domain name resolution.

Therefore, put public authoritative name servers into the public network, not in an internal company network. Host them at a service provider, or in the cloud, or use DNS services of specialised DNS service providers.

Note: If your internal services also rely on domains hosted outside your network, as discussed in the previous section, make sure to have a copy of the zone on internal authoritative name servers.

Firewalls and load balancers

The purpose of a firewall is to control access to certain resources. The public authoritative DNS is indeed public, so there is no use in operating dedicated firewalls protecting DNS Port 53. Of course, a firewall should protect the server hosting the name service (e.g., protecting SSH access to the server), but there is no need to protect and track Port 53.

DNS mostly uses UDP as transport protocol, where every single request uses a different source IP and source port. With stateful firewalls, every single DNS request will create a “connection” in the firewall, stored in state tables. These state tables are a limited resource. Recent attacks against DNS servers showed that outages were often caused by overloaded firewall state tables. Hence, a simple iptables/nftables firewall, which only allows UDP+TCP Port 53 without state tracking (“NOTRACK”), usually outperforms a dedicated firewall and saves resources on the expensive enterprise firewalls.

DNSSEC for end-to-end validation

Nowadays, end-to-end protection for services mostly uses application layer security. For example, TLS is added to http to form https securing the communication between browser and web server. But there are still services where end-to-end security is not used for a large part of the underlying systems. Foremost, e-mail is still vulnerable to man-in-the-middle attacks using DNS spoofing, i.e., the manipulation of DNS entries or DNS server addresses in the memory of network devices. The only available technology that guarantees the authenticity of DNS information is DNSSEC (Hoffman, 2023). However, DNSSEC is still considered complicated and error-prone and has so far found comparatively little adoption.

So, before using DNSSEC, you should understand the technology and test DNSSEC procedures extensively. Alternatively, if you do not want to perform that activity, use a DNS provider, which offers DNSSEC signing of customer zones like our service.

Unix-based OS and name servers

Running an authoritative name server requires a robust operating system (OS) and trustworthy software with a proven track record, for example, a Unix/Linux based operating system with a well-known trusted name server software such as ISC Bind, NLNedLabs NSD, CZ.NIC Knot DNS or PowerDNS (Lencse, 2020, and Wikipedia, 2024).

Like with any other piece of software, remember to continuously update the operating system and the name server software in order to be prepared for new vulnerabilities.

Note: One of the most dangerous vulnerabilities of DNS ever published was cache poisoning (Kaminsky, 2008). Shortly after the incident, updates had been made available for all name server software products, One would expect that, in the meantime, these updates have been applied to all instances worldwide. In reality, however numerous “forgotten” DNS servers have not been patched even – after more than 15 years!

DNS anycast

When choosing a DNS provider, look for providers that deploy anycast technology. Anycast is a network configuration method standardised as RFC 1546 (Mendez et al., 1993).

Anycast allows to achieve a high level of cyber resilience by running multiple instances of a service, such as DNS on different physical locations sharing only a single IP address. Network packets, like DNS queries, in an anycast topology always take the shortest path, resulting not only in high redundancy but also low latency. This is achieved by applying the Border Gateway Protocol (BGP) and clever prefix announcements at different parts of the internet. Aside from speed, anycast provides high redundancy with efficient load balancing and improved fault tolerance by design.

In contrast, traditional unicast technology relies on only a few servers that can scale well for high loads. However, these servers are often concentrated in some region of the world and therefore do not provide comparable resilience, connectivity or response time.

Multi-provider strategy

Although every DNS provider guarantees 100% availability, history shows that nobody is safe and anyone can fail, be it due to human error, technical failures or just a new DDoS traffic record.

Using a second DNS provider might double costs but removes the single point of failure. Additionally, DNS provider costs are usually negligible in the overall IT operational budget. Alternatively, contract a DNS provider and continue operating one or more authoritative name servers yourself.

Conclusion

Treat your domain name as a critical resource, not as an add-on service. Without a robust and resilient DNS solution, your business might lose customers and your operations could be seriously hampered. Therefore, segregate your authoritative DNS from other applications and services and invest in resilience and robustness.

REFERENCES

Scroll to Top