In short
A DNS security test checks that devices really use your protective resolver and that it blocks what it should. Confirm each device's resolver, visit your provider's published test domains, repeat off site and on guest Wi-Fi, try bypass routes such as browser DNS over HTTPS, check DNSSEC on your domain and confirm tests appear in your logs.
Get a quote for a business DNS security review
Tell us roughly how many users or sites you have and we will reply by email with options and a quote.
What a DNS security test should prove
People searching for a "DNS security checker" usually want one button that says pass or fail. No single website can tell you that, because the answer depends on each device, network and policy. A useful test proves five things:
- The right resolver answers every lookup, from every site and device type.
- Threats are blocked: phishing, malware and command-and-control test domains return a block, not a page.
- Your policy applies to the right people: staff, guests and students each get their own rules.
- Bypass routes are closed: hard-coded DNS, DNS over TLS and browser DNS over HTTPS cannot route around the resolver.
- Everything is logged against the right network, device or user.
Run the tests below with a simple results sheet: test, device, location, expected result, actual result. You will need it again after every network change.
Step 1: confirm which resolver devices use
Start by finding out which DNS servers each device has been given and which one actually answers.
- On Windows, ipconfig /all lists the DNS servers for each network adapter, and nslookup with any domain shows which server answered.
- On macOS, iOS, Android and ChromeOS, the network details for the current Wi-Fi or Ethernet connection list the DNS servers.
- On routers and firewalls, check the DNS servers handed out by DHCP and the upstream servers the device itself uses.
- On Windows DNS servers, check the forwarders: they should list only your protective resolver's addresses.
Look for anything unexpected: an internet provider's DNS left as a secondary, a public resolver typed in by hand, or a VPN that pushes its own DNS. Many protective DNS services also publish a test page or domain that confirms your lookups are reaching them. For Cisco Umbrella, our sister site lists Cisco's published test destinations on its Umbrella DNS servers page; for other services, use the test domains in your provider's own documentation.
Step 2: check that threats and categories are blocked
Next, check that the resolver blocks what it should. Do not visit real malicious sites to test this. Use the harmless test domains your provider publishes for phishing, malware and command-and-control checks, which resolve to a block when protection works. Cisco, for example, publishes Umbrella test destinations for DNS-layer coverage, such as welcome.umbrella.com (confirms your lookups reach Umbrella) and internetbadguys.com (should show a block page for phishing); Cisco's Secure Access documentation has its own test destinations page, so use the list for the service you run.
| Test | How to run it | What a pass looks like |
|---|---|---|
| Resolver check | Visit your provider's configuration test page or domain | The provider confirms your lookups reach it |
| Phishing block | Visit the provider's phishing test domain | A block page, sinkhole or NXDOMAIN, as your policy defines |
| Malware and C2 block | Visit the provider's malware and command-and-control test domains | A block response for each |
| Content category | Visit a site in a category your policy blocks | A block page for the right group only |
| SafeSearch | Search for an explicit term on Google, Bing or YouTube | Filtered results, where your service enforces SafeSearch via DNS |
| Logging | Search the dashboard or SIEM for each test | Every test appears against the right identity |
If a block shows as a browser certificate warning instead of a branded page, that is expected with some block-page designs: the NCSC notes that redirecting to a block page may cause a certificate error. Installing your provider's root certificate, where it offers one, usually fixes the display.
Not sure which option fits? Ask us
Tell us what you need and we will recommend the right option for your organisation, with a quote.
Step 3: test off site, on guest Wi-Fi and on mobile data
Most gaps appear away from the main office network. Repeat the resolver and blocking tests:
- On a laptop at home and on a mobile hotspot, with the roaming client running. Check the client shows as protected in your dashboard.
- On the same laptop connected to the corporate VPN, and again with the VPN disconnected.
- On guest Wi-Fi, which should have its own policy and usually no access to internal names.
- At every branch site, not just head office.
- On phones and Chromebooks, if your service covers them. Our DNS roaming client guide compares which clients cover which platforms.
For Cisco Umbrella's roaming module, see Umbrella roaming client on our sister site.
Step 4: try the bypass routes
A determined user, a misconfigured app or malware will try to route around your resolver. Test the common routes on a managed device:
- Hard-coded DNS: set the device to use a public resolver by hand and try a lookup. If outbound port 53 is blocked except for your resolvers, it should fail.
- DNS over TLS: where the operating system allows it, point it at a public DoT resolver. Outbound port 853 should be blocked.
- Browser DNS over HTTPS: check each browser's secure DNS setting. On a managed device it should be off or locked to your protective resolver by policy, and users should not be able to change it. Then check whether a lookup made in the browser still appears in your logs.
- Filter-avoidance services: if your service offers a category for public DoH, proxy and anonymiser services, confirm it blocks a known one.
- VPNs: check whether personal VPN apps can be installed and whether your service or device policy blocks them.
If any test succeeds, see should you block DNS over HTTPS? and the DNS security best practices checklist for the fixes.
Is a business DNS security review the right fit for you?
We will check it against your systems and requirements and recommend the right option.
Step 5: check DNSSEC on your own domain
DNS security includes the domains you own. To check whether your domain is signed with DNSSEC, look for a DS record at the parent zone and DNSKEY records on your domain; dig with the +dnssec option shows the signatures, and public DNSSEC analysers will show whether the chain of trust is intact from the root to your domain. If your DNS host supports DNSSEC and it is not switched on, plan it carefully: a broken DNSSEC set-up stops validating resolvers reaching your domain.
While you are there, confirm that registrar lock is on and that every registrar and DNS hosting account uses multi-factor authentication. See DNS hijacking for why.
Schools, records and what to do when a test fails
Schools and colleges have their own test to run: the DfE filtering and monitoring standards expect an annual review, and SWGfL's free Test Filtering tool checks illegal and inappropriate content blocking without visiting harmful sites. Our school web filter test guide covers it.
When a test fails, note the device, location and time, check the resolver it used, and fix the route before re-testing. Common causes are a forgotten secondary DNS server, a branch firewall without outbound DNS rules, a browser DoH setting not covered by policy, or a roaming client that has stopped running.
If you would rather have someone else run these checks, we can carry out a DNS security review: testing your sites, devices and policies and giving you a short list of fixes in priority order, with the scope agreed at quote. Contact us to arrange one.
How Forever Systems helps with DNS security
We are an independent UK IT and cyber security provider and a Cisco Partner. We supply Cisco Umbrella and Cisco Secure Access DNS Defense, and a range of other DNS filtering options, so we can recommend what fits rather than one answer for everyone.
- Start with what you have: we look at your firewall, endpoint protection and Microsoft 365 licences first, as some already include DNS or web filtering
- Choosing a service: Cisco DNS-layer security, DNS filtering bundled with endpoint protection, or a protective DNS service from the public sector, compared in plain English
- Set-up and roll-out: network forwarding, roaming clients for laptops off site, policies, block pages and controls to stop encrypted DNS bypassing the filter
- Migration help, including planning a move from Umbrella DNS packages to Cisco Secure Access DNS Defense
- Ongoing help: policy changes, reporting reviews, licence management and renewals, agreed at quote
We work with businesses, schools, charities and public sector organisations.
Frequently asked questions
How do I test if my DNS filtering is working?
Check which resolver the device uses, then visit your provider's published test domains for phishing, malware and command and control. A working set-up returns a block for each, and the tests appear in your dashboard or SIEM against the right network, device or user.
How do I check which DNS resolver a device is using?
On Windows, ipconfig /all lists the DNS servers for each adapter and nslookup shows which server answered. On other devices, the network details show the DNS servers. Many protective DNS providers also publish a test page that confirms your lookups reach them.
How can I tell whether DNS over HTTPS is bypassing our filter?
Check each browser's secure DNS setting on a managed device: it should be off or locked to your protective resolver by policy. Then make a lookup in the browser and confirm it appears in your DNS logs. If it does not, the browser is likely using another resolver.
Is there an online DNS security checker?
Provider test pages confirm whether your lookups reach a particular service, and DNSSEC analysers check your own domain. No single website can test your whole set-up, because results depend on each device, network and policy, so run the checks on this page across your sites and devices.
How often should we test DNS security?
Test after any network change, new site, new device type or major browser or operating system update, and as part of a regular review. Schools should include filtering tests in the annual review the DfE standards expect.
Is it safe to test with real malicious websites?
No. Use the harmless test domains your provider publishes, which are designed to trigger a block, and for schools, SWGfL's Test Filtering tool, which checks blocking without visiting harmful content.
Still have a question about a business DNS security review?
Ask us and a member of our team will reply by email.