The Domain Name System (DNS) is one of the most important computer services we have, one that makes possible the internet as we know it and use it today. In principle, DNS is easily explained – the most common analogy is that it is like a phone book (of the internet). If you want to call someone but you don’t know their number, because numbers are harder to remember than names, you look them up in the phone book. You search until you find the name, and there you find the corresponding telephone number. In this analogy, the name of the person is replaced by the domain name, the telephone number becomes the IP address, and the telephone book itself is the Domain Name System. So if you want to call up www.scip.ch, you have to find the IP address of the underlying network participant (the www.scip.ch web server). The operating system asks DNS for the relevant IP address. You can find a good brief introduction into the way DNS functions at learndns.com.

Things get more complicated at the technical level, where DNS becomes a science in itself. Bear in mind that the DNS is expected to index many millions of websites worldwide (2014 saw the billion barrier broken) and to pair each one up with an IP address. This ensures that each internet participant gets the right IP address precisely when they need it. DNS makes this happen through a decentralized, hierarchical structure. A DNS query is raised via a resolver, also known as a recursive DNS server. This has a number of domain names in its cache, which it can use to respond immediately to the requester. Any domain name that is not stored in the resolver cache is found using the hierarchical DNS structure. The resolver queries one of the 13 root name servers. This points to a name server that administers the TLD (top-level domains), such as .ch or .net. The parts of the domain name between the periods are also known as zones, so in resolving www.scip.ch the root name server will pass the request on to the name server for the ch. zone. This in turn knows the name server for the scip. zone, which, finally, knows the IP address for www.scip.ch and transfers it in a response to the requester.

DNS in a company context

From a company’s perspective, domain names have become a valuable commodity. They enable the company’s internet presence for marketing purposes, or concrete applications like online stores. Viewed from a company perspective, one might well ask: how can customers find our products and brands or use our services if not through the internet and a corresponding domain name address? Attempting to answer this question should make it clear to many companies just how important an internet presence – and, in particular, its availability and thus the DNS – actually are.

The fact that there is a relationship of trust between the customer or user and the domain name opens up another interesting perspective. This leads us to issues like online banking, e-government and e-health. Users simply trust in the fact that they are actually communicating with their health insurer’s server, say, when they log on to www.MyHealthInsurer.example to upload confidential data (e.g. claims documentation, diagnoses, etc.). Here it is only entering the correct domain name and perhaps the “look and feel” of the website that help verify that it is actually the genuine website for the insurer.

With these thoughts about DNS in mind, or the possibility of making a service known to the public via a domain name on the internet, a company must treat its own domain name as a valuable commodity which it is obliged to protect. So the issue of DNS should be duly included in any risk and IT considerations. The potential for attacks and fraud that come with DNS is well known.

Attacks with DNS

Below, we present some typical attacks and possible mitigation measures involving DNS.

Distributed reflection DoS attack

The distributed reflection DoS attack exploits the fact that some open resolvers respond to every DNS query they receive. An attacker can send multiple DNS queries with spoofed IP addresses (those of its attack targets). This means that the resolver’s response isn’t sent to the original requester but, rather, to the IP address that the attacker included in the phony DNS query. What’s more, the size of the request data packet sent to the resolver is significantly smaller than the response “returned” to the attack target, so the attack volume of the DoS attack is multiplied via the intermediary step of the resolver. This is what is meant by a reflected or amplified attack technique, because the attack is reflected or amplified by the resolver. For the attack to succeed, the spoofed DNS queries must be sent not just to one but to numerous open resolvers, in order to generate the largest possible volume of DNS responses. This is where the distributed part of the term comes from.

The 2013 Spamhouse incident offers an idea of the scope of DDoS attacks via DNS. In that case, attackers used methods such as DNS amplification to flood the Spamhouse server with 75 Gbps. It should be noted that amplification is used less these days thanks to IoT botnets, as millions of IoT devices are brought together as a botnet, meaning that amplification is no longer necessary. One example is the botnet Mirai, which in late 2016 was able to unleash an attack of over 620 Gbps on the servers of its targets.

⇒ YouTube Video

While companies cannot directly thwart DDoS attacks, redundant systems and UTM firewalls can significantly reduce the risk of DDoS attacks on components with exposure to the internet. Further methods of defense include logging, monitoring, and meaningful alerts of activity at the system’s perimeter. This can help IT admins respond quickly and correctly to attacks, launch appropriate measures, and also inform customers, partners, and members of staff if necessary.

The nature of these attacks therefore also demands measures on the part of DNS and “internet” (ISP) operators. Through various configuration measures, the potential for DDoS attacks can be minimized. Of course, the first step should be to securely configure unnecessary open resolvers. Operating a DNS service for a company doesn’t have to mean responding to every DNS query from every random internet participant. DNS operators can also implement RRL (response rate limiting), which is included with some of the popular DNS software. With this configuration, the DNS server is instructed to only allow a certain volume of identical DNS responses to a given IP address area. Once the limit is exceeded, the DNS server cancels any further identical DNS responses. For the root of the attack – the possibility of distributing DNS queries with spoofed IP addresses – solutions have also been in place for some time. One option is BCP38, which is described in RFC2827. BCP38 is designed to prevent IP packets with phony IP addresses from “entering” the internet in the first place (ingress filtering).

DNS Hijacking

