DNS Explained

DNS Explained

By How we write our guides

DNS is the address book of the internet. Every time a browser, command-line tool, or application connects to a hostname, it first performs a DNS lookup to find the IP address. Understanding how this works and how to query and debug it is an essential networking skill.

How DNS resolution works

When you connect to linuxdork.com, the following happens:

  1. Your application calls getaddrinfo("linuxdork.com") (or equivalent)
  2. The OS checks its local cache
  3. The OS checks /etc/hosts for a static entry
  4. If not found, the OS queries the recursive resolver configured in /etc/resolv.conf
  5. The recursive resolver checks its cache; if no cached answer exists, it performs iterative resolution:
    • Asks a root nameserver (there are 13 sets): “Who handles .com?”
    • Asks the .com TLD nameserver: “Who is authoritative for linuxdork.com?”
    • Asks the authoritative nameserver for linuxdork.com: “What is the A record for linuxdork.com?”
  6. The answer is returned to your OS, cached per the record’s TTL, and the connection proceeds
# Trace a full DNS resolution step by step
dig +trace linuxdork.com

DNS record types

Each DNS record type stores a different kind of information about a domain.

TypePurposeExample
AIPv4 addressexample.com -> 93.184.216.34
AAAAIPv6 addressexample.com -> 2606:2800::1946
CNAMEAlias to another namewww.example.com -> example.com
MXMail serverexample.com mail -> mail.example.com priority 10
TXTArbitrary textSPF, DKIM, domain verification
NSAuthoritative nameserversexample.com NS ns1.example.com
SOAZone authority metadataSerial, refresh, retry, expire times
PTRReverse DNS (IP to name)34.216.184.93.in-addr.arpa -> example.com
SRVService location_https._tcp.example.com -> host:port priority weight
CAACertificate Authority AuthorizationWhich CAs may issue TLS certs

dig: the primary DNS query tool

dig is the standard tool for querying DNS. It produces detailed output including the full answer, TTL values, and which server responded.

# Basic A record lookup
dig linuxdork.com

# Short answer only
dig linuxdork.com +short

# Query a specific record type
dig linuxdork.com A
dig linuxdork.com AAAA
dig linuxdork.com MX
dig linuxdork.com TXT
dig linuxdork.com NS
dig linuxdork.com SOA
dig linuxdork.com CAA

# Query a specific DNS server (bypass your configured resolver)
dig @8.8.8.8 linuxdork.com
dig @1.1.1.1 linuxdork.com
dig @ns1.example.com linuxdork.com    # query authoritative directly

# Reverse DNS lookup (IP to hostname)
dig -x 8.8.8.8
dig -x 8.8.8.8 +short

# Trace the full resolution chain
dig +trace linuxdork.com

# Show all records for a zone (AXFR zone transfer, usually restricted)
dig axfr example.com @ns1.example.com

# Multiple queries in one command
dig linuxdork.com A linuxdork.com MX

Reading dig output

; <<>> DiG 9.18.1 <<>> linuxdork.com
;; QUESTION SECTION:
;linuxdork.com.        IN   A

;; ANSWER SECTION:
linuxdork.com.  300    IN   A    76.76.21.21

;; Query time: 12 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Sat Jun 28 10:00:00 UTC 2026
;; MSG SIZE  rcvd: 58
  • QUESTION SECTION: what was asked
  • ANSWER SECTION: the result. 300 is the TTL in seconds.
  • SERVER: which resolver answered

nslookup: simpler queries

nslookup is older and less detailed than dig, but available on most systems including Windows.

# Basic lookup
nslookup linuxdork.com

# Query a specific server
nslookup linuxdork.com 8.8.8.8

# Query a specific record type
nslookup -type=MX linuxdork.com
nslookup -type=TXT linuxdork.com

# Interactive mode
nslookup
> server 1.1.1.1
> set type=MX
> linuxdork.com
> exit

host: the quickest lookups

host is the most concise DNS tool for quick checks:

# Forward lookup
host linuxdork.com

# Reverse lookup
host 8.8.8.8

# Specific record type
host -t MX linuxdork.com
host -t TXT linuxdork.com

# Query a specific nameserver
host linuxdork.com 1.1.1.1

resolvectl: systemd-resolved management

On systems using systemd-resolved, resolvectl provides status information and cache management:

# Show DNS configuration per interface
resolvectl status

# Show active DNS servers
resolvectl dns

# Perform a lookup through systemd-resolved
resolvectl query linuxdork.com
resolvectl query -t MX linuxdork.com

# Flush the DNS cache
sudo resolvectl flush-caches

# Show cache statistics
resolvectl statistics

# Show DNS search domains
resolvectl domain

DNS configuration files

# Resolver configuration: which DNS servers to query
cat /etc/resolv.conf
# nameserver 1.1.1.1
# nameserver 8.8.8.8
# search home.local

# On systemd-resolved systems, this may be a symlink
ls -la /etc/resolv.conf
# -> /run/systemd/resolve/stub-resolv.conf  (uses 127.0.0.53)
# -> /run/systemd/resolve/resolv.conf       (uses real DNS servers)

# Static hostname entries (checked before DNS)
cat /etc/hosts

# Resolution order (hosts vs DNS)
grep hosts /etc/nsswitch.conf
# hosts: files dns myhostname

Common DNS record tasks

Checking SPF, DKIM, and DMARC

