DNS security is one of the most overlooked attack surfaces in Indian businesses. The Domain Name System translates domain names to IP addresses — every web request, email, and API call depends on it. When DNS is compromised, attackers silently redirect users to phishing pages, intercept email, or exfiltrate data without touching your application code. DNSSEC, DNS over HTTPS (DoH), and registrar-level controls exist to close these gaps, yet adoption across Indian SMBs remains critically low. This guide explains what each control does, why it matters under India's cyber compliance landscape, and how to build a layered DNS defence today.
How DNS Actually Works — and Where It Breaks
When a user visits app.yourcompany.in, this chain fires in milliseconds:
- The browser queries a recursive resolver (your ISP's or a public resolver like 8.8.8.8).
- The resolver walks the hierarchy: root nameservers →
.inTLD nameservers → your authoritative nameserver. - The authoritative nameserver returns the IP.
- The resolver caches the answer for the record's TTL.
graph TD
A[User Browser] -->|1 DNS query| B[Recursive Resolver / ISP]
B -->|2 Walk hierarchy| C[Root Nameserver]
C -->|3 Referral| D[.in TLD Nameserver]
D -->|4 Referral| E[Your Authoritative NS]
E -->|5 Real answer| B
B -->|6 Cached response| A
ATK[Attacker] -->|Race - forged response| B
B -->|Cache poisoned| F[Forged IP Served to All Users]
F --> G{DNSSEC Validation}
G -->|Signature mismatch| H[Query Rejected - Safe]
G -->|No DNSSEC| I[Forged Record Accepted]
style ATK fill:#5f1e1e,stroke:#EF4444,color:#e2e8f0
style F fill:#5f1e1e,stroke:#EF4444,color:#e2e8f0
style I fill:#5f1e1e,stroke:#EF4444,color:#e2e8f0
style H fill:#1e3d2f,stroke:#10B981,color:#e2e8f0
style G fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
style A fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
style B fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
style C fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
style D fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
style E fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0The DNS Threat Landscape for Indian Businesses
DNS Cache Poisoning
Attackers race to inject forged DNS responses before the legitimate answer arrives. A successful poisoning redirects all users hitting that cached record to a cloned login page. The Kaminsky attack (2008) proved this at scale; modern variants exploit birthday paradoxes in port and transaction-ID prediction.
DNS Hijacking via Registrar Takeover
If an attacker gains access to your domain registrar account via credential stuffing, phishing, or SIM swap, they can update your NS records entirely — taking your site and email dark or rerouting them globally. CERT-In has documented multiple such Indian domain hijackings tied to weak registrar credentials.
Subdomain and MX Abuse
Dangling CNAME records pointing to decommissioned cloud resources (expired S3 buckets, old Heroku apps) let attackers claim that subdomain and serve malicious content under your brand. MX record tampering silently reroutes inbound email to attacker-controlled servers — bypassing every endpoint control.
DNS Tunneling for Data Exfiltration
DNS traverses almost every firewall unopposed. Attackers encode stolen data inside DNS query strings — e.g., dGhpcyBpcyBzdG9sZW4gZGF0YQ.attacker.com — and collect it at a nameserver they control. Tools like iodine and dnscat2 automate this. Traditional DLP misses it entirely because it inspects HTTP/S, not DNS.
NXDOMAIN Injection by ISPs
Some Indian ISPs intercept NXDOMAIN responses and redirect them to monetised landing pages. This breaks DNS-based security tools that rely on NXDOMAIN signals for threat feeds and leaks internal query traffic to third parties.
DNSSEC: Cryptographic Trust for the DNS Hierarchy
DNSSEC (DNS Security Extensions, RFC 4033–4035) adds digital signatures to DNS records. Every zone signs its records with a private key; the corresponding public key is published as a DNSKEY record and chained upward to the TLD and root. A validating resolver can verify the entire chain of trust before accepting a response.
What DNSSEC Protects Against
- Cache poisoning (forged records fail signature verification)
- Data integrity in transit (records cannot be modified mid-flight)
- Spoofed responses from rogue resolvers
What DNSSEC Does Not Protect Against
- Registrar account takeover (the signing keys live at your registrar)
- DDoS against your nameservers
- DNS tunneling (tunneled data still passes valid DNS; DNSSEC signs the channel, not the content)
- Privacy (queries are still visible in plaintext unless combined with DoH/DoT)
Why DNSSEC Adoption Is Low in India
DNSSEC requires coordination across your registrar, DNS hosting provider, and authoritative nameserver. The .in ccTLD managed via NIXI supports it, as do major registrars like GoDaddy and BigRock. The barrier is operational: misconfigured DNSSEC causes SERVFAIL and complete domain outage, deterring risk-averse operators. Managed providers like Cloudflare now offer one-click DNSSEC, but most Indian SMBs have never enabled it.
pie title Relative DNS Attack Surface vs Deployed Controls in Indian SMBs
"DNSSEC enabled" : 8
"DoH or DoT in use" : 12
"Registrar lock active" : 25
"CAA records configured" : 5
"No DNS controls deployed" : 50Know your vulnerabilities before attackers do
Run a free VAPT scan — takes 5 minutes, no signup required.
Book Your Free ScanDNS over HTTPS and DNS over TLS
Standard DNS sends queries in plaintext over UDP port 53. Anyone on the network path — your ISP, a coffee-shop router, a corporate proxy — can read every domain you query, even if the destination uses HTTPS.
DNS over TLS (DoT) wraps DNS in a TLS session on port 853, encrypting the transport.
DNS over HTTPS (DoH) tunnels DNS queries inside HTTPS on port 443, making them indistinguishable from ordinary web traffic.
The Enterprise Visibility Tradeoff
For individuals, DoH/DoT is a clear privacy win. For enterprises, it creates a visibility gap: security teams lose DNS logging signals when employees use a personal DoH resolver (e.g., 1.1.1.1/dns-query).
The fix is a corporate DoH/DoT resolver — on-premises (Unbound, Knot Resolver) or a managed filtering service — enforced via endpoint policy. You get encrypted queries and full enterprise visibility.
| Control | Protects Against | Does Not Protect | Deployment Complexity |
|---|---|---|---|
| DNSSEC | Cache poisoning, data tampering | Privacy, tunneling, registrar hijack | Medium — registrar + hosting coordination |
| DoH / DoT | ISP snooping, NXDOMAIN injection | Cache poisoning alone | Low — resolver change or browser policy |
| Registrar Lock | NS/registrar hijacking | On-path attacks | Low — toggle in registrar dashboard |
| Filtering DNS Resolver | Malware C2, phishing domains | Signed record attacks | Low — point resolvers at provider |
| CAA Records | Unauthorized TLS cert issuance | DNS hijacking itself | Low — add one DNS record |
| DNS Monitoring | Post-compromise detection | Prevention | Medium — requires SIEM integration |
Registrar Lock and 2FA: The Simplest High-Value Control
A registrar lock (EPP status clientTransferProhibited) prevents domain transfers or NS record changes without explicitly unlocking first — even if an attacker holds your registrar password. Pair it with a strong unique password, hardware-token or TOTP-based 2FA, and change alerts, and you stop the most common DNS hijacking vector outright.
CAA Records: Locking Certificate Issuance
A Certification Authority Authorization (CAA) record (RFC 6844) declares which CAs may issue TLS certificates for your domain. Example:
yourcompany.in. CAA 0 issue "letsencrypt.org"
yourcompany.in. CAA 0 issuewild ";"Only Let's Encrypt may issue standard certs; wildcard issuance is forbidden entirely. An attacker attempting to get a fraudulent cert from any other CA will be refused at pre-issuance check. CAA does not protect against an attacker who has hijacked DNS and controls a permitted CA, but it significantly raises the bar.
Protective DNS Resolvers: Filtering at the Query Level
Protective DNS services maintain threat feeds of known malicious domains and return NXDOMAIN or a sinkhole IP for blocked queries — catching threats before a TCP connection ever forms. Options include Cloudflare Gateway (1.1.1.2) and Quad9 (9.9.9.9). MeitY-adjacent programmes recommend filtering DNS as a baseline control for critical information infrastructure.
CERT-In Incident Reporting Obligations
Under the CERT-In Directions of April 2022, Indian organisations must report cyber incidents within six hours of discovery. DNS-related incidents that trigger this obligation include:
- Unauthorised DNS record changes (hijacking)
- Phishing attacks hosted under your domain
- Malware distribution traced to your domain infrastructure
- Data exfiltration via DNS tunneling
Building a Layered DNS Security Programme
A mature DNS security posture is a stack of complementary controls, not a single product.
| Layer | Control | Priority |
|---|---|---|
| Registrar | Transfer lock + 2FA + change alerts | P0 — do today |
| Authoritative DNS | DNSSEC signing enabled | P0 — do this week |
| Resolvers | DoH or DoT to a filtering resolver | P1 — do this month |
| Certificate | CAA records restricting issuance | P1 — do this month |
| Monitoring | DNS change notifications, SIEM integration | P1 — do this month |
| Incident response | CERT-In reporting runbook for DNS events | P2 — do this quarter |
| Penetration testing | DNS zone transfer, subdomain enumeration, dangling CNAME audit | P2 — annual |
DNS Security and Automated VAPT
DNS misconfigurations — open zone transfers, missing DNSSEC, dangling subdomains, absent CAA records — are among the findings surface-area in a thorough VAPT engagement. Bachao.AI (operated by Dhisattva AI Pvt Ltd, a DPIIT Recognized Startup) includes DNS reconnaissance and misconfiguration checks as part of its automated scan suite. You can run a free VAPT scan to see how your domain's DNS posture scores before an attacker does.
For findings that require CERT-In empanelled attestation — such as regulated-sector compliance reports — the platform works with a CERT-In empanelled partner to deliver the formal audit documentation.
External References
- CERT-In Cyber Security Directions 2022 — mandatory incident reporting timelines
- Cloudflare Learning: What is DNSSEC? — accessible primer on DNSSEC chain of trust
- IETF RFC 8484 — DNS Queries over HTTPS — the DoH specification
- ICANN DNSSEC Information — why DNSSEC matters globally