DNS: The Silent Killer Nobody Thinks About Until the Outage.

The server is running. The app is responding. The database is alive. But the site has been down for two hours and the support queue is overflowing. You check the monitoring — everything is green. You check the nginx logs — silence, not a single request coming in. Then it hits you: the problem isn’t the server. The problem is that nobody is reaching the server at all.

DNS. Again DNS.

It’s the system you configure on day one and forget for years. Until the next outage at 3 a.m.

HOW DNS WORKS — NO FLUFF

DNS is the internet’s phone book. You know the name, DNS knows the number. The browser knows the domain, DNS returns the IP.

When a user types example.com, a chain of events begins:

1. The browser checks its local cache. If it resolved this recently — it uses that.
2. If not — it asks the system resolver (your router, your ISP’s DNS, or 1.1.1.1 if you’ve configured it).
3. The resolver doesn’t know — it goes to the root servers. There are 13 of them, and they know everything at the top level.
4. The root servers say: “The .com servers handle that.”
5. The .com TLD servers say: “These nameservers handle example.com.”
6. The domain’s nameservers return the final IP.
7. The browser finally connects to the server.

This whole journey takes 20–150 milliseconds. On the first request. After that the answer is cached.

This is where TTL — Time To Live — comes in. It’s the number of seconds a cached answer stays valid. TTL = 3600 means everyone gets the cached answer for an hour without touching your nameservers. Sounds like an optimization — and it is. But TTL is also the main source of pain when you need to change something urgently.

DNS RECORD TYPES: WHAT DOES WHAT

Most people know the A record and stop there. That’s like knowing only first gear — you can move, but slowly and wrong.

A record maps a domain to an IPv4 address. The most basic one. example.com → 192.0.2.1 (IP reserved for documentation per RFC 5737).

AAAA record — same thing for IPv6. In 2026, ignoring IPv6 means deliberately cutting off part of your audience.

CNAME record — an alias. www.example.com points to example.com rather than directly to an IP. Convenient: change one A record, all CNAMEs follow automatically. Important caveat: CNAME cannot be placed on the root domain (apex). Subdomains only. Otherwise you’ll break MX and NS. Some DNS providers work around this with their own extensions — ALIAS or ANAME — but that’s their internal magic.

MX record tells the internet where to deliver email for the domain. Without it, messages just get lost somewhere. MX has a priority — lower number means higher priority. Multiple MX records with different priorities give you mail redundancy.

TXT record — a dumping ground for text data. Domain verification for Google, AWS, Cloudflare. SPF, DKIM, DMARC. All of it lives in TXT. Unstructured, but flexible.

NS record specifies which nameservers are authoritative for the zone. This is the most security-critical record: if an attacker changes NS — they get full control over your DNS.

PTR record — reverse DNS. IP → domain. Mail servers always check PTR when receiving a message. No PTR — message goes to spam or gets rejected. Configured at your hosting provider, not your registrar.

CAA record restricts which certificate authorities can issue SSL certificates for your domain. One line — and no outside CA can issue a certificate for your domain, even if they can prove domain control by other means.

SRV record describes a specific service: protocol, host, port, priority. Used in VoIP, corporate messaging systems, some game servers.

SOA — Start of Authority. A metadata record for the zone: primary nameserver, admin email, serial number for secondary server synchronization. Rarely touched, but worth knowing.

HOW DNS KILLS SERVICES — REAL SCENARIOS

This isn’t theory. This is what happens regularly.

DNS provider goes down. Your server is in perfect shape. But the DNS zone is hosted at a registrar that had an outage overnight. Nobody can resolve the domain. For users, the site is dead — even though it’s running and waiting for connections. In October 2021, a BGP misconfiguration took down Facebook, Instagram and WhatsApp for more than seven hours. Technically the servers were running. But the BGP routes to Facebook’s DNS servers were withdrawn, DNS stopped responding, and billions of users saw a blank screen.