# SPF record (who can send email for this domain)
dig TXT linuxdork.com +short | grep spf

# DKIM record (email signature public key)
dig TXT selector._domainkey.linuxdork.com +short

# DMARC policy
dig TXT _dmarc.linuxdork.com +short

Verifying domain ownership records

# Google Search Console, Let's Encrypt, and similar services
# add TXT records for verification
dig TXT linuxdork.com +short

# CAA records (which CAs can issue TLS certs)
dig CAA linuxdork.com +short

Reverse DNS (PTR records)

# Check if an IP has a reverse DNS entry
dig -x 76.76.21.21 +short
host 76.76.21.21

# Reverse DNS is managed by the IP block owner (usually your hosting provider)
# PTR records live in the .in-addr.arpa zone (IPv4) or .ip6.arpa (IPv6)

Common DNS problems and how to diagnose them

# "Name does not resolve" -- check the basics
ping linuxdork.com                   # does resolution work at all?
dig linuxdork.com                    # check for errors in the answer
dig @8.8.8.8 linuxdork.com           # bypass local resolver
cat /etc/resolv.conf                 # check nameserver config
resolvectl status                    # check systemd-resolved status

# "Wrong IP returned" -- cache or propagation issue
dig linuxdork.com +short             # what does your resolver say?
dig @ns1.linuxdork.com linuxdork.com # what does authoritative say?
sudo resolvectl flush-caches         # clear local cache and retry

# "Email not delivering" -- check MX records
dig MX linuxdork.com
dig TXT linuxdork.com | grep spf

# "NXDOMAIN but I just added the record" -- TTL propagation
dig SOA linuxdork.com                # check the SOA TTL
# Records take time to propagate; the old TTL must expire on all caches

Frequently Asked Questions

What is DNS and what does it do?

DNS (Domain Name System) is a distributed database that maps human-readable domain names to IP addresses. When you type google.com into a browser, your computer queries a DNS server to get the IP address (e.g., 142.250.80.46) before it can connect. Without DNS, you would need to remember the IP address of every website and service you use. DNS also stores other information about a domain, including mail server addresses (MX records), text verification records, and IPv6 addresses.

How does DNS resolution work?

When you look up a domain, your system first checks its local cache and the /etc/hosts file. If not found, it queries your configured recursive resolver (often your ISP or a public resolver like 1.1.1.1). The resolver checks its own cache, and if it does not have a current answer, it performs iterative resolution: it asks a root nameserver which TLD nameserver is authoritative for the domain, then asks that TLD server which nameserver is authoritative for the specific domain, then asks that authoritative nameserver for the final answer. The result is cached according to the TTL value in the DNS record.

What is the difference between A and AAAA records?

An A record maps a domain name to an IPv4 address (e.g., example.com -> 93.184.216.34). An AAAA record maps a domain name to an IPv6 address (e.g., example.com -> 2606:2800:220:1:248:1893:25c8:1946). The name AAAA comes from the fact that an IPv6 address is four times the size of an IPv4 address. Most domains have both record types to support dual-stack clients. When a client looks up a domain, it typically requests both types simultaneously and prefers the IPv6 address if one is available.

What is a DNS TTL?

TTL (Time To Live) is a value in seconds attached to every DNS record that tells resolvers how long to cache the record before re-querying the authoritative server. A TTL of 3600 means the record can be cached for one hour. Low TTLs (60-300 seconds) allow quick propagation of changes but increase load on authoritative servers. High TTLs (86400 seconds = 1 day) reduce query volume but mean changes take longer to propagate. Before making changes to DNS records, it is good practice to lower the TTL in advance to reduce the propagation delay.

What is the difference between a recursive resolver and an authoritative nameserver?

An authoritative nameserver holds the definitive records for a domain. When you register a domain and configure DNS, the records you set are stored on your authoritative nameservers. A recursive resolver (also called a recursive or full-service resolver) is the DNS server your computer queries directly. It does the work of following the chain from root to TLD to authoritative server on your behalf, caches the results, and returns the final answer. Your ISP, Google (8.8.8.8), and Cloudflare (1.1.1.1) operate recursive resolvers. Route 53 and Cloudflare DNS also operate authoritative nameservers for hosted zones.

How do I flush the DNS cache on Linux?

On systemd-resolved systems (most modern Ubuntu, Fedora, and Debian installations), run sudo resolvectl flush-caches. On systems using nscd, run sudo systemctl restart nscd. On systems using dnsmasq, run sudo systemctl restart dnsmasq. There is no single universal command because Linux does not have a built-in system-wide DNS cache in the kernel — caching is done by whichever resolver daemon is running. Applications like Firefox also maintain their own DNS caches, which must be flushed separately.

Related articles

Unbound: Running Your Own Recursive DNS ResolverPi-hole filters. A forwarder caches. Unbound resolves from the root servers itself, which means no provider sees your queries at all. Setup, DNSSEC, and the one setting that makes it feel slow when it is not.systemd-resolved Explained: Why /etc/resolv.conf Is a Symlink NowWhat systemd-resolved does, why 127.0.0.53 appears in resolv.conf, how split DNS works, and how to actually configure or disable it.Pi-hole and Network-Wide DNS FilteringBlocking ads at the DNS layer covers every device on the network including the ones that cannot run an extension. Here is how it works, what it cannot do, and how to avoid making yourself the network outage.