Post

DNS In Detail

DNS In Detail

What Even Is DNS?

So think about it this way. You know how your phone has contacts? You don’t memorize your friend’s phone number, you just search for their name and your phone handles the rest. DNS is exactly that, but for the Internet.

Every device on the Internet has an IP address. Something like 93.184.216.34. Nobody wants to type that every time they want to visit a website. So instead, you type example.com, and DNS figures out what IP address that maps to. Simple concept, but the machinery behind it is actually pretty fascinating.

DNS stands for Domain Name System, and it is one of the most critical pieces of infrastructure on the Internet. If DNS breaks, the whole Internet feels broken, even though technically the servers are still up and running fine. You just can’t find them.

DNS Resolution Flow How your browser finds a website - DNS sits in the middle of every request

Domain Hierarchy

Before we get into how DNS resolves names, you need to understand how domain names are actually structured. They are hierarchical, and they are read from right to left.

Take mail.google.com. as an example:

1
2
3
4
.               <-- Root (the dot at the end, usually hidden)
com             <-- Top-Level Domain (TLD)
google          <-- Second-Level Domain (SLD)
mail            <-- Subdomain

Root Level

This is the very top of the tree. It is represented by a single dot (.). You never actually type it, but it is there. Every domain name technically ends with a dot. Your browser just hides it.

Top-Level Domains (TLDs)

These are what come right after the root. There are two flavours:

  • gTLDs (Generic TLDs): .com, .org, .net, .edu, .gov, .io, .dev etc. Originally these had specific purposes (.edu for education, .gov for government) but .com became a free-for-all.
  • ccTLDs (Country Code TLDs): .uk, .us, .ng, .de, .jp etc. These are tied to specific countries, though many have been repurposed (.io is technically British Indian Ocean Territory, .ly is Libya, yet tech companies love them).

Second-Level Domain (SLD)

This is the part you register. google in google.com. tryhackme in tryhackme.com. This is the actual brand or name.

Subdomains

Anything to the left of the SLD is a subdomain. mail.google.com has mail as a subdomain. www.google.com has www. You can chain multiple subdomains together like one.two.three.google.com, though there is a limit. The full domain name cannot exceed 253 characters, and each label (each part between dots) cannot exceed 63 characters.

Record Types

DNS is not just one thing. It stores multiple types of data, and each type has a specific purpose. These are called Resource Records.

A Record

Maps a domain name to an IPv4 address. This is the most common record type.

1
example.com.    300    IN    A    93.184.216.34

The 300 is the TTL (Time To Live) in seconds. It tells resolvers how long to cache this answer.

AAAA Record

Same as an A record, but for IPv6 addresses. IPv6 looks like 2606:2800:220:1:248:1893:25c8:1946. As IPv4 addresses continue to run out globally, AAAA records are becoming increasingly important.

CNAME Record

CNAME stands for Canonical Name. It is an alias. Instead of pointing to an IP, it points to another domain name.

1
www.example.com.    300    IN    CNAME    example.com.

This means www.example.com is an alias for example.com. The resolver then goes and looks up example.com to get the actual IP. You cannot have a CNAME at the root of a domain (so no CNAME for example.com itself, only for subdomains). This is a common point of confusion.

MX Record

MX stands for Mail Exchange. This tells email servers where to deliver email for a domain.

1
example.com.    300    IN    MX    10    mail.example.com.

The 10 is the priority. Lower numbers have higher priority. If you have multiple mail servers, you can set priorities so email goes to the primary server first and falls back to a secondary if the primary is down.

TXT Record

TXT records let domain owners store arbitrary text. They are heavily used for email security:

  • SPF (Sender Policy Framework): Specifies which mail servers are allowed to send email on behalf of your domain. Helps fight spoofing.
  • DKIM (DomainKeys Identified Mail): Stores a public key used to verify email signatures.
  • DMARC: Tells receiving mail servers what to do when SPF or DKIM checks fail.

TXT records are also used for domain ownership verification (like when you add a site to Google Search Console).

NS Record

NS stands for Name Server. These records delegate a DNS zone to specific authoritative name servers.

1
2
example.com.    86400    IN    NS    ns1.example.com.
example.com.    86400    IN    NS    ns2.example.com.

This is how the TLD server knows which name server to send resolvers to when someone asks about example.com.

PTR Record

This is the reverse of an A record. Instead of resolving a name to an IP, it resolves an IP to a name. Used in reverse DNS lookups. Particularly useful for verifying that a mail server’s IP actually belongs to the domain it claims to be from.

SOA Record

SOA stands for Start of Authority. Every DNS zone has exactly one SOA record. It contains administrative information about the zone: the primary name server, the email of the domain admin, and timing values for zone transfers and caching.

SRV Record

