Skip to content
Back to Blog
·9 min read·technology

DNS Security for Indian Businesses: DNSSEC and DoH

DNS security weaknesses — spoofing, cache poisoning and registrar hijacking — are rising threats for Indian SMBs. Learn how DNSSEC and DoH close these gaps.

BR

Bachao.AI Research Team

Cybersecurity Research

Scan Your Attack Surface

Security exposure this creates

Unpatched vulnerabilities in your tech stack are the #1 entry point for breaches targeting Indian businesses. Here's what to watch.

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:

  1. The browser queries a recursive resolver (your ISP's or a public resolver like 8.8.8.8).
  2. The resolver walks the hierarchy: root nameservers → .in TLD nameservers → your authoritative nameserver.
  3. The authoritative nameserver returns the IP.
  4. The resolver caches the answer for the record's TTL.
That cache is the primary attack target. A poisoned cache — forged IP inserted before the real answer arrives — sends every subsequent user to the wrong server with no visible warning.
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:#e2e8f0

The 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.

⚠️
WARNING
ISP DNS resolvers in India frequently inject NXDOMAIN redirects and log all query traffic. For business environments, switching to an enterprise-grade encrypted resolver (DoH/DoT) eliminates both information leakage and injection.
14 lakh+Cyber incidents reported to CERT-In in 2022 alone — a multi-year high (CERT-In Annual Report 2022)
1 in 5Indian organisations experienced a DNS-based attack in the past year, per global DNS threat surveys (IDC/EfficientIP Global DNS Threat Report 2023)

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

    1. Cache poisoning (forged records fail signature verification)
    2. Data integrity in transit (records cannot be modified mid-flight)
    3. Spoofed responses from rogue resolvers

What DNSSEC Does Not Protect Against

    1. Registrar account takeover (the signing keys live at your registrar)
    2. DDoS against your nameservers
    3. DNS tunneling (tunneled data still passes valid DNS; DNSSEC signs the channel, not the content)
    4. 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" : 50
ℹ️
NOTE
The pie above reflects qualitative estimates based on APNIC measurement data and CERT-In guidance, not a controlled survey. The point is directional: most Indian SMBs have no DNS-layer controls in place.

Know your vulnerabilities before attackers do

Run a free VAPT scan — takes 5 minutes, no signup required.

Book Your Free Scan

DNS 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.

ControlProtects AgainstDoes Not ProtectDeployment Complexity
DNSSECCache poisoning, data tamperingPrivacy, tunneling, registrar hijackMedium — registrar + hosting coordination
DoH / DoTISP snooping, NXDOMAIN injectionCache poisoning aloneLow — resolver change or browser policy
Registrar LockNS/registrar hijackingOn-path attacksLow — toggle in registrar dashboard
Filtering DNS ResolverMalware C2, phishing domainsSigned record attacksLow — point resolvers at provider
CAA RecordsUnauthorized TLS cert issuanceDNS hijacking itselfLow — add one DNS record
DNS MonitoringPost-compromise detectionPreventionMedium — 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.

🛡️
SECURITY
Check your registrar right now: log in, confirm transfer lock is on, verify that 2FA is hardware-token or authenticator-app (not SMS), and ensure your account email is a monitored security alias — not a personal inbox.

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.

💡
TIP
Point all endpoint and server resolvers at a filtering DNS provider, then log DNS queries to your SIEM. You will immediately see C2 beaconing, DNS tunneling attempts, and shadow-IT cloud services that bypass your proxy.

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:

    1. Unauthorised DNS record changes (hijacking)
    2. Phishing attacks hosted under your domain
    3. Malware distribution traced to your domain infrastructure
    4. Data exfiltration via DNS tunneling
Failure to report within six hours carries regulatory consequences. Real-time DNS monitoring with change alerts directly supports your ability to detect, scope, and report these incidents on time.

Building a Layered DNS Security Programme

A mature DNS security posture is a stack of complementary controls, not a single product.

LayerControlPriority
RegistrarTransfer lock + 2FA + change alertsP0 — do today
Authoritative DNSDNSSEC signing enabledP0 — do this week
ResolversDoH or DoT to a filtering resolverP1 — do this month
CertificateCAA records restricting issuanceP1 — do this month
MonitoringDNS change notifications, SIEM integrationP1 — do this month
Incident responseCERT-In reporting runbook for DNS eventsP2 — do this quarter
Penetration testingDNS zone transfer, subdomain enumeration, dangling CNAME auditP2 — annual
🎯Key Takeaway
DNS is the silent infrastructure beneath every digital transaction. A single poisoned cache entry, a hijacked NS record, or an unmonitored dangling CNAME can silently redirect your customers, intercept your email, or exfiltrate data through channels that bypass every application-level control. Registrar lock costs nothing to enable. DNSSEC takes an afternoon. DoH takes five minutes. The barrier is awareness, not budget — and the exposure from inaction is real.

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

Frequently Asked Questions

What is DNS spoofing and how does it affect Indian businesses?
DNS spoofing (or cache poisoning) tricks a DNS resolver into caching a forged IP address for a legitimate domain. Visitors are then silently redirected to attacker-controlled servers — typically phishing pages or malware distribution sites — without any browser warning. Indian businesses are not specifically targeted by DNS spoofing above the global average, but low DNSSEC adoption means the attack has a higher success rate when attempted.
Does enabling DNSSEC break anything on my website?
DNSSEC itself does not affect how your website loads for users — it only adds a validation layer for DNS resolvers. The risk is misconfiguration: if your DNSSEC keys expire or your DS record at the registrar gets out of sync with your zone-signing keys, resolvers will return SERVFAIL and your domain becomes unreachable. Use a managed DNS provider that automates key rotation (Cloudflare, Route 53, and others handle this) to eliminate operational risk.
Is DNS over HTTPS mandatory under CERT-In guidelines?
CERT-In does not currently mandate DoH specifically, but the April 2022 Directions require organisations to maintain accurate logs and report incidents promptly. Using an encrypted, logging-capable DNS resolver (DoH or DoT to a corporate resolver) directly supports both requirements. For critical information infrastructure, MeitY guidance recommends encrypted DNS as a baseline network security control.
How do I check if my domain has dangling subdomain records?
Run a DNS enumeration and check each CNAME and A record for active resolution. For each CNAME pointing to a cloud provider (S3, GitHub Pages, Heroku, etc.), verify the target resource actually exists and belongs to your organisation. An automated VAPT scan will surface dangling CNAMEs as part of reconnaissance. You can start with a free VAPT scan to get an initial picture.
What is a CAA record and do I need one?
A CAA (Certification Authority Authorization) record is a DNS record that restricts which Certificate Authorities are allowed to issue TLS certificates for your domain. Without one, any of the 100+ publicly trusted CAs can technically issue a certificate for your domain — a risk if DNS is compromised. Adding a CAA record takes two minutes and significantly narrows the certificate-issuance attack surface.
How quickly must I report a DNS hijacking to CERT-In?
Under the CERT-In Directions of April 2022, organisations must report cyber incidents — including unauthorised DNS record changes — within six hours of becoming aware. This makes real-time DNS monitoring (change alerts from your registrar and your DNS hosting provider) a compliance requirement, not just a security nice-to-have.
BR

Bachao.AI Research Team

Cybersecurity Research

AI-powered security research and threat intelligence from the Bachao.AI team. Covering the latest vulnerabilities, CVEs, and cybersecurity developments affecting Indian businesses.

Get cybersecurity insights for Indian SMBs

Weekly vulnerability alerts, DPDP compliance tips, and security guides. No spam — unsubscribe anytime.

We respect your privacy. Your email is never shared.

Find out if you're exposed to this class of threat

Free automated scan — risk score in under 2 hours. No credit card required.

Scan Your Attack Surface
Find your vulnerabilitiesStart free scan →