DNS Security for Indian Enterprises: Why DNS Filtering Is Your Last Line of Defence Against Malware and Data Exfiltration

• 04 July, 2026
• No Comments

Every time an employee opens a browser, runs a scheduled task, or a piece of malware phones home, it starts with a single DNS query. Yet in most Indian enterprise environments, DNS traffic flows unmonitored and unfiltered — an open highway that attackers have been exploiting for decades. In 2026, with threat actors increasingly tunnelling command-and-control (C2) traffic, ransomware callbacks, and data exfiltration payloads inside DNS packets, ignoring DNS security is no longer a calculated risk. It is an unacceptable blind spot.

This guide explains exactly how attackers abuse DNS, what DNS security controls look like in practice, and how Indian enterprises can deploy DNS filtering within their existing FortiGate infrastructure — or through a managed SOC — to close one of the most persistent gaps in enterprise defence.

Why DNS Is the Attacker’s Favourite Protocol

DNS was designed for availability, not security. Port 53 UDP is allowed outbound on virtually every corporate firewall, on every VLAN, for every device. Unlike HTTP/S traffic, DNS queries rarely pass through a web proxy and are almost never deep-inspected by default. Attackers have known this for years, and their toolkits reflect it.

The Four Most Common DNS-Based Attack Patterns

• DNS tunnelling: Malware encodes data — stolen credentials, files, keylogger output — inside the subdomain labels of DNS queries. The queries go to an attacker-controlled authoritative DNS server that decodes and logs the exfiltrated data. Tools like iodine, dnscat2, and custom implants used in advanced persistent threat (APT) campaigns all use this technique. A single infected endpoint can exfiltrate gigabytes of data over days without triggering a traditional DLP alert.
• Domain Generation Algorithms (DGA): Ransomware and botnets generate hundreds or thousands of random-looking domain names daily. The malware tries each one until it finds the current C2 domain. Traditional blocklists can never keep up — the domains change faster than they can be catalogued. Only machine-learning-based DNS analytics can spot the pattern of DGA traffic.
• Fast-flux DNS: Phishing infrastructure rotates the IP addresses behind a domain every few minutes, making IP-based blocking ineffective. The domain itself is the indicator of compromise, and only DNS-layer inspection catches it.
• DNS cache poisoning and hijacking: Attackers who compromise an organisation’s DNS resolver or recursive forwarder can redirect internal users to malicious sites — even for domains the enterprise has visited thousands of times. DNSSEC validation and response policy zones (RPZ) defend against this at the resolver level.

The CERT-In and DPDP Compliance Angle

Indian enterprises operating under the DPDP Act 2023 and CERT-In’s April 2022 directions carry specific obligations that DNS security directly addresses.

CERT-In’s directions require organisations to maintain logs of all ICT systems including network devices, and to report incidents within six hours of detection. DNS logs are often the earliest forensic evidence of a compromise — the first C2 callback, the first DGA beacon, the first exfiltration tunnel. Without DNS logging, meeting the six-hour reporting window becomes nearly impossible because incident timelines cannot be reconstructed.

Under the DPDP Act, the obligation to implement “reasonable security safeguards” for personal data extends to the network layer. A DNS filtering solution that blocks known malicious domains before data can leave the network is a demonstrable, auditable control — exactly the kind of evidence a Data Protection Board investigation would expect to see.

Key compliance point: CERT-In’s directions mandate log retention for 180 days. DNS query logs from all devices — including BYO devices on guest Wi-Fi — should be captured, stored, and indexed for fast search during incident response.

How DNS Filtering Works: From Recursive Resolver to FortiGate

DNS security is not a single product. It is a layered set of controls applied at different points in the DNS resolution chain. Here is how each layer works in an enterprise context:

Layer 1 — Protective DNS (PDNS) at the Recursive Resolver

The most impactful control is replacing the organisation’s recursive DNS resolver (typically a forwarding server or the ISP’s default) with a protective DNS service. PDNS evaluates every outbound DNS query against threat intelligence feeds, machine-learning classifiers, and category databases. Queries to known malicious domains, newly registered domains (NRDs), DGA-generated names, and high-risk categories (cryptomining, adult content, phishing kits) return a blocked response (NXDOMAIN or a sinkhole IP) before any TCP connection is ever attempted.

FortiGate’s FortiDNS and the integrated FortiGuard DNS Filtering service deliver this capability natively for networks already running Fortinet infrastructure. Policies can be pushed from FortiManager to every FortiGate in the estate — branch offices, data centres, remote access gateways — within seconds.

Layer 2 — DNS Firewall / Response Policy Zones (RPZ)

Response Policy Zones allow an enterprise’s internal authoritative DNS server (typically Windows DNS or BIND) to override responses for specific domains or domain patterns. An RPZ feed from a threat intelligence provider automatically poisons the local cache for malicious names — blocking them even for devices that bypass the corporate resolver by using hardcoded public DNS servers (a common malware evasion tactic).

Layer 3 — DNS Inspection at the Firewall

FortiGate’s Application Control and DNS Filter profiles inspect DNS traffic at the network edge. This catches devices that attempt to use alternative resolvers (8.8.8.8, 1.1.1.1) by transparently redirecting all UDP/TCP port 53 traffic to the corporate resolver. It also enforces DNS-over-HTTPS (DoH) policy — blocking or redirecting DoH traffic that would otherwise bypass traditional DNS controls entirely.

