DNS security best practices: a checklist

The checklist at a glance

This list follows the NCSC's guidance on protective DNS and adds the steps that protect the domains you own. Work through it in order: the early items give the biggest gain for the least effort.

1 to 4: make every lookup go through your protective resolver

1. Use a protective DNS resolver. Public sector bodies and schools that are eligible should use the NCSC's free NCSC PDNS service; the NCSC says a commercial service is not a substitute where you qualify. Everyone else should choose a commercial service that meets the NCSC's selection criteria: deny lists fed by threat intelligence, admin-editable allow lists, logs you can export, roaming clients, DNSSEC support and an SLA.
2. Route all internal DNS through it. Point routers and firewalls at the protective resolver. Where you run Active Directory, leave clients on your domain controllers and set the protective resolver as the forwarder, so internal names still resolve locally. Remove any secondary public resolver: devices pick between configured servers, so an unfiltered backup is a route around your policy.
3. Block outbound DNS that bypasses it. The NCSC advises firewall rules that block outbound DNS on port 53 and port 853 unless it goes through your resolver. Allow only your internal DNS servers or forwarders to send DNS to the protective service.
4. Control DNS over HTTPS. DoH uses port 443, so a firewall rule alone will not stop it. The NCSC recommends disabling DoH in operating systems and browsers, or configuring it to use your protective resolver while keeping logging, and enforcing that through Group Policy and mobile device management. Some services also offer a category that blocks known public DoH and filter-avoidance services. See should you block DNS over HTTPS?.

5 to 7: cover every device and every group

1. Protect devices off site. A network-level resolver stops at the office door. Install a DNS roaming client on laptops, and on phones and Chromebooks where the service supports them, so lookups reach the protective resolver from home, hotels and mobile data. Check how the client behaves alongside your VPN.
2. Set policies by group. Staff, guests, contractors and, in schools, students need different rules. Separate guest Wi-Fi onto its own policy, and use identity integration (for example Microsoft Entra ID) where your service supports per-user rules.
3. Manage allow lists carefully. Add specific domains when a business service is wrongly blocked, record why, and review the list from time to time. Avoid allowing whole categories to fix one site.

Schools should also check their filtering against KCSIE and the DfE standards; our web filtering for schools hub explains how DNS filtering fits.

8: log, alert and review

The NCSC says organisations should have DNS logging in place as part of security monitoring, and that a protective DNS service's block data should feed alerting and incident investigation in a SIEM. In practice:

• Send protective DNS logs, and your internal DNS server logs, to your SIEM or log platform, so you can tie a blocked lookup to a device and user.
• Alert on repeated lookups for command-and-control or malware categories: one device trying again and again is a likely infection.
• Review blocked-domain reports regularly for patterns, such as a phishing campaign aimed at your staff or a category that is blocking legitimate work.
• Watch for signs of DNS tunnelling: long, random-looking subdomains and unusual query volumes to one domain.

Check how easily your provider's logs integrate with your tools before you buy; export options and retention differ between services. If you have no SIEM or nobody to watch alerts, a managed detection and response service can take that on.

9: secure the domains you own

DNS security is not only about outbound lookups. If an attacker changes your domain's records, they can redirect your website, intercept email or issue certificates in your name. Protect your own domains with:

• Registrar lock (transfer lock, and registry lock where your registrar offers it) so the domain cannot be moved without extra checks.
• Multi-factor authentication on every registrar and DNS hosting account, with as few people holding access as possible.
• DNSSEC signing, so resolvers that validate can detect forged answers for your domain.
• Accurate contact details and renewal dates, so an expired domain is not picked up by someone else.
• Change monitoring on important records such as MX, SPF, DMARC and your website addresses.

See DNS hijacking for how these attacks work and the symptoms to look for.

10 and 11: harden internal DNS and keep testing

1. Harden internal DNS servers. Keep them patched, allow recursive lookups only from your own networks, restrict zone transfers to known secondary servers, and do not expose internal DNS to the internet.
2. Test and repeat. Check that each site, each policy group and each type of device really uses the protective resolver, that bypass attempts fail and that blocks appear in your logs. Our DNS security test guide walks through the checks. Repeat after network changes, new sites and major browser or operating system updates.

DNS-layer protection sits comfortably alongside the five technical controls in Cyber Essentials: firewalls, secure configuration, user access control, malware protection and security update management.

Common mistakes to avoid

• Leaving the internet provider's DNS server, or a public resolver, as a secondary entry on routers or DHCP scopes.
• Pointing domain-joined computers straight at an external resolver, which breaks internal name resolution and leads to rushed exceptions.
• Protecting the office network but not laptops that work from home most of the week.
• Blocking port 53 on the firewall but forgetting port 853 and browser DNS over HTTPS.
• Allowing a whole category to unblock one website, instead of adding a single domain to the allow list.
• Collecting DNS logs that nobody looks at, with no alert for repeated command-and-control blocks.
• Securing outbound DNS while the registrar account for the company domain still uses a single shared password.

Each of these is quick to fix once someone has spotted it, which is why a short review and a proper DNS security test are worth the time.

Getting help

If you would like a second pair of eyes, we can review your DNS set-up against this checklist and give you a short list of fixes in priority order. Where you need a protective DNS service, we can compare the options we supply, from Cisco DNS-layer security to DNSFilter, Webroot, ThreatDown, Sophos, WatchGuard and SASE platforms, and help you deploy and tune it. Scope and pricing are confirmed at quote, so contact us to start.