SRV records specify the location of services. They include the port number and the protocol. Used by things like SIP (VoIP), XMPP (messaging), and other protocols that need to advertise where their service runs.

How a DNS Request Actually Works

This is where it gets interesting. Let’s trace exactly what happens when you type google.com into your browser.

Step 1: Local Cache

Your computer checks its local DNS cache first. If you visited google.com recently, the answer is probably already stored and you get it instantly. On Windows you can see your local cache with ipconfig /displaydns.

Step 2: The Recursive Resolver

If there is no cached answer, the query goes to your recursive resolver. This is typically your ISP’s DNS server, or a public one you have configured like 8.8.8.8 (Google) or 1.1.1.1 (Cloudflare). The recursive resolver does all the heavy lifting on your behalf.

Step 3: Root Server

If the recursive resolver does not have the answer cached either, it asks one of the 13 root server clusters (labeled A through M, like a.root-servers.net). The root server does not know the IP of google.com, but it knows where to find the .com TLD servers.

Step 4: TLD Name Server

The recursive resolver now asks the .com TLD name server. It still does not know the IP of google.com, but it knows which name servers are authoritative for google.com. It responds with those NS records.

Step 5: Authoritative Name Server

The recursive resolver queries one of Google’s authoritative name servers. This server has the actual answer. It responds with the A record: 142.250.190.78 (or similar, Google uses multiple IPs).

Step 6: The Answer Returns

The recursive resolver caches the answer (for the duration of the TTL) and sends it back to your computer. Your computer also caches it. Your browser connects to the IP.

The whole process typically takes milliseconds. And once it is cached, subsequent lookups are even faster.

DNS in Security

DNS is a gold mine from a security perspective. Both attackers and defenders pay close attention to it.

DNS as an Attack Vector

  • DNS Spoofing / Cache Poisoning: An attacker poisons a resolver’s cache with a fake DNS record. When a user tries to visit bank.com, they get sent to the attacker’s server instead. DNSSEC was designed to prevent this.
  • DNS Tunneling: Attackers can exfiltrate data or establish C2 (Command and Control) channels through DNS queries. Since DNS traffic is rarely blocked, it is a sneaky way to move data out of a network.
  • DNS Hijacking: Attacker modifies DNS settings at the router level or on the authoritative server itself to redirect traffic.
  • NXDOMAIN Attacks: Flooding a DNS server with queries for non-existent domains to cause a denial of service.

DNS as a Defender’s Tool

  • DNS Sinkholes: Security teams redirect known malicious domains to a controlled IP address. Instead of letting malware call home, you catch the request and log it.
  • Passive DNS: Logging historical DNS resolution data. Useful for threat intelligence and incident investigation.
  • DNS-layer Filtering: Services like Cisco Umbrella sit at the DNS level and block malicious domains before a connection is even made.

Practical: Let’s Look at DNS Live

You can do all of this right now. Open a terminal.

Basic lookup with nslookup (works on Windows and Linux):

1
nslookup google.com

More detailed lookup with dig (Linux/Mac, or install it on Windows):

1
dig google.com
1
2
3
4
5
6
7
8
9
10
11
12
13
# Ask for a specific record type
dig google.com MX
dig google.com TXT
dig google.com NS

# Query a specific DNS server directly
dig @8.8.8.8 google.com

# Do a reverse lookup (PTR record)
dig -x 8.8.8.8

# Trace the full resolution path from root servers
dig +trace google.com

The dig +trace command is the most educational one. It shows you exactly what we walked through above: the root server response, the TLD server response, and then the authoritative answer. Run it and watch it unfold.

Check your local DNS cache on Windows:

1
ipconfig /displaydns

Flush your local DNS cache:

1
ipconfig /flushdns

This is useful when a website’s IP has changed but your machine is still using the old cached value.

A Real Scenario

Let’s say a company called SecureCorp launches a new email domain, securecorp.io. Their IT team needs to set up DNS correctly. Here is what they configure:

RecordTypeValuePurpose
securecorp.ioA203.0.113.50Main website
www.securecorp.ioCNAMEsecurecorp.ioAlias for www
mail.securecorp.ioA203.0.113.51Mail server IP
securecorp.ioMX 10mail.securecorp.ioEmail routing
securecorp.ioTXTv=spf1 ip4:203.0.113.51 -allSPF email security
securecorp.ioNSns1.securecorp.ioName servers

Without the MX record, email to @securecorp.io addresses would fail. Without SPF, other mail servers would likely reject or spam-flag their outbound emails. DNS is not just about loading websites. It is the foundation of how email, services, and applications find each other on the Internet.


That is DNS. Once you understand it, you start seeing it everywhere, in every protocol, every tool, every attack. It is one of those fundamentals that pays back dividends the deeper you go into security or networking.

This post is licensed under CC BY 4.0 by the author.

Trending Tags