DNS security means protecting the Domain Name System — the lookup layer that turns yourcompany.com into an IP address — from cache poisoning, spoofing, tunnelling, hijacking, and subdomain takeover. Attackers target DNS because it is trusted, rarely monitored, and almost always allowed straight through the firewall. Defending it requires DNSSEC, encrypted resolution (DoH/DoT), split-horizon design, continuous monitoring, registrar hardening, and disciplined cleanup of dangling records. Most Indian dev and ops teams treat DNS as "set it and forget it" — exactly the assumption attackers rely on.
Why DNS Is a Favourite Attack Surface
DNS was built in the 1980s for availability, not authentication. Every resolution — a laptop asking "where is api.yourbank.in" — is a plaintext UDP exchange that any on-path attacker can spoof, and every outbound port 53 packet is waved through by firewalls that block almost everything else. That combination makes DNS attractive for three goals: redirecting users to malicious infrastructure, hiding stolen data inside "normal-looking" lookups, and quietly taking over abandoned subdomains that still point at your brand.
For Indian SMBs and mid-market companies running e-commerce, fintech, or SaaS workloads, DNS compromise is rarely the headline breach — it is the invisible step before one. A poisoned cache redirects customers to a phishing clone of your login page. A tunnel exfiltrates customer PII a few bytes at a time, under the radar of DLP tools watching HTTP and email. A dangling CNAME left behind by a decommissioned marketing campaign gets claimed by an attacker and used to host malware under your own domain's reputation.
How DNS Resolution Actually Works — and Where It Breaks
Understanding the attack surface starts with the resolution path: a client asks a recursive resolver, which walks the hierarchy from root to TLD to authoritative nameserver, then caches the answer for the TTL. Each hop is a place trust can be forged or abused.
The two dotted paths above are where most real-world DNS attacks live: a forged reply racing the legitimate answer back to the resolver (poisoning), and a covert channel riding inside query and response fields (tunnelling).
Attack 1: DNS Cache Poisoning and Spoofing
Cache poisoning tricks a recursive resolver into storing a forged IP address for a legitimate domain. Because DNS traditionally runs over UDP with a 16-bit transaction ID as the only real anti-spoofing check, an attacker who can guess or brute-force that ID — and win the race against the real authoritative response — can plant a fake record. Once poisoned, every user behind that resolver is silently redirected until the TTL expires, which can be hours.
Modern variants combine poisoning with DNS spoofing on local networks (ARP spoofing plus a rogue DNS reply) to intercept traffic even on networks that use encrypted resolvers, if the client's DNS settings themselves aren't locked down. This is why source-port randomization and DNSSEC validation matter even inside otherwise well-segmented networks.
Know your vulnerabilities before attackers do
Run a free VAPT scan — takes 5 minutes, no signup required.
Book Your Free ScanAttack 2: DNS Tunnelling for Exfiltration and C2
DNS tunnelling encodes data — commands, stolen files, malware payloads — inside DNS queries and responses, typically using subdomains as the data-carrying field (base64chunk.exfil.attacker-domain.com). Because DNS resolution is almost never fully blocked or inspected the way HTTP/S is, tunnelling gives attackers a low-and-slow channel for command-and-control beaconing and data exfiltration that bypasses most perimeter controls and legacy DLP tools.
CERT-In has repeatedly flagged DNS tunnelling and abuse as a recurring technique in post-compromise activity, precisely because it hides inside traffic defenders assume is benign. The tell-tale signs are unusually long subdomain labels, high query volume to one unfamiliar domain, TXT/NULL record abuse, and query entropy unlike normal hostname patterns.
Attack 3: DNS Hijacking
DNS hijacking changes what a domain resolves to, but at a higher level than a single poisoned cache — commonly through a compromised registrar account, a stolen API key, or a coerced intermediary. Attackers who gain access to a domain's control panel can repoint nameservers or individual records wholesale, redirecting an entire domain's mail, web, and API traffic. Historically, attackers have hit high-value domains not by breaking cryptography, but by phishing or credential-stuffing the registrar login.
Router-level hijacking is the SMB-scale version: malware that rewrites a home or office router's DNS settings so every device on the network resolves through an attacker-controlled server, with no visible symptom beyond "the internet feels slightly wrong."
Attack 4: Subdomain Takeover
Subdomain takeover exploits dangling DNS records — a CNAME still pointing at old-campaign.herokuapp.com or staging.some-paas.net long after the underlying cloud resource was deleted. If an attacker claims that same resource name on the third-party platform, your subdomain now resolves to infrastructure they fully control, inheriting your domain's trust and reputation. Marketing microsites, decommissioned staging environments, and abandoned proof-of-concepts are the usual culprits — nobody remembers to delete the record when the resource is torn down.
This is one of the most common findings in real-world attack surface reviews, precisely because it requires zero exploitation skill — just a systematic sweep of every subdomain a company has ever created.
The Defence Stack: What Actually Works
No single control stops all four attack classes. DNS defence is layered, and each layer closes a different gap.
| Control | Stops | Notes |
|---|---|---|
| DNSSEC | Cache poisoning, spoofing | Cryptographically signs records; validate at the resolver, sign at the authoritative zone |
| DoH / DoT | On-path spoofing, ISP-level snooping | Encrypts the query itself; must be paired with endpoint policy so users can't bypass it |
| Split-horizon DNS | Internal reconnaissance | Serves different answers to internal vs external resolvers, hiding internal topology |
| DNS query monitoring | Tunnelling, C2 beaconing | Flag high-entropy subdomains, abnormal query volume, rare TLDs |
| Registrar hardening | Hijacking | MFA, registry lock, restricted IP access to the control panel |
| Dangling-record cleanup | Subdomain takeover | Continuous inventory of every CNAME/record against live cloud resources |
DNSSEC: Cryptographic Trust for Resolution
DNSSEC adds digital signatures to DNS records so a resolver can verify a response came from the authoritative source and wasn't forged in transit. NIST publishes detailed DNSSEC deployment guidance, and most ccTLD registries, including India's .in registry, support DNSSEC signing. The catch: DNSSEC must be enabled at both the authoritative zone (signing) and the resolver (validation) to matter — a signed zone queried by a non-validating resolver gets none of the protection.
.in or .com zone is DNSSEC-signed with a simple dig +dnssec query, or via any public DNSSEC-analyzer tool. Most companies discover it was never enabled at all.DoH and DoT: Encrypting the Query Itself
DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) encrypt the query/response exchange, closing the on-path spoofing and eavesdropping window plain UDP DNS leaves wide open. The trade-off: DoH in particular can make DNS traffic harder for the network team to inspect, since it looks like ordinary HTTPS traffic. Run DoH/DoT to a controlled, monitored internal resolver rather than letting every device pick its own public encrypted resolver — otherwise you gain confidentiality but lose visibility.
Split-Horizon DNS
Split-horizon (or split-brain) DNS serves different zone answers depending on whether the query originates internally or externally. It prevents external attackers from using DNS enumeration to map internal hostnames, IP ranges, and service names — reconnaissance that often precedes a targeted attack.
Continuous Monitoring
Effective DNS monitoring looks for anomalies, not signatures: spikes in NXDOMAIN responses (a sign of algorithmically generated domains used by malware), abnormally long or high-entropy query names, sudden shifts in which resolver a device uses, and query volume to domains registered days ago. This is the kind of pattern automated, continuous scanning is built to catch — treating DNS posture as something to check every scan cycle, not once a year.
Registrar and Domain-Control Hardening
Because DNS hijacking usually starts with a compromised registrar account, the fix is largely identity hygiene: multi-factor authentication on the registrar login, registry lock (a status that requires out-of-band verification before nameserver changes are accepted), restricted access to who can touch DNS records, and alerting on any nameserver or NS-record change.
Dangling-Record Cleanup
The fix is process, not technology: every time a cloud resource, PaaS app, or third-party integration is decommissioned, the corresponding DNS record must be deleted in the same change. A live inventory of every subdomain, cross-checked against active resources quarterly at minimum, closes the gap before an attacker finds it first.
Where DNS Fits in a Broader VAPT Programme
DNS misconfigurations — missing DNSSEC, dangling CNAMEs, permissive zone transfers, weak registrar access — are exactly the low-effort, high-impact findings a structured vulnerability assessment should surface first. Any organisation running a compliance programme under DPDP or a sector regulator like RBI or SEBI should expect DNS hygiene in the audit scope, not an afterthought. If your last security review skipped DNSSEC status, dangling records, and registrar access controls, it wasn't complete.
Building DNS Security Into Everyday Operations
Teams that avoid DNS incidents build hygiene into routine change management, not a single tool: every DNS change reviewed like a firewall rule, every decommissioned service triggering a record audit, every registrar account under MFA with an owner still on payroll. None of this is exotic — it's discipline applied to a layer that usually gets none.
For Indian dev and ops teams juggling DPDP compliance and a growing external attack surface, DNS security is one of the highest-leverage places to start, because the fixes — DNSSEC, MFA, monitoring, cleanup — are well understood and don't require a large budget, only consistent ownership. Dhisattva AI Pvt Ltd built its automated scanning approach around exactly this principle: the controls that matter most are often the ones nobody owns continuously.