Stop Blaming DNS and Start Understanding Your Own Bloody Network

I am going to say something that will upset the technically comfortable and bore the technically indifferent, but it needs saying regardless.

DNS is the messenger, not the murderer.

As Graham put it on this week’s podcast, and annoyingly elegantly at that: DNS may be the first component to reveal that something is amiss. It is not, therefore, the author of every calamity.

We have spent this entire week pulling apart the DNS blame reflex. Monday’s companion post covered the podcast discussion. Tuesday’s deep dive examined the real DNS security threats. Wednesday’s analysis from Mauven looked at the gap between public and private sector DNS protection. Thursday’s guide from Graham laid out the practical troubleshooting steps. Friday’s case study from Lucy showed what happens when you spend three weeks blaming DNS while a compromised router rewrites your network.

But here is what sits underneath all of it, the thing that DNS misdiagnosis is really a symptom of: most UK small businesses do not understand their own network infrastructure. And a network you do not understand is a network you cannot defend.

The Black Box Problem

Ask the owner of a typical UK SMB to describe their network and you will get something like this: “We have broadband, a router thing, the wifi, and the internet.”

That is it. That is the depth of understanding. The router is a plastic box in the corner that an engineer from the ISP installed two years ago. Nobody has logged into it since. Nobody knows the admin password. Nobody knows what firmware version it runs. Nobody knows what DNS servers it uses. Nobody knows whether it has a firewall or what the rules are.

The network is a black box. Things go in, things come out, and when they stop coming out, someone says “must be DNS” because that is the only technical-sounding thing they have heard of.

This is not a criticism of intelligence. Running a small business is hard enough without also becoming a network engineer. But it is a statement of fact about risk. If you do not know what your network looks like when it is healthy, you cannot possibly know when something has changed. And if you cannot detect changes, you cannot detect compromise.

The Competence Gap Nobody Addresses

The DSIT Cyber Security Breaches Survey 2025 found that 43% of UK businesses reported a breach or attack in the past twelve months. It also found that smaller organisations lag behind in implementing security measures. The decline in reported breaches among micro and small businesses was attributed primarily to fewer phishing attacks, not to improved defences.

Here is what the survey does not capture: how many small businesses experienced a DNS-related security issue and never knew about it. Because without DNS monitoring, without logging, without even a basic understanding of what their resolver settings should be, there is no mechanism to detect that anything happened.

The case study we published on Friday illustrated this perfectly. A compromised router redirected DNS queries for three weeks. The firm had no logs. No baseline. No documentation. The incident was discovered only because a vendor’s support team guided them through a comparison that should have happened on day one.

That is not a failure of technology. That is a failure of understanding.

What a Minimum Viable Network Understanding Looks Like

I am not asking small business owners to study for a CCNA. I am asking for the absolute minimum: know enough about your network to detect when something is wrong.

Know your router. What model is it. Who installed it. When was it last updated. What are the admin credentials, and have they been changed from the factory defaults. What DNS servers does it use.

Know your broadband. Who is the ISP. What is the connection type. Is there a static IP or dynamic IP. What is the advertised speed versus the actual speed. Does the ISP perform any DNS filtering or transparent proxying.

Know your DNS configuration. What resolver do your devices use. Is it the ISP default, a public resolver, or a protective DNS service. When was it last set, and by whom. Is it documented anywhere.

Know your devices. How many devices connect to your network. Are they all known. When was the last time someone checked for unfamiliar connected devices.

This is not exhaustive. It is not technically demanding. It is the equivalent of knowing where the mains fuse box is in your premises and what each switch does. Basic operational literacy for the infrastructure your business depends on.

The IT Support Dependency Problem

Many small businesses outsource their IT to a sole trader or a small MSP. That is perfectly sensible. But it creates a dependency that becomes dangerous when it prevents the business from understanding its own infrastructure.

