Introduction
When you type a website address into your browser, a lot happens before you see anything on screen. Your computer needs to figure out which IP address corresponds to that hostname. That translation is handled by DNS, the Domain Name System. It is a distributed, hierarchical database that the entire internet depends on, and understanding it is essential for anyone working in networking or security.
DNS Record Types
Every line in a DNS zone file is a record. The most common ones are A records, which map a hostname to an IPv4 address; AAAA records, which do the same for IPv6; CNAME records, which point one hostname to another hostname; MX records, which specify which mail server handles email for a domain; and NS records, which indicate which DNS server is authoritative for a domain. There are others, but these are the ones you encounter most often.
How Resolution Works
DNS is hierarchical. At the top are the root DNS servers, there are 13 of them named A through M, though each one has many physical instances distributed around the world using a technique called anycast. Below the root are top-level domain servers for things like .com, .ca, and .edu. Below those are the authoritative servers for individual domains.
When you ask your local DNS server to resolve www.cnn.com, if it does not have the answer cached, it goes through a lookup chain. It first asks a root server, which tells it which TLD server handles .com. It then asks that .com TLD server, which points it to CNN's own authoritative DNS server. That server knows the actual IP address and sends it back. Your DNS server caches the result and returns it to you.
Your query to the local DNS server is a recursive query, you are asking it to go figure out the answer and come back. The queries the DNS server makes along the way to root and TLD servers are iterative, each one says "I do not know, but try asking this server next."
Caching and TTL
Once a DNS server resolves a hostname, it caches the result so it does not have to repeat the whole lookup for every request. Each DNS record has a Time to Live value set by the authoritative server. That TTL tells other servers how long to keep the cached record before discarding it and looking it up fresh. A long TTL reduces DNS traffic but means changes propagate slowly. A short TTL means faster propagation but more frequent lookups.
Your own computer also has a local DNS cache. On Windows, you can view it with ipconfig /displaydns. This cache is separate from the DNS server's cache and follows the same TTL rules.
UDP and TCP in DNS
Most DNS queries use UDP because it is fast and lightweight, and most responses fit within 512 bytes. When a response is too large for UDP, the server sets a truncated flag in the reply and the client resends the query over TCP to get the full answer. TCP is also used for zone transfers, where a backup DNS server pulls a full copy of a domain's zone data from the primary server. Zone transfers involve large amounts of data, so the reliability of TCP is appropriate there.
Zone Transfers and Security
Zone transfers are meant to keep backup DNS servers in sync with the primary. A backup server contacts the primary on port 53 over TCP, requests all the DNS records for a zone, and stores them locally. The problem is that if a DNS server is misconfigured to allow zone transfers from any IP address, an attacker can query it and get a complete map of all hostnames and IP addresses in the domain. That is a serious information leak and a common penetration testing target.
The fix is straightforward: configure your DNS server to only allow zone transfers from known backup server IP addresses and deny everyone else.
Reverse DNS Lookups
A normal DNS query takes a hostname and returns an IP address. A reverse lookup does the opposite, it takes an IP address and finds the associated hostname. This uses a special domain structure under .in-addr.arpa, where IP addresses are written in reverse. To look up the hostname for 12.33.247.6, you query 6.247.33.12.in-addr.arpa.
Tools like traceroute use reverse lookups automatically to show you hostnames for each hop rather than just IP addresses. That is also why traceroute can be slow, it is waiting for reverse DNS responses. You can skip that with traceroute -n on Linux or tracert -d on Windows.
DNS Cache Poisoning
DNS cache poisoning is an attack where an attacker tricks a DNS server into caching a false record. For example, an attacker might cause a DNS server to associate a legitimate banking domain with a malicious IP address. Users who query that poisoned server would then be sent to the wrong site without any obvious warning.
The attack typically exploits the window of time between when a DNS server sends a query and when it receives a response. By flooding the server with forged replies that contain the right transaction ID before the real response arrives, an attacker can get the false record accepted. DNSSEC was designed to address this by cryptographically signing DNS records, though adoption has been uneven.
DNS as a Reconnaissance Tool
Attackers use DNS actively during reconnaissance. Tools like nslookup and dig can enumerate records, probe for mail servers, and attempt zone transfers against misconfigured servers. Some DNS record types like HINFO were historically used to document what hardware and OS a server was running, which is exactly the kind of information you do not want an attacker to have for free.
Even querying a DNS server for its software version can help an attacker identify vulnerable versions of BIND or other DNS software. A well-hardened DNS server should either return a generic version string or nothing at all.
Conclusion
DNS is one of the most critical pieces of internet infrastructure. The hierarchical resolution process, caching with TTL, zone transfers, reverse lookups, and the various record types all build on each other. For defenders and attackers alike, DNS is a rich source of information and a meaningful attack surface. Understanding how it works is not optional knowledge, it is foundational.