DNS Related

1. DNS

The Domain Name System (DNS) is the phonebook of the Internet. Humans access information online through domain names, like nytimes.com or espn.com. Web browsers interact through Internet Protocol (IP) addresses. DNS translates domain names to IP addresses so browsers can load Internet resources.

DNS resolution process

  1. DNS query: A user types 'example.com' into a web browser and the query travels into the Internet and is received by a DNS recursive resolver.
  2. Root nameserver: The resolver then queries a DNS root nameserver (.).
  3. TLD nameserver: The root server then responds to the resolver with the address of a Top Level Domain (TLD) DNS server (such as .com or .net), which stores the information for its domains. When searching for example.com, our request is pointed toward the .com TLD.
  4. Authoritative nameserver: The TLD server then responds with the IP address of the domain's nameserver, example.com.
  5. DNS resolver: Lastly, the recursive resolver sends a query to the domain's nameserver.
  6. IP address: The IP address for example.com is then returned to the resolver from the nameserver.
  7. DNS resolver response: The DNS resolver then responds to the web browser with the IP address of the domain requested initially.
  8. Browser request: Once the 8 steps of the DNS lookup have returned the IP address for example.com, the browser is able to make the request for the web page.
  9. Web server response: The browser makes a HTTP request to the IP address.
  10. Page display: The server at that IP returns the webpage to be rendered in the browser.

DNS record types

  • A record: The record that holds the IP address of a domain. Learn more about the A record.
  • AAAA record: The record that contains the IPv6 address for a domain (as opposed to A records, which list the IPv4 address). Learn more about the AAAA record.
  • CNAME record: Forwards one domain or subdomain to another domain, does NOT provide an IP address. Learn more about the CNAME record.
  • MX record: Directs mail to an email server. Learn more about the MX record.
  • TXT record: Lets an admin store text notes in the record. These records are often used for email security. Learn more about the TXT record.
  • NS record: Stores the name server for a DNS entry. Learn more about the NS record.
  • SOA record: Stores admin information about a domain. Learn more about the SOA record.
  • SRV record: Specifies a port for specific services. Learn more about the SRV record.
  • PTR record: Provides a domain name in reverse-lookups. Learn more about the PTR record.

2. DNS caching

The purpose of caching is to temporarily stored data in a location that results in faster data retrieval for future requests. DNS caching involves storing data closer to the requesting client so that the DNS query can be resolved earlier and additional queries further down the DNS lookup chain can be avoided, thereby improving load times and reducing bandwidth/CPU consumption. DNS data can be cached in a variety of locations, each of which will store DNS records for a set amount of time determined by a time-to-live (TTL).

Browser DNS caching

Modern web browsers are designed by default to cache DNS records for a set amount of time. The purpose here is obvious; the closer the DNS caching occurs to the web browser, the fewer processing steps must be taken in order to check the cache and make the correct requests to an IP address. When a request is made for a DNS record, the browser cache is the first location checked for the requested record.

Operating system (OS) level DNS caching

The operating system level DNS resolver is the second and last local stop before a DNS query leaves your machine. The process inside your operating system that is designed to handle this query is commonly called a "stub resolver" or DNS client. When a stub resolver gets a request from an application, it first checks its own cache to see if it has the record. If it does not, it then sends a DNS query (with a recursive flag set), outside the local network to a DNS recursive resolver inside the Internet service provider (ISP).

Recursive resolver DNS caching

When a recursive resolver receives a DNS query, like all previous steps, it will check to see if the requested host-to-IP-address translation is already stored inside its local persistence layer. The recursive resolver also has additional functionality depending on the types of records it has in its cache:

  • If the resolver does not have the A records, but does have the NS records for the authoritative nameservers, it will query those name servers directly, bypassing several steps in the DNS query. This shortcut prevents lookups from the root and .com nameservers (in our search for example.com) and helps the resolution of the DNS query occur more quickly.
  • If the resolver does not have the NS records, it will send a query to the TLD servers (.com in our case), skipping the root server.
  • In the unlikely event that the resolver does not have records pointing to the TLD servers, it will then query the root servers. This event typically occurs after a DNS cache has been purged.

3. DNS security

DNS spoofing/cache poisoning

DNS spoofing is a type of cyber attack that exploits DNS server vulnerabilities to divert traffic away from legitimate servers towards fake ones. One of the reasons DNS spoofing is so dangerous is because it can spread from DNS server to DNS server. A common result of DNS spoofing is DNS cache poisoning, which occurs when a DNS server's cache is corrupted with false information.

DNS tunneling

DNS tunneling utilizes the DNS protocol to communicate non-DNS traffic over port 53. It sends HTTP and other protocol traffic over DNS. There are various, legitimate reasons to utilize DNS tunneling. However, there are also malicious reasons to use DNS tunneling VPN services. They can be used to disguise outbound traffic as DNS, concealing data that is typically shared through an internet connection. For malicious use, DNS requests are manipulated to exfiltrate data from a compromised system to the attacker's infrastructure. It can also be used for command and control callbacks from the attacker's infrastructure to a compromised system.

DNS hijacking

DNS hijacking is the practice of redirecting DNS queries to different nameservers. This can be accomplished via malware that overrides a computer's TCP/IP configuration to point at a rogue DNS server under the control of an attacker, or through modifying the behavior of a trusted DNS server so that it does not comply with internet standards.

NXDOMAIN attack

An NXDOMAIN attack is a type of DNS flood attack where an attacker inundates a DNS server with requests for invalid or non-existent records. The attack's goal is to cause a denial of service for legitimate traffic by consuming DNS server resources with lookups for records that don't exist. NXDOMAIN attacks can also target recursive resolvers with the goal of filling up the resolver's cache with junk requests.

Phantom domain attack

A phantom domain attack is similar to an NXDOMAIN attack in its goal of consuming resolver resources. Phantom domain attacks set up a number of 'phantom' domain servers which either respond to requests very slowly or not at all. The resolver is then hit with a flood of requests to these domains, creating a backlog of requests that can tie up the resolver's resources and degrade performance for legitimate requests.

Random subdomain attack

In a random subdomain attack, the attacker sends DNS queries for various random, non-existent subdomains of one or more legitimate sites. The goal is to create a denial of service for the domain's authoritative nameserver, making it impossible to lookup the website from the nameserver. As a side effect, the ISP serving the attacker may also be impacted as their recursive resolver's cache becomes filled with bad requests.

Domain lock-up attack

In a domain lock-up attack, the attacker sets up malicious domains with nameservers that respond very slowly to requests. When a resolver requests the malicious domains, the nameserver responds slowly, which ties up the resolver's resources waiting for a response and can eventually lead to denial of service as the resolver's capacity to respond to other requests becomes impaired.

Botnet-based CPE attack

In a botnet-based CPE attack, the attacker uses a botnet to generate massive amounts of DNS requests from customer premise equipment (CPE) devices like home routers towards a victim's authoritative server. Because the requests are coming from legitimate IP addresses of real users, it becomes difficult to block the attack traffic without also blocking legitimate users.