TTL wasn’t lowered before the migration. You’re moving to a new server. Your A record TTL is 86400 — one day, as many registrars default to. You update the record, but half the world still hits the old IP for 24 hours. If the old server is already off — those users don’t exist for you anymore. The solution is simple and well-known: two days before the migration, drop TTL to 300. After the move — bring it back up.

No automatic failover. The primary server went down. The backup is up and waiting. But DNS still points to the dead IP, because “setting up failover” was always something to do later. Later arrived on Friday evening.

Domain hijacking. An attacker gains access to the registrar account — through a leaked password, phishing, or a panel vulnerability. Changes the NS records to their own. Now they control your DNS. They can redirect traffic, issue an SSL certificate for your domain, intercept email. Your servers are alive, your code is untouched — but the service is effectively under their control. In 2019, the Sea Turtle campaign worked exactly this way — actors with alleged Iranian affiliation compromised registrars and DNS providers, then intercepted traffic from governments and telecoms across more than 13 countries. Cisco Talos called it “the first publicly confirmed case of a DNS registrar being compromised.”

Cache poisoning. An attacker injects fake DNS responses into a resolver’s cache. Users get a spoofed IP and end up at the attacker’s server, thinking it’s yours. The attack has been known since the 1990s. Solved by DNSSEC — but many still haven’t enabled it.

Subdomain takeover. You decommission a service — an S3 bucket, a Heroku app, GitHub Pages — but forget to remove the CNAME record from DNS. The record sits there pointing to a resource that no longer exists. An attacker registers that resource under their own account, and your subdomain now serves their content. Trivial attack, detected automatically by scanners. Easy to check: audit all CNAME records in your zone and confirm each one actually resolves to something live.

DNS amplification. A server with an open resolver can become a weapon in someone else’s hands. Here’s how it works: the attacker wants to take down a victim, but instead of attacking directly they use your DNS as an amplifier. They send a small request (60 bytes) with the victim’s IP spoofed as the source — DNS runs over UDP, where there’s no handshake and source IPs are trivial to forge. Your resolver dutifully responds with a large packet (3000+ bytes) — but not to the attacker, to the victim, because that’s the IP in the request.

That’s where the up-to-50x amplification factor comes from: the ratio of response size to request size. The attacker spent 1 Mbps of their own bandwidth — the victim received 50 Mbps. ANY queries and TXT records for DNSSEC-enabled domains produce especially large responses — cryptographic signatures bloat the packet size significantly.

If you’re running an open resolver, your server is participating in attacks on others. Your hosting provider gets abuse reports, your IP reputation drops, your bandwidth gets consumed by someone else’s traffic. Millions of open resolvers across the internet are used exactly this way. Check whether you have one:

dig @YOUR_IP example.com

If it responds — close recursion for external addresses in your bind/unbound config, or block port 53 on the firewall for all addresses except your own networks.

An open resolver is a DNS server that answers recursive queries from any IP on the internet, not just its own clients. A normal resolver serves only its own network. An open one answers everyone — which is exactly what makes it useful as an amplification weapon.

Three ways to close it. Via nftables — the simplest approach, no need to touch the DNS server itself:

nft add rule inet filter input udp dport 53 \
    ip saddr != { 127.0.0.1, 10.0.0.0/8, 192.168.0.0/16 } drop

Via bind — disable recursion at the config level:

# /etc/named.conf
options {
    recursion yes;
    allow-recursion { 127.0.0.1; 10.0.0.0/8; };
};

Via unbound:

# /etc/unbound/unbound.conf
server:
    access-control: 0.0.0.0/0 refuse
    access-control: 127.0.0.1/32 allow
    access-control: 10.0.0.0/8 allow

If you’re not running a public DNS server — just block port 53 on the firewall for all external addresses and stop thinking about it.

WHAT NOBODY WRITES ABOUT

DNSSEC has existed since 2005. It adds a cryptographic signature to DNS responses — the resolver can verify that the answer is genuine and not a forgery. In 2026, a significant portion of domains still run without DNSSEC. The “it’s complicated to set up” argument is long dead: Cloudflare enables DNSSEC with a single button click.

