About DNS
DNS is a system for resolving computer names into IP addresses, and it does not have a central database. The information is distributed over many thousands of name servers. Globally distributed DNS servers translate domain names into IP addresses and thus control which server a user can reach via a particular domain. There are several types of DNS servers that are used worldwide:
| Server Type | Description |
|---|---|
DNS Root Server | The root servers of the DNS are responsible for the top-level domains (TLD). As the last instance, they are only requested if the name server does not respond. Thus, a root server is a central interface between users and content on the Internet, as it links domain and IP address. The Internet Corporation for Assigned Names and Numbers (ICANN) coordinates the work of the root name servers. There are 13 such root servers around the globe. |
Authoritative Nameserver | Authoritative name servers hold authority for a particular zone. They only answer queries from their area of responsibility, and their information is binding. If an authoritative name server cannot answer a client’s query, the root name server takes over at that point. Based on the country, company, etc., authoritative nameservers provide answers to recursive DNS nameservers, assisting in finding the specific web server(s). |
Non-authoritative Nameserver | Non-authoritative name servers are not responsible for a particular DNS zone. Instead, they collect information on specific DNS zones themselves, which is done using recursive or iterative DNS querying. |
Caching DNS Server | Caching DNS servers cache information from other name servers for a specified period. The authoritative name server determines the duration of this storage. |
Forwarding Server | Forwarding servers perform only one function: they forward DNS queries to another DNS server. |
Resolver | Resolvers are not authoritative DNS servers but perform name resolution locally in the computer or router. |
DNS is useful for hackers because it stores and outputs additional information about the services associated with a domain, such as the email server for the domain in question.
DNS encryption
By default, DNS is not encrypted. However, IT security professionals apply DNS over TLS (DoT) or DNS over HTTPS (DoH) here. In addition, the network protocol DNSCrypt also encrypts the traffic between the computer and the name server.
DNS records (types)
| DNS Record | Description |
|---|---|
A | Returns an IPv4 address of the requested domain as a result. |
AAAA | Returns an IPv6 address of the requested domain. |
MX | Returns the responsible mail servers as a result. |
NS | Returns the DNS servers (nameservers) of the domain. |
TXT | This record can contain various information. The all-rounder can be used, e.g., to validate the Google Search Console or validate SSL certificates. In addition, SPF and DMARC entries are set to validate mail traffic and protect it from spam. |
CNAME | This record serves as an alias for another domain name. If you want the domain www.hackthebox.eu to point to the same IP as hackthebox.eu, you would create an A record for hackthebox.eu and a CNAME record for www.hackthebox.eu. |
PTR | The PTR record works the other way around (reverse lookup). It converts IP addresses into valid domain names. |
SOA | Provides information about the corresponding DNS zone and email address of the administrative contact. |
dig SOA
dig the soa record to see who is responsible for the operation of the domain and how DNS information is managed. Note that in the example below, the “@” is replaced with a dot in the email address. Thus awsdns-hostmaster.amazon.com is really awsdns-hostmaster@amazon.com.
dig soa www.inlanefreight.com
; <<>> DiG 9.16.27-Debian <<>> soa www.inlanefreight.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15876
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.inlanefreight.com. IN SOA
;; AUTHORITY SECTION:
inlanefreight.com. 900 IN SOA ns-161.awsdns-20.com. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400
;; Query time: 16 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Jan 05 12:56:10 GMT 2023
;; MSG SIZE rcvd: 128DNS configuration
All DNS servers work with three different types of configuration files. Options not listed in named.conf have default values.
- local DNS configuration files (typically named.conf.local, named.conf.options, named.conf.log)
- zone files
- reverse name resolution files
zone file
A zone file is a text file that describes a DNS zone with the BIND file format. In other words it is a point of delegation in the DNS tree. The BIND file format is the industry-preferred zone file format and is now well established in DNS server software.
cat /etc/bind/db.domain.com
;
; BIND reverse data file for local loopback interface
;
$ORIGIN domain.com
$TTL 86400
@ IN SOA dns1.domain.com. hostmaster.domain.com. (
2001062501 ; serial
21600 ; refresh after 6 hours
3600 ; retry after 1 hour
604800 ; expire after 1 week
86400 ) ; minimum TTL of 1 day
IN NS ns1.domain.com.
IN NS ns2.domain.com.
IN MX 10 mx.domain.com.
IN MX 20 mx2.domain.com.
IN A 10.129.14.5
server1 IN A 10.129.14.5
server2 IN A 10.129.14.7
ns1 IN A 10.129.14.2
ns2 IN A 10.129.14.3
ftp IN CNAME server1
mx IN CNAME server1
mx2 IN CNAME server2
www IN CNAME server2For the IP address to be resolved from the Fully Qualified Domain Name (FQDN), the DNS server must have a reverse lookup file. In this file, the computer name (FQDN) is assigned to the last octet of an IP address, which corresponds to the respective host, using a PTR record. The PTR records are responsible for the reverse translation of IP addresses into names, as we have already seen in the above table.
cat /etc/bind/db.10.129.14
;
; BIND reverse data file for local loopback interface
;
$ORIGIN 14.129.10.in-addr.arpa
$TTL 86400
@ IN SOA dns1.domain.com. hostmaster.domain.com. (
2001062501 ; serial
21600 ; refresh after 6 hours
3600 ; retry after 1 hour
604800 ; expire after 1 week
86400 ) ; minimum TTL of 1 day
IN NS ns1.domain.com.
IN NS ns2.domain.com.
5 IN PTR server1.domain.com.
7 IN MX mx.domain.com.
...SNIP...Footprinting DNS
The DNS server can be queried as to which other name servers are known. We do this using the NS record and the specification of the DNS server we want to query using the @ character.
dig ns inlanefreight.htb @10.129.14.128
; <<>> DiG 9.16.1-Ubuntu <<>> ns inlanefreight.htb @10.129.14.128
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45010
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: ce4d8681b32abaea0100000061475f73842c401c391690c7 (good)
;; QUESTION SECTION:
;inlanefreight.htb. IN NS
;; ANSWER SECTION:
inlanefreight.htb. 604800 IN NS ns.inlanefreight.htb.
;; ADDITIONAL SECTION:
ns.inlanefreight.htb. 604800 IN A 10.129.34.136
;; Query time: 0 msec
;; SERVER: 10.129.14.128#53(10.129.14.128)
;; WHEN: So Sep 19 18:04:03 CEST 2021
;; MSG SIZE rcvd: 107Sometimes it is also possible to query a DNS server’s version using a class CHAOS query and type TXT. However, this entry must exist on the DNS server.
dig CH TXT version.bind 10.129.120.85
; <<>> DiG 9.10.6 <<>> CH TXT version.bind
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47786
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; ANSWER SECTION:
version.bind. 0 CH TXT "9.10.6-P1"
;; ADDITIONAL SECTION:
version.bind. 0 CH TXT "9.10.6-P1-Debian"
;; Query time: 2 msec
;; SERVER: 10.129.120.85#53(10.129.120.85)
;; WHEN: Wed Jan 05 20:23:14 UTC 2023
;; MSG SIZE rcvd: 101We can use the option ANY to view all available records. This will cause the server to show us all available entries that it is willing to disclose. It is important to note that not all entries from the zones will be shown.
dig any inlanefreight.htb @10.129.14.128
; <<>> DiG 9.16.1-Ubuntu <<>> any inlanefreight.htb @10.129.14.128
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7649
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 2
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 064b7e1f091b95120100000061476865a6026d01f87d10ca (good)
;; QUESTION SECTION:
;inlanefreight.htb. IN ANY
;; ANSWER SECTION:
inlanefreight.htb. 604800 IN TXT "v=spf1 include:mailgun.org include:_spf.google.com include:spf.protection.outlook.com include:_spf.atlassian.net ip4:10.129.124.8 ip4:10.129.127.2 ip4:10.129.42.106 ~all"
inlanefreight.htb. 604800 IN TXT "atlassian-domain-verification=t1rKCy68JFszSdCKVpw64A1QksWdXuYFUeSXKU"
inlanefreight.htb. 604800 IN TXT "MS=ms97310371"
inlanefreight.htb. 604800 IN SOA inlanefreight.htb. root.inlanefreight.htb. 2 604800 86400 2419200 604800
inlanefreight.htb. 604800 IN NS ns.inlanefreight.htb.
;; ADDITIONAL SECTION:
ns.inlanefreight.htb. 604800 IN A 10.129.34.136
;; Query time: 0 msec
;; SERVER: 10.129.14.128#53(10.129.14.128)
;; WHEN: So Sep 19 18:42:13 CEST 2021
;; MSG SIZE rcvd: 437Zone transfer
Zone transfer refers to the transfer of zones to another server in DNS, which generally happens over TCP port 53. This procedure is abbreviated Asynchronous Full Transfer Zone (AXFR). Since a DNS failure usually has severe consequences for a company, the zone file is almost invariably kept identical on several name servers. When changes are made, it must be ensured that all servers have the same data. Synchronization between the servers involved is realized by zone transfer.
The slave fetches the SOA record of the relevant zone from the master at certain intervals, the so-called refresh time, usually one hour, and compares the serial numbers. If the serial number of the SOA record of the master is greater than that of the slave, the data sets no longer match.
dig axfr inlanefreight.htb @10.129.14.128
; <<>> DiG 9.16.1-Ubuntu <<>> axfr inlanefreight.htb @10.129.14.128
;; global options: +cmd
inlanefreight.htb. 604800 IN SOA inlanefreight.htb. root.inlanefreight.htb. 2 604800 86400 2419200 604800
inlanefreight.htb. 604800 IN TXT "MS=ms97310371"
inlanefreight.htb. 604800 IN TXT "atlassian-domain-verification=t1rKCy68JFszSdCKVpw64A1QksWdXuYFUeSXKU"
inlanefreight.htb. 604800 IN TXT "v=spf1 include:mailgun.org include:_spf.google.com include:spf.protection.outlook.com include:_spf.atlassian.net ip4:10.129.124.8 ip4:10.129.127.2 ip4:10.129.42.106 ~all"
inlanefreight.htb. 604800 IN NS ns.inlanefreight.htb.
app.inlanefreight.htb. 604800 IN A 10.129.18.15
internal.inlanefreight.htb. 604800 IN A 10.129.1.6
mail1.inlanefreight.htb. 604800 IN A 10.129.18.201
ns.inlanefreight.htb. 604800 IN A 10.129.34.136
inlanefreight.htb. 604800 IN SOA inlanefreight.htb. root.inlanefreight.htb. 2 604800 86400 2419200 604800
;; Query time: 4 msec
;; SERVER: 10.129.14.128#53(10.129.14.128)
;; WHEN: So Sep 19 18:51:19 CEST 2021
;; XFR size: 9 records (messages 1, bytes 520)Subdomain brute forcing
The individual A records with the hostnames can also be found out with the help of a brute-force attack.
for sub in $(cat /opt/useful/seclists/Discovery/DNS/subdomains-top1million-110000.txt);do dig $sub.inlanefreight.htb @10.129.14.128 | grep -v ';\|SOA' | sed -r '/^\s*$/d' | grep $sub | tee -a subdomains.txt;done
ns.inlanefreight.htb. 604800 IN A 10.129.34.136
mail1.inlanefreight.htb. 604800 IN A 10.129.18.201
app.inlanefreight.htb. 604800 IN A 10.129.18.15dnsenum is a utility that lets you brute force a DNS server. SUBDOMAIN in the example below is the zone in focus (e.g. ns.inlanefreight.htb).
dnsenum --dnsserver 10.129.209.49 --enum -p 0 -s 0 -o subdomains.txt -f /usr/share/seclists/Discovery/DNS/(a smal list).txt --threads 90 SUBDOMAIN.inlanefreight.htb
Types of DNS attacks
Let’s review different types of attacks and how they can affect your online presence.
Domain hijacking
This type of attack can involve changes in your DNS servers and domain registrar that can direct your traffic away from the original servers to new destinations.
Domain hijacking is often caused by a lot of factors related to exploiting a vulnerability in the domain name registrar’s system, but can also be achieved at the DNS level when attackers take control of your DNS records.
Once the bad guys have hijacked your domain name, it will probably be used to launch malicious activities such as setting up a fake page of payment systems like PayPal, Visa or bank institutions. Attackers will create an identical copy of the real website that records critical personal information such as email addresses, usernames, and passwords.
Fortunately, you can avoid this situation. Just take a look at our How to Prevent Domain Hijacking guide.
DNS flood attack
This is one of the most basic types of DNS attack. In this Distributed Denial of Service (DDoS), the attacker will hit your DNS servers.
The main goal of this kind of DNS flood is to simply overload your server so it cannot continue serving DNS requests, because the resolution of resource records is affected by all the hosted DNS zones.
This kind of attack is mitigated easily as the source often comes from one single IP. However, it can get difficult when it becomes a DDoS (Distributed Denial of Service) where hundred or thousand hosts are involved.
While a lot of requests will be instantly detected as malicious, a lot of legal requests will be made in order to confuse defense mechanisms. This makes the mitigation system job a little bit harder sometimes.
Distributed Reflection Denial of Service (DRDoS)
When it comes to DDoS, the rules change. As we told you before, in order to diffuse the source of the attack it will be distributed across a large number of hosts. The ultimate goal of any DDoS is to overload your network with a large number of packets or a large number of bandwidth-consuming requests, to either overload your network capacity or to exhaust your hardware resources.
What’s the difference between DDoS and DRDoS?
While a simple DDoS is the act of making any target unavailable by denying their online services with flood requests, the DRDoS is a little bit different, and often more effective.
A DRDoS attack will try to send requests from its own servers, and the trick lies in spoofing the source address that will be set to that of the targeted victim, which will cause all machines to reply back and flood the target.
This kind of attack often involves and is generated by botnets that run compromised systems or services that will be ultimately used to create the amplification effect and attack the target, as seen when KrebsOnSecurity was hit by DRDoS in 2016.
Cache poisoning
DNS cache poisoning, also known as DNS spoofing, is one of the most common DNS attacks that happen every day.
The trick in this kind of attack is pretty easy to understand. By exploiting system vulnerabilities, attackers will try to inject malicious data into your DNS resolvers’ cache. This is an attack technique often used to redirect victims to another remote server.
Once the cache poisoning attack is live and working, attackers will receive all the legitimate traffic in their own servers, that are often used to show phishing-based pages to steal personal information from visitors.
How does it work?
Most of the time it’s caused by vulnerable systems; opening spam emails containing malicious links can expose you to a system compromise, and ultimately get your DNS resolver cache modified to finally lead you to malicious websites — in order to steal your personal information or infect you with spyware, adware, viruses, etc.
DNS tunneling
This is a type of cyber attack used to include encoded data from other applications inside DNS responses and queries.
While this technique wasn’t originally created to attack hosts, but to bypass network controls, nowadays it is mostly used to perform remote attacks.
In order to perform DNS tunneling, attackers need to gain access to a compromised system, as well as access to an internal DNS server, a domain name and DNS authoritative server.
How does it work?
- The DNS client sends a request for a given domain name including the data encoded in the hostname.
- The DNS server answers back and a two-way connection is established between both parts.
- Now the attacker can transfer malicious data along with any DNS answer to gain remote access.
DNS hijack attack
While DNS spoofing is often confused with DNS hijacking as both happen at the local system level, they are two different types of DNS attacks.
Most of the time, DNS spoofing or cache poisoning just involves overwriting your local DNS cache values with fake ones so you can be redirected to a malicious website.
On the other hand, DNS hijacking (also known as DNS redirection) often involves malware infections in order to hijack this important system service. In this case, the malware hosted on the local computer can alter the TCP/IP configurations so they can point to a malicious DNS server, one that will eventually redirect the traffic to a phishing website.
This is one of the easiest ways to perform a DNS attack, as it doesn’t involve complicated techniques. Furthermore, there are a lot of automated scripts used by script kiddies to perform this type of attack.
Random subdomain attack
This is not the most frequent type of DNS attack, but it can happen from time to time on certain networks. Random subdomain attacks can often be labeled as DoS attacks, as their nature adheres to the same goal as common DoS.
In this case, attackers send a lot of DNS queries against a valid and existing domain name. However, the queries will not target the main domain name, but a lot of non-existing subdomains. The goal of this attack is to create a DoS that will saturate the authoritative DNS server that hosts the main domain name, and finally, cause the interruption of all DNS record lookups.
It’s an attack that’s hard to detect, as the queries will come from botnets from infected users who don’t even know they’re sending these types of queries, from what are ultimately legitimate computers.
NXDOMAIN attack
NXDOMAIN attacks are involved in DDoS attacks, as they often involve a huge number of remote DNS clients that will flood your DNS authoritative servers with queries targeting non-existing domains. As a consequence, this will cause a DNS recursion and NXDOMAIN answering back.
If you don’t conduct a regular DNS audit, remote attackers can see this as an attractive opportunity to perform malicious attacks against your networks.
The main goal of this attack is to make your DNS server spend time, software and hardware resources in illegitimate requests that will prevent and cause service failure for legitimates ones, as the DNS server cache will be totally filled with NXDOMAIN failure results.
Phantom domain attack
Phantom domain attacks are kind of similar to random subdomain attacks.
In this kind of attack, the bad guys attack your DNS resolver and force it to use up resources to resolve what we call “phantom” domains, as these domains will never answer back to the queries.
The goal of this attack is to let the DNS resolver server wait for the answer for a long time, eventually leading to failure or degraded DNS performance issues.