Layer 4 — DNS Logging and SIEM Integration

Without logging, DNS filtering is a prevention-only control. Integrating DNS query logs with a SIEM (FortiSIEM, Splunk, or the SOC’s preferred platform) enables detection use cases that filtering alone cannot cover: slow-and-low DNS tunnelling that stays below volume thresholds, internal resolver queries from unexpected hosts, and retrospective hunting after an incident is declared.

Practical Deployment: A Four-Week Rollout Plan for Indian Enterprises

Most enterprises delay DNS security because they fear disrupting business-critical applications. The following phased approach minimises risk while delivering value quickly.

Week 1 — Audit and Baseline

• Identify all DNS resolvers in use across the environment (AD-integrated DNS, branch forwarders, guest Wi-Fi resolvers, cloud VPC resolvers).
• Enable DNS query logging on all resolvers in monitor-only mode. Feed logs to the SIEM.
• Run a 7-day baseline report: top queried domains, domains with high entropy names (DGA candidates), external resolvers in use, and any known-bad domains already present in logs.
• Map any application dependencies on specific external DNS servers (some SaaS connectors or legacy apps may use hardcoded resolvers).

Week 2 — Enable Blocking in Audit Mode

• Deploy FortiGuard DNS Filtering in log-only mode across all FortiGate policies. Review the would-have-been-blocked list daily and whitelist any false positives.
• Configure RPZ on internal DNS servers with a curated threat feed (CISA’s known-bad domains list is a free starting point).
• Brief the helpdesk team: they will receive calls from users whose legitimate but mis-categorised sites are flagged.

Week 3 — Enforce Blocking, Redirect Rogue Resolvers

• Switch FortiGuard DNS Filtering from log-only to block mode for high-confidence categories: malware C2, phishing, botnet, DGA.
• Add FortiGate policies to redirect all outbound UDP/TCP 53 traffic to the corporate resolver. Block DoH to non-approved providers.
• Enable anomaly-based DNS alerts in SIEM: flag any host generating >500 unique NXDOMAIN responses per hour (DGA indicator), or DNS query payloads >200 bytes (tunnelling indicator).

Week 4 — SOC Integration and Runbook

• Create SOC playbook: DNS alert → check host for other IOCs → isolate if confirmed → preserve DNS logs for CERT-In reporting.
• Schedule quarterly DNS security reviews: review blocked domain statistics, update category policies, re-evaluate whitelisted domains.
• Document the DNS security controls for DPDP Act compliance evidence files.

Common Mistakes That Undermine DNS Security

Even enterprises that have invested in DNS filtering often leave gaps that a skilled attacker will find.

• Not covering cloud workloads: EC2 instances, Azure VMs, and GCP compute resources often use the cloud provider’s default resolver and bypass on-premises DNS filtering entirely. Extend your PDNS policy to cloud environments via VPC-level DNS settings or cloud-native DNS security integrations.
• Ignoring IPv6: IPv6 AAAA queries are sometimes processed by a separate resolver path that bypasses the filtering layer. Audit your IPv6 DNS configuration explicitly.
• Overlooking encrypted DNS (DoH/DoT): Browsers like Chrome and Firefox enable DoH by default. If your FortiGate is not intercepting and blocking unsanctioned DoH traffic, the DNS filtering layer can be bypassed by any user who leaves their browser at defaults.
• Whitelisting too broadly: “Whitelist the entire cloud provider domain” is a common shortcut that renders DNS filtering useless against DGA malware hosted on AWS, Azure, or Cloudflare infrastructure. Whitelist specific subdomains, not top-level zones.
• No alert tuning: An untuned DNS anomaly alert that fires thousands of times per day trains SOC analysts to ignore it. Invest time in tuning thresholds to your environment’s baseline before going live.

What to Look For in a Managed DNS Security Partner

For enterprises that lack the in-house expertise to deploy and tune DNS security, a managed security provider should be able to demonstrate the following capabilities:

• Native integration with FortiGate FortiGuard DNS Filtering and FortiSIEM — not just a bolt-on third-party tool that adds complexity.
• 24/7 SOC with DNS-specific detection use cases, not just firewall and endpoint alerts.
• Threat intelligence feeds updated in real time — DGA and fast-flux domains have a lifespan measured in hours, not days.
• CERT-In-aligned incident response: pre-built runbooks for DNS-based incidents that meet the six-hour reporting timeline.
• Documented evidence outputs for DPDP Act compliance audits.

Conclusion: DNS Is Not Boring Infrastructure — It Is an Active Threat Surface

Security teams that treat DNS as boring plumbing — something the networking team manages, not the security team — are leaving one of the most valuable detection and prevention controls off the table. In environments where endpoints are increasingly mobile, cloud workloads span multiple providers, and attackers are under pressure to avoid traditional IOC-based detection, DNS traffic is often the clearest signal of malicious activity available.

The good news: DNS security is not a rip-and-replace project. For most Indian enterprises running FortiGate, the capability is already licenced. Activating it, tuning it, and integrating it with the SOC is a matter of weeks — not months — and the protection it provides against ransomware callbacks, data exfiltration, and phishing infrastructure is immediate and measurable.

PJ Networks’ 24/7 NOC and SOC teams specialise in deploying and managing DNS security controls for Indian enterprises — from FortiGuard DNS Filtering activation through SIEM integration and CERT-In-aligned incident response. If you want to understand where your DNS security posture stands today, reach out for a no-obligation network security assessment.