DNS is transmitted in plain text. Always. Your ISP sees every domain you resolve. Corporate firewalls too. Anyone sitting between you and your resolver sees the full list of domains — no hacking required, just passive traffic sniffing.

DNS over TLS (DoT) and DNS over HTTPS (DoH) solve this in different ways, but with the same goal — encrypt the DNS query so nobody can read it in transit.

Why does this matter? DNS is the one protocol that can’t be blocked. Port 53 is open everywhere — otherwise nothing works. That’s exactly why unencrypted DNS is a hole that everyone ignores.

Your ISP, your hosting provider, a corporate firewall, or anyone on the same network can see every domain your server contacts. Requests to external APIs, to package repositories, to monitoring systems — all of it is intelligence gathering without a single exploit, just passive listening.

Unencrypted DNS can be tampered with in transit. A packet that looks like a legitimate DNS response gets accepted by the resolver, and the user ends up somewhere they didn’t intend to go. That’s how DNS man-in-the-middle attacks work. With DoT/DoH, tampering is impossible: the connection is encrypted and authenticated by certificate.

Finally: ISPs and corporate networks block domains through DNS. DoH bypasses this because the request is indistinguishable from regular HTTPS traffic.

DoT runs on port 853 and wraps standard DNS in a TLS connection. Clean and straightforward, but easy to block — just close port 853 on the firewall.

DoH runs on port 443 — the same port as regular HTTPS. DNS queries look like ordinary web requests. Blocking it without breaking all HTTPS is practically impossible.

Browsers — Firefox, Chrome, Edge — support DoH out of the box. Firefox uses Cloudflare 1.1.1.1 by default, bypassing the system DNS. Chrome and Edge work differently: they upgrade the system DNS to DoH if the provider supports it, but don’t bypass the system resolver. On a server, you need to configure this explicitly regardless.

On a Linux server, the easiest way to enable DoT is via systemd-resolved:

# /etc/systemd/resolved.conf
[Resolve]
DNS=1.1.1.1#cloudflare-dns.com 9.9.9.9#dns.quad9.net
DNSOverTLS=yes

Or via stubby for more granular control:

apt install stubby          # Debian/Ubuntu
dnf install stubby          # RHEL/Fedora

# /etc/stubby/stubby.yml — key parameters:
# resolution_type: GETDNS_RESOLUTION_STUB
# dns_transport_list: GETDNS_TRANSPORT_TLS
# tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
# upstream_recursive_servers: 1.1.1.1, 9.9.9.9

After that, stubby listens on 127.0.0.1:53 and proxies all queries over TLS. Set nameserver 127.0.0.1 in /etc/resolv.conf — and all system DNS traffic goes out encrypted.

DNS tunneling — transmitting arbitrary data inside DNS packets. The firewall blocks everything except DNS on port 53. But DNS traffic is always allowed — otherwise nothing works. And that’s exactly the channel malware uses to send commands and exfiltrate data. Hard to detect: the DNS queries look normal, there are just a lot of them and the domain names are suspiciously long.

Registrar and DNS provider are different things. You bought the domain from a registrar, and by default they also host your DNS zone. Convenient, but it creates a single point of failure. If the registrar goes down — DNS goes down with it. The smarter setup: domain at the registrar, DNS zone at Cloudflare or another dedicated provider with a real SLA.

Anycast — when a single IP address is served from multiple locations around the world simultaneously. Cloudflare, Google Public DNS, and other major DNS providers all work this way. A query from Singapore goes to the nearest datacenter, not across the Atlantic. Resolution takes single-digit milliseconds. Cloudflare’s network in 2026 covers 300+ cities in 100+ countries. A single nameserver on a VPS in Germany won’t come close.

Zone transfer (AXFR) — the mechanism for synchronizing DNS zones between primary and secondary nameservers. Useful, but if not restricted by IP — anyone can download the complete list of all your DNS records with a single command. Every subdomain, every internal service, every IP address — a ready-made infrastructure map for pre-attack reconnaissance. Test it:

dig @ns1.example.com example.com AXFR