DNS hijacking refers to cases where attackers display a domain name on an IP address of their choice. This means that websites can be made essentially inaccessible or internet users misdirected to phony websites for the purpose of stealing information such as access data for online banking. Options for pointing a domain name to a false IP address include:

Phony DNS server

Should an attacker manage to change the default DNS server entry on a computer or a DNS server, it would give them control over all DNS queries that the user makes from this system. This means that attackers could define the IP address that they want any domain name to point to. This type of manipulation often occurs after infection with malware, which can be implanted in a computer system via various different routes.

One method for countering these problems is to ensure that anti-virus programs are always up to date, that adequate hardening is carried out on the system, and that users are sufficiently aware of cyber risks.

DNS Cache Poisoning

DNS cache poisoning occurs when an attacker exploits the DNS server’s buffer. The buffer holds DNS entries in its cache for a predefined period (time to live, or TTL). This occurs for performance reasons, i.e. so that not every single DNS query has to be resolved by the entire DNS hierarchy. After the TTL has expired, there is a very brief interval in which this DNS server no longer knows which IP address to allocate for a given domain. The DNS therefore queries another DNS server for the corresponding IP. If the attacker is then able to communicate a false DNS response with a false IP address allocation in the time between the DNS query and the DNS response of this server, this entry is once more stored in the DNS server’s cache until the TTL has expired again. This means that the DNS server’s cache is poisoned by the false DNS entry. Users who then query this DNS server for the IP of this domain receive a false IP address, and instead of arriving at their intended destination, they come to a server which is controlled by the attacker. This technique only functions if the DNS requester doesn’t use authenticated DNS responses among the DNS servers involved.

When the cache of the DNS server is poisoned, it can also lead to a trickle-down effect, as other DNS servers adopt the false DNS entry. This means that this false DNS entry can “trickle” down to the local DNS cache of computers and network devices.

There are various different and complementary measures that can help reduce the risk of cache poisoning. It is important to ensure that patches for the DNS software used are completely up to date. DNS servers can also be configured in such a way that they maintain a strict trust relationship, making it harder for attackers to implant false DNS entries. TTL values can also be kept to a minimum and the cache of local computers and network components deleted at regular intervals. DNSSEC helps minimize the risk of cache poisoning. DNSSEC signs DNS information to verify that the originator of this DNS information is trustworthy. Finally, you can verify whether an IP address really does belong to the desired domain name and hasn’t been manipulated by an attacker. This only functions if the whole chain of name resolution (from root to complete name resolution of the name) is signed using DNSSEC.

DNS Tunneling

DNS tunneling isn’t an attack on the DNS in the classic sense. Because DNS must be available to anyone who wishes to resolve a domain name, many firewalls allow DNS traffic (port 53) to pass. Attackers can use this fact to exfiltrate data or implement command & control callbacks in networks that have already been infiltrated. A further use of DNS tunneling is in bypassing captive portal services (paid internet access), e.g. for hotels and these days even for in-flight wifi services. Here the desired form of communication can be hidden, such as via TCP packets in DNS traffic. The iodine tool can be used for this.

There are various techniques for preventing data flow through DNS tunneling without blocking DNS traffic entirely. One is to monitor the firewall for unusual DNS communications, such as high volumes of DNS packets to the same recipient, or analyzing the content of DNS packets. This can be achieved through deep packet inspection (DPI), although this is resource-intensive. Blacklisting of unknown recipients, or whitelisting of known recipients, are further options. The important thing here, it would seem, is that admins are immediately informed of unusual behavior, and/or that firewalls and security appliances are configured with corresponding block rules. Blocking DNS traffic from internal hosts to the internet is also possible, but this requires running a local DNS internally.

Conclusion

The risks, attack methods, and measures described here represent a mere glimpse into the world of DNS. One thing is certain: it is vital that companies whose business models rely on the internet get to grips with the issue of DNS security. In recent years, the relevance of DNS security has only grown. Major enterprises have long been aware of the risks posed by DNS.

But SMEs should not underestimate the risks either, and they are advised to talk to their IT partners or departments about DNS-related risks. Here it is important to clarify whether, and to what extent, the company’s business model is dependent on DNS. Where there are dependencies, such as if the company’s products are offered exclusively through the internet, it makes sense to keep up to date with the security status of the DNS used. In general, it is possible to ask the host which techniques are used to protect the domain, but also to check with the ISP about techniques used to counter DNS cache poisoning and DDoS.

Where companies operate their own DNS servers, adequate hardening, regular software updates of the DNS server, and a secure configuration (not forgetting open resolvers) are essential.

About the Author

Dominik Altermatt is working since 2003 in the IT business and was responsible for Data Leakage Prevention at a Swiss bank for many years. Besides traditional penetration testing he is also focusing on the introduction and improvement of IT security management processes. (ORCID 0000-0003-4575-4597)

Links

• http://www.learndns.com
• http://www.redbarn.org/dns/ratelimits
• https://github.com/yarrick/iodine
• https://www.bcp38.info
• https://www.helpnetsecurity.com/2017/10/03/companies-unprepared-dns-attacks/
• https://www.iana.org/domains/root/servers
• https://www.icann.org/resources/pages/dnssec-qaa-2014-01-29-also
• https://www.internetlivestats.com/total-number-of-websites/
• https://www.theguardian.com/technology/2016/oct/26/ddos-attack-dyn-mirai-botnet