If the only person who knows what DNS resolver your router uses is an external IT consultant who visits once a month, you have a knowledge single point of failure. If that consultant is unavailable when something breaks, the business is helpless. If the consultant changes settings without documenting them, the business has no baseline to compare against.

The relationship with an IT provider should be collaborative, not opaque. You should know what they have configured, why, and where the documentation lives. If they resist providing that information, you have a different kind of problem.

DNS Is Just the Beginning

Everything I have said about DNS this week applies equally to every other component of your network infrastructure.

Do you know what firewall rules are active on your router? Do you know whether your wifi uses WPA3 or an older, weaker protocol? Do you know which ports are open to the internet? Do you know whether your ISP router has UPnP enabled, silently allowing devices to open ports without your knowledge?

Most small businesses do not know the answer to any of these questions. And the answer to each one has security implications.

DNS gets the attention because it produces visible symptoms: websites do not load, and that triggers an immediate response. But the quiet misconfiguration of a firewall rule, or an open port nobody authorised, or a UPnP-enabled IoT device that has punched a hole through your perimeter: these produce no symptoms at all until they are exploited.

The Cultural Shift Required

The shift I am asking for is not technical. It is cultural. It is the difference between treating your network as someone else’s problem and treating it as the foundation your business operates on.

You would not run a restaurant without understanding your food hygiene requirements, even if you outsource the deep clean. You would not run a construction site without understanding health and safety obligations, even if you employ a safety officer. You should not run a business that depends on its network without understanding the basics of how that network works.

That does not mean doing the technical work yourself. It means knowing enough to ask the right questions, verify the answers, and detect when something has changed.

How to Turn This Into a Competitive Advantage

Businesses that understand their own infrastructure respond faster to incidents, make better decisions about technology investments, and present a more credible security posture to clients and partners.

If you are in a sector where clients ask about your security practices, being able to describe your network architecture, your DNS configuration, and your monitoring approach is immediately differentiating. Most competitors cannot do this. They will say “we have an IT person who handles that.” You will say “here is our documented configuration, our protective DNS policy, and our incident response process.” The gap is obvious.

How to Sell This to Your Board

Operational resilience depends on understanding. A business that does not understand its own network cannot diagnose problems efficiently, cannot detect compromise, and cannot plan infrastructure changes intelligently. That is operational risk.

Insurance and compliance expectations are rising. Cyber insurance providers and regulatory bodies increasingly expect evidence of security controls. Documented network configurations, DNS policies, and monitoring capabilities are becoming baseline expectations.

The cost of ignorance is higher than the cost of learning. Spending half a day documenting your network, understanding your DNS configuration, and establishing a baseline is cheaper than spending three weeks chasing the wrong problem while a compromised router exfiltrates client data.

What This Means for Your Business

1. Spend one hour this week documenting your network. Router model, admin credentials location, DNS settings, broadband provider, connection type. Write it down. Store it somewhere accessible. This is your baseline.

2. Log in to your router. Check the admin credentials. Check the DNS settings. Check the firmware version. If you cannot do any of these things, that is the first problem to solve.

3. Ask your IT provider for documentation. If they manage your network, ask for a written summary of what is configured, when it was last reviewed, and what DNS resolver is in use. If they cannot or will not provide this, consider what that tells you.

4. Set a quarterly review date. Put a recurring calendar entry to check router firmware updates, verify DNS settings, and review connected devices. Fifteen minutes, four times a year.

5. Start with DNS and work outwards. This week’s content has given you the tools to understand, troubleshoot, and secure your DNS configuration. That is one component of your network understood. Apply the same approach to your firewall, your wifi security, and your device management.

Source	Article
NCSC	Small Business Guide
NCSC	Protective DNS for the private sector
DSIT / GOV.UK	Cyber Security Breaches Survey 2025
NCSC	Managing Public Domain Names
NCSC	Protective Domain Name Service (PDNS)
Cloudflare	1.1.1.1 DNS Resolver
Quad9	Quad9 DNS Security and Privacy