DNS security rarely makes it into the opening slides of a security briefing. Most Australian IT teams treat DNS as solved infrastructure: it either works or it doesn't, and when it works, nobody thinks about it. That's the problem. DNS is the first thing a machine reaches out to when it wants to go anywhere on the internet, and attackers have known for years that it's also the last control most organisations bother to harden.
The Australian Signals Directorate's own guidance flags DNS as a critical component of network security, yet DNS-based attacks continue to succeed against organisations that have invested heavily in endpoint protection and email filtering. The gap isn't knowledge. It's prioritisation.
Why DNS is such an attractive attack surface
DNS traffic is almost always permitted through firewalls. It has to be: stop DNS and nothing works. That permissive stance gives attackers a reliable channel for two very different kinds of abuse.
The first is DNS tunnelling. An attacker who has compromised a machine inside your network can encode data inside DNS queries and exfiltrate it to a resolver they control, even when every other outbound port is blocked. Tools that automate this have been publicly available for over a decade. Detection requires baseline analysis of query volume, query length, and entropy, not just perimeter rules.
The second is command-and-control (C2) over DNS. Malware beacons home by resolving domain names that map to attacker infrastructure. Domain generation algorithms (DGAs) make this harder to block by cycling through thousands of candidate domains, so a blocklist becomes useless within hours. Catching DGA traffic requires anomaly detection on resolution patterns, not manual block lists.
Both attack classes bypass controls that most Australian organisations rely on. They also bypass controls covered in the network segmentation playbook, because segmentation protects lateral movement inside the network but doesn't inspect what's leaving through DNS port 53.
The most common gaps in Australian environments
Across Australian enterprise environments, four DNS security failures appear consistently.
Unmonitored recursive resolvers. Many organisations run internal recursive resolvers without logging queries at all. If a machine inside the network resolves a known-malicious domain, there's no record of it. SIEM integrations and SOAR playbooks can't act on data that isn't collected.
No DNS filtering layer. A protective DNS service sits between your resolvers and the root, blocking resolution of known-malicious domains before a connection is ever made. The ACSC recommends protective DNS as a baseline control for both government and enterprise environments. Despite this, a significant share of Australian mid-market organisations still rely solely on perimeter firewalls and endpoint AV, with no DNS filtering in place.
Missing DNSSEC validation. DNSSEC signs DNS records cryptographically, so resolvers can verify that the response they receive hasn't been tampered with in transit. DNS cache poisoning attacks, where a resolver is tricked into caching a forged record and sending users to attacker-controlled infrastructure, are much harder to pull off against DNSSEC-validating resolvers. Yet many Australian organisations haven't enabled DNSSEC validation on their resolvers, and a meaningful proportion haven't signed their own zones either.
Split-horizon DNS without proper controls. Split-horizon configurations expose internal records only to internal resolvers. Done correctly, this limits attack surface. Done carelessly, internal zone data leaks to external resolvers, and an attacker can map your internal infrastructure before setting foot inside the network.
Protective DNS: the quickest win
If an organisation takes one step from this article, it should be deploying a protective DNS service. The model is simple: configure your internal resolvers to forward queries to a filtering service that maintains threat intelligence feeds. Domains associated with malware, phishing, C2 infrastructure, and newly registered suspicious domains get blocked at the resolution stage. The connection never happens.
Quad9 offers a free option. Quad9 blocks known-malicious domains using threat intelligence from over 20 partners, including feeds from the cybersecurity research community. Commercial options from Cisco Umbrella, Cloudflare Gateway, and others add policy controls, per-user logging, and category filtering on top of the threat intelligence layer.
The ACSC's own protective DNS service is available to Australian government agencies. Non-government organisations should look at commercial equivalents. The cost is low relative to the protection it provides, and deployment typically takes a day, not a sprint.
DNS logging: what to collect and why
Protective DNS catches known-bad domains. Logging catches the things that slip through, and the historical record needed to investigate when something does. At minimum, DNS query logs should capture: the source IP of the querying host, the queried domain name, the record type requested, the response received, and a timestamp.
Forward these logs to your SIEM. Useful detection rules to build on top of this data include:
- High query volumes from a single host to domains it hasn't queried before (tunnelling indicator)
- Queries to domains with high entropy names (DGA indicator)
- Queries to recently registered domains, particularly those under 30 days old
- Resolution failures at above-baseline rates from a specific host
These rules generate noise at first. Tuning them against your own baseline is more useful than generic thresholds copied from a vendor guide.
DNSSEC: signing your own zones
DNSSEC adoption in Australia has been slow. Part of the problem is that signing a zone requires coordinating with your registrar and DNS hosting provider, and the tooling varies. Part of it is that the immediate visible benefit is hard to demonstrate until an attack occurs.
The two steps are distinct. First, enable DNSSEC validation on your resolvers so they reject unsigned responses that don't match published signatures. This protects your users from cache poisoning attacks targeting external zones. Second, sign your own authoritative zones so that external resolvers can verify your records. This protects people looking up your domains from being redirected by a poisoned response upstream.
Both steps matter. Validation without zone signing protects lookups going out. Zone signing without validation protects lookups coming in. Most Australian organisations that have done any DNSSEC work have done one and not the other.
DNS and the Essential Eight
The Essential Eight maturity model doesn't name DNS security explicitly as a control, but several of its controls depend on DNS being trustworthy. Application control relies on software reaching legitimate update servers. Patch management assumes that machines resolve vendor update URLs correctly. If DNS is compromised, both controls fail silently.
The practical implication: DNS security is foundational infrastructure for the Essential Eight, not a separate workstream. Organisations that are serious about reaching Maturity Level 2 or 3 on the Essential Eight should audit their DNS posture as part of that programme, not separately.
Where to start this week
A DNS security improvement programme doesn't need a six-month project plan. Three concrete actions deliver real risk reduction quickly.
First, audit what's logging. Check whether your internal resolvers (Windows DNS, BIND, Unbound, or whatever your environment runs) have query logging enabled, and verify those logs are reaching your SIEM or log management platform. If they aren't, fix that before anything else.
Second, evaluate a protective DNS service. Run a proof of concept with Quad9 or a commercial alternative for two to four weeks. Measure how many malicious or suspicious resolutions it blocks. That number makes the business case for permanent deployment.
Third, check your public DNS zones against DNSSEC. Tools like DNSViz will show you whether your zones are signed, whether the chain of trust is intact, and whether there are configuration errors. The output is visual and free, and it typically reveals problems that nobody knew existed.
DNS security is unglamorous work. It doesn't produce a dashboard with breach-prevention metrics. But the cost of not doing it shows up in post-incident reviews, when forensics teams discover that malware was beaconing home for weeks through a channel nobody was watching.