If it returns records — you have an open zone transfer. In your nameserver configuration, restrict AXFR to the IP addresses of your secondary servers only.

Split-horizon DNS — when the same domain returns different answers depending on who’s asking. Inside the network: db.example.com → 10.0.0.5 (internal IP). From outside: NXDOMAIN, as if the domain doesn’t exist. Used to hide internal infrastructure from the outside world: only public services are visible externally, internal ones are invisible. Implemented via bind views or a separate internal DNS server with its own zones.

HOW TO CONFIGURE DNS CORRECTLY

TTL — the last thing people think about and the first thing that bites them. Simple rule: keep it at 3600 for stable records. Drop it to 300 at least 48 hours before any planned changes. After the change is done — bring it back up. This is the only way to switch traffic quickly without hours of waiting for caches to expire.

Two nameservers — the minimum, not the target. One NS is a single point of failure. Registrars require at least two, but more is better, across different networks and geographic regions. Cloudflare gives you two NS records for free — but thanks to anycast they’re served from 300+ locations worldwide, which is more reliable than four regular nameservers on separate VPS instances.

2FA at your registrar — not optional. Domain hijacking through a compromised registrar account happens regularly. 2FA stops the majority of these cases. If your registrar doesn’t support 2FA — change registrars.

CAA record — one line that closes an entire class of attacks. Example:

example.com. CAA 0 issue "letsencrypt.org"

Now only Let’s Encrypt can issue a certificate for your domain. Any other CA will refuse — even if someone proves domain control through other means.

SPF, DKIM, DMARC — the mandatory trio if you run email. SPF specifies which servers are allowed to send. DKIM signs messages cryptographically. DMARC tells receiving servers what to do with messages that fail checks — reject, quarantine, or just log. Without all three, your emails go to spam and attackers can send phishing messages from your domain.

Set up PTR if you’re running your own mail server. Check it with:

dig -x YOUR_IP +short

It should return your mail server’s hostname. Configured at your hosting provider, not your registrar.

DNS record monitoring — what everyone forgets. Server monitoring is set up. SSL certificate monitoring is set up. But if your domain’s A record suddenly changes — nobody will know until users start complaining. UptimeRobot, Zabbix, or any dedicated DNS monitor handles this with five minutes of setup.

Registry lock — protection against unauthorized domain transfer to another registrar. Without it, gaining access to the registrar account is enough to transfer the domain within hours. Registry lock requires manual confirmation of any transfer through a separate channel. Available at most major registrars, often free. For production domains — mandatory.

QUICK AUDIT: RUN THIS NOW

Open a terminal and run your domain through these checks:

# Current DNS records
dig example.com A
dig example.com MX
dig example.com NS
dig example.com CAA
dig example.com TXT

# Reverse DNS for your mail server
dig -x YOUR_IP +short

# DNSSEC check
dig example.com +dnssec

# Open resolver — should NOT respond
dig @YOUR_IP example.com

# Open zone transfer — should NOT return records
dig @ns1.example.com example.com AXFR

# Global propagation check
# dnschecker.org or whatsmydns.net

What should be in place:
— A record points to the correct IP
— TTL is reasonable (not 86400 by default)
— At least two NS records from different networks
— CAA record exists
— MX is configured, PTR matches your mail server hostname
— SPF, DKIM, DMARC in TXT records
— DNSSEC enabled
— 2FA active at the registrar
— Registry lock enabled
— Zone transfer restricted to authorized IPs
— No open resolver
— All CNAME records point to live resources
— DNS record monitoring is configured

CONCLUSION

DNS has one job: get users to your server. If DNS is broken — it doesn’t matter how good the server is. Nobody reaches it.

Yet DNS is one of the most underestimated parts of any infrastructure. Configured at launch, forgotten immediately. Meanwhile it quietly becomes a point of failure, an attack vector, and the source of day-long delays during migrations.

One hour of auditing. TTL, NS, CAA, SPF/DKIM/DMARC, registrar 2FA, record monitoring. None of it is complicated. It just rarely gets done — until the first outage.