Guideline for a fail-safe DNS
17.07.2023 00:00

The DNS (Domain Name System) is the basis for all services on the internet. It is necessary for all domain-based services to find the IP address of the relevant server. This includes for example the website of your company, the webshop, 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. Below, enterprises and Internet Service Providers will find helpful tips and tricks on how to set up their DNS infrastructure to make it even more secure.

 

 

Separate 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. For example if the domain is used for a web shop, this is of course bad as you miss customers. But if the domain is also used for the company e-mail, or to address company internal resources, the whole company is affected and employees cannot work anymore. This can mean not only financial damage but also damages to the image of the company.

 

So, if your company is called "Example Ltd. ", you may use www.example.com for your website, and @example.com for your e-mail communication. But for your internal resources you should consider using a dedicated zone, for example "example-infra.com" to address your routers, servers and internal services. If this is not possible due to legacy issues, you should make sure that, even if your public authoritative name servers are not available, the domain still resolves inside your company network. For this, you could use for example "split-DNS", 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
When talking about 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 webshops. But attackers are smart, and try to attack everything that may hurt the victim. These targets also includes e-mail servers, authoritative name servers, the internet connection of the company and routers of the company’s network. So, all these targets must be addressed when considering DDoS protection.

 

Take a look at banks or retail shops: Most of them have a front door and a back door. At the front door, the doors are wide open and every potential customer is welcome. At the back door, only employees are allowed. They need to have a key to open the door, or will be controlled by dedicated security personal. And often there are delivery entrances too. Regardless what happens in front of the shop (e.g. storm of customers on Black Friday sale), the employees can enter the shop and can do their work in the back office.

 

In the early days of IT, a company had a common used internet connectivity and a common used network for public and internal services. Hence, DDoS attacks (or customer storms) against the company website could overload the internet connection and network of the company. While most enterprises host their websites now outside of the company networks, using ISPs or cloud services, many enterprises still self-host their DNS and e-mail in their own network. Hence, a dedicated attack against the authoritative name servers will traverse the company’s internet connection, their internal networks and possible several firewalls.

 

Even if the name server is capable of handling the attack, the internet connection may suffer, firewalls may get overloaded and the whole company network breaks although only the name servers were attacked. Conversely, an attack against some other parts of the company’s network may overload the internet connection and the name servers are not available any more. Although in that scenario the company’s web-shop is still working fine, internet users fail to resolve the e-shops domain name because of an unrelated attack.

 

The authoritative name service can be compared to the leaflet of a retail shop. These leaflets are located at the front entrance, or often also outside in front of the shop – never in the back office.

 

So, put your public authoritative name servers into the public, not in your internal company network. Locate them at some internet service provider, or in the cloud, or use DNS services of specialized DNS service providers like RcodeZero DNS.

 

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 too.

 

 

Avoid firewalls and load balancers in front of name services
The purpose of a firewall is to control access to certain resources. The public authoritative DNS is public, so there is no usage of 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 out performs a dedicated firewall and save resources on the expensive enterprise firewalls.

 

 

DNSSEC for end2end validation
Nowadays end2end protection for services mostly uses application layer security, for example TLS for https protected websites. But there are still services with end2end security, like e-mail. Hence, e-mail is still vulnerable to man-in-the-middle attacks, which may try to use DNS spoofing. The only available technology preventing DNS spoofing is DNSSEC. Although a solution does exist the bad news is that DNSSEC is still complicated and error prone.

 

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. RcodeZero DNS comes with free DNS DNSSEC support.

 

 

Use a Unix based operating system
We recommend to use a Unix based operating system and well known trusted name servers like Bind, NSD, Knot or PowerDNS. Also, remember to continuously update your name server software. Alternatively, if you do not want to have that work, use a DNS provider like RcodeZero DNS who supports you.

 

 

Use a Multi Provider Strategy
Where do you host your savings? All within the same bank, or do you distribute your money to several banks? Although every DNS provider guarantees 100 % availability, as we do, history shows that nobody is safe and anyone can fail, due to human error, technical failures or just a new DDoS traffic record.

 

Using a second DNS provider of course doubles the DNS provider costs, but DNS provider costs are usually negligible in your IT-security budget. Or you use a DNS provider but still operate one DNS yourself. Our Anycast service RcodeZero DNS can be used as Primary DNS or Secondary DNS.

 

Conclusion
If you are looking for a trustworthy DNS provider for your DNS infrastructure, you can rely on our long-standing expertise and ensure the reachability of your domains with the same technology we use and develop for nic.at – our sister company and the official .at domain registry. Our Anycast service RcodeZero DNS is ideal for companies and internet service providers. We offer different products adapted to your needs. Contact us at rcodezero@ipcom.at or test our service for 30 days for free.