The cheapest place to stop an attack is before it starts.

What actually happens

A device wants to reach example.com. Before anything else, it asks a resolver for the address. The resolver answers, the device connects, and the transaction proceeds. That first question is the moment of interest, because it happens before the connection exists.

A protective resolver does one extra thing in that instant: it checks the name against current threat intelligence. If the name is known to be hosting malware, serving a phishing page, or acting as a control channel for something already inside the network, it declines to answer truthfully. The device is told the destination does not exist, or is quietly pointed at a harmless address that records the attempt.

Nothing is blocked at the firewall, because no packet is ever sent. The attack does not get as far as being traffic.

Why the name is the useful place to intervene

Three reasons, and they compound.

It is early. Every other control acts on something that is already happening — a connection to inspect, a file to scan, a process to kill. A name lookup is a statement of intent before the act. Stopping something there costs nothing and breaks nothing downstream.

It is universal. Endpoint software covers the devices you can install software on. That excludes the printer, the television, the heat pump, the security camera, the visitor’s laptop and the contractor’s phone. All of them still ask for addresses, so all of them are covered by a resolver whether they cooperate or not.

It is the same chokepoint attackers depend on. Malware that phones home usually does so by name, because names survive the loss of an address. The property that makes command-and-control resilient is the same property that makes it visible.

The part people underestimate: you learn what is on your network

The threat blocking is the reason it gets bought. The query record is often worth more.

A resolver sees every device asking for every name, continuously. That is an inventory nobody had to compile: which devices exist, what services they depend on, what they talk to when nobody is watching, and what changed this week. It answers questions that are otherwise surprisingly hard — is that appliance still calling home to a vendor who went out of business? — and it does it from records you already have rather than a project you have to run.

Where it does not help

A control sold without its boundaries gets trusted for things it was never going to stop, and that misplaced confidence is its own risk. So, plainly:

It acts on names, not addresses. Something that connects directly to an IP address asks no question, so there is nothing to intercept.

Devices can carry their own resolver. Plenty of consumer equipment ships with a DNS server hardcoded inside it and ignores whatever the network offers. Unless that traffic is redirected, those devices are outside the protection entirely — and the ones that do this tend to be exactly the ones you least control.

Browsers can encrypt lookups past you. Encrypted DNS is good for privacy on a hostile network and inconvenient on one you are responsible for. It is manageable, but it has to be managed deliberately rather than discovered.

Intelligence has a horizon. A domain registered an hour ago is on nobody’s list. Filtering shifts the odds; it does not close the door.

It is one control among several. It does not patch anything, segment anything, or remove the need for backups.

This is not a novel idea

Two governments have already decided the argument.

The United States. CISA operates a Protective DNS Resolver that is mandated for every federal civilian executive branch agency, and offered to critical-infrastructure operators through a pilot. Their description of the mechanism is the same one set out above: queries pass through resolvers that filter actively, and where a query matches a threat-intelligence indicator the service blocks, redirects or sinkholes the response and raises an alert.

The United Kingdom. The NCSC runs PDNS as one of its Active Cyber Defence capabilities. It is mandated for central government departments by the Cabinet Office and open to other organisations. Its method is disarmingly plain — it prevents access to known-malicious domains by simply not resolving them — and notably, it gives participating organisations metrics about the health of their own networks, which is the visibility argument made above, arrived at independently.

Three details of those designs are worth borrowing whatever your size. Both sit upstream of the organisation’s own resolvers rather than replacing them, so internal naming keeps working untouched. Both have roaming and cloud devices point at the resolver directly, which closes the gap that opens the moment a laptop leaves the building — the control follows the device, not the office. And both treat the records as a product in their own right, not a by-product.

If two governments mandate a control across their entire civilian estates, the question is no longer whether it works. It is whether you have it.

And in New Zealand

The New Zealand Information Security Manual names it directly. NZISM describes Protective DNS as providing “real-time secure DNS resolver checks for domains and IP addresses against known malicious entities”, and lists it as one of the dynamic network defence capabilities agencies are expected to consider.

The obligation, though, is softer than the mandates above — and the difference is worth understanding rather than glossing:

• 7.1.7.C.02 — agencies should maintain detection tooling that includes dynamic network defence (i.e. protective DNS and/or NGFW). A should, across all classifications. The equivalent must, at 7.1.7.C.01, applies only at the higher classifications and does not name protective DNS.
• 14.3.10.C.03 — agencies that do not operate an allow list should deny list websites to prevent access to known malicious ones, and 14.3.10.C.04 says that list should be updated frequently. That is the same control described by its effect rather than its mechanism.
• 16.6.13.C.04 — DNS, proxy and event logs should be retained for a minimum of twelve months. Note what that assumes: that the records exist, that you hold them, and that they are worth keeping for a year. It is the visibility argument in the form of a retention control.
• 18.4.13.C.01 — DNS servers are explicitly named among the high value servers that should carry host-based intrusion detection.

So New Zealand does not run a national resolver and mandate its use, as the UK and US do. What it does is name the capability, expect agencies to consider it, and assume the query records exist and are kept for a year.

For a New Zealand organisation the practical reading is straightforward. If you are a government agency, this is a should you will be asked about, and “we considered it” is a better answer with evidence attached. If you are not, you are looking at a control that two allied governments have made compulsory for their own departments and that your own national manual names — which is about as clear a signal of settled good practice as this field produces.

Doing it properly

The difference between a protective resolver that works and one that merely exists comes down to four things, none of them exotic:

Own the resolver. If the filtering happens somewhere you cannot see, you cannot tell whether it is still happening. Running it yourself — or at minimum holding the records yourself — is what makes the rest possible.

Enforce it. A resolver that devices may use is a suggestion. Traffic to other resolvers has to be redirected or refused, or the devices that most need protecting are the ones that will quietly opt out.

Watch for bypass. New equipment arrives with its own opinions. The useful question is not “is filtering enabled” but “what tried to go around it this week”, and that question can only be answered from records.

Monitor the protection itself. A resolver that stops filtering usually keeps resolving perfectly, so nothing appears to be wrong. Silence is not evidence of health; the failure mode of this control is that it fails invisibly, which is why the monitoring is part of the service rather than an extra.