It Is Always DNS, Except When It Isn't: Why Your Office Blames the Wrong Suspect Every Single Time

Podcast

It Is Always DNS, Except When It Isn't: Why Your Office Blames the Wrong Suspect Every Single Time

Forty three percent of UK businesses reported a cyber breach or attack in the past twelve months, according to the DSIT Cyber Security Breaches Survey 2025. A meaningful chunk of those incidents started with something that looked, sounded, and smelled like a DNS problem. Except it was not.

This week on The Small Business Cyber Security Guy podcast, I sat down with Mauven MacLeod, Lucy Harper, and Graham Falkner to tackle the most misdiagnosed problem in small business IT: the reflexive, unshakeable, almost religious conviction that every broken website, every failed login page, and every sulking printer is somehow DNS.

**Listen to the full episode: https://www.podbean.com/eas/pb-wb9nn-1aa0932 **

The Sacred Phrase

If you have worked in IT longer than about six minutes, you have heard it. “It is not DNS. There is no way it is DNS. It was DNS.”

The joke lands because it is occasionally true. DNS does sit right near the start of most web browsing. Type a friendly name like google.com and something has to turn that into an IP address. Without that translation, the browser is asking for directions with half the map missing.

But here is the bit that matters: DNS is the translator, not the entire diplomatic summit. You can have perfect DNS and still no website. Bad wifi, captive portals, browser cache full of stale nonsense, a router having a funny turn, a security product intercepting traffic: all of these dress up in a DNS costume and fool people into chasing the wrong culprit.

Why the Reflex Exists

The DNS blame reflex did not come from nowhere. DNS has a mythical status in IT culture because when it genuinely goes wrong, the results look magical and infuriating. So people overlearn the lesson. They had one horrible DNS incident in 2019 and now every broken web app gets treated like the return of the king.

As Mauven put it on the show: people hear “resolver cache” and half the room thinks a clever person is talking, so they stop questioning. Meanwhile the actual issue is the router dropping outbound requests.

What We Covered

This episode breaks down into three sections that every small business owner and their IT person needs to understand.

First, what DNS actually does. The plain English version. Browser asks for an IP address. If it does not know, it asks a resolver. The resolver climbs the tree: root name server, then TLD server, then authoritative name server. Catalogue, page, line item. Once the answer comes back, only then does the browser make the actual web request. It is a chain of questions getting more specific, not one magical box.

Second, genuine DNS failure versus DNS-looking failure. This is the distinction that saves hours. Genuine DNS failure means the record is wrong, the authoritative name server is not answering, or answers have been poisoned. DNS-looking failure is far more common: the device cannot talk to the resolver, the internet connection is unstable, the router is misbehaving, or a security control is blocking queries.

Third, the troubleshooting sequence. Another device. Another network. Check resolver reachability. Clear cache. Compare the IP you get back. Five steps. No interpretive dance required.

The Security Angle You Cannot Afford to Miss

This is where the conversation got properly serious. Because a DNS-looking issue might not be innocent incompetence. It could be tampering.

Rogue DNS settings on a device or router can redirect users somewhere they never meant to go. Cache poisoning stuffs corrupt data into the cache so users are sent to the wrong IP address. From the user’s point of view, it is just “the site is weird today.” From a security perspective, that is potentially a serious compromise.

The NCSC’s Protective DNS service has resolved over 2.5 trillion DNS queries and prevented access to 1.5 million malicious domains since 2017. That is the scale of the threat. For private sector SMBs who do not qualify for NCSC’s PDNS, the guidance is clear: source protective DNS from trusted commercial providers with proven cyber security expertise.

In October 2025, three critical vulnerabilities were disclosed in BIND 9, the software that powers a significant portion of the internet’s DNS infrastructure. Two of those vulnerabilities enabled cache poisoning attacks. Over 706,000 exposed instances were identified worldwide. This is not theoretical. This is current.

The Business Trap

Small businesses get hit hardest by DNS misdiagnosis because they do not have time for elegant diagnostics. They have invoices to send, customers waiting, and somebody from sales declaring the website dead with the emotional energy of a Shakespearean messenger.

So one person says “DNS” and the whole room runs at it. Hours vanish. The actual problem, usually something mundane like a router config change or a security product behaving unexpectedly, sits quietly in the corner waiting to be discovered.

The operational cost is wasted time. The security cost is potentially dismissing genuine tampering as just another boring outage.

How to Turn This Into a Competitive Advantage

Understanding DNS properly puts you ahead of most competitors who still treat network problems like a guessing game. When your clients or partners experience an outage, you can respond methodically while everyone else panics. That builds trust and professional reputation.

If you are tendering for contracts that require cyber security credentials, demonstrating that your team follows a structured troubleshooting process and uses protective DNS shows maturity. It separates you from businesses that are still poking settings and hoping for the best.

Document your DNS configuration. Choose known-good resolvers. Monitor for changes. These are low cost steps that signal operational competence to anyone evaluating your business.

How to Sell This to Your Board

Three arguments that will land in any boardroom.

Wasted time has a price tag. Every hour spent chasing the wrong network problem is an hour not spent on revenue-generating activity. A structured troubleshooting process reduces mean time to resolution. That is directly measurable.

Security incidents hide behind boring complaints. The DSIT survey shows 43% of UK businesses experienced a breach or attack. Rogue DNS and cache poisoning can masquerade as routine outages. If your team dismisses every “the website is slow” complaint without proper investigation, you may be missing active compromise.

The regulator recommends it. The NCSC explicitly recommends protective DNS for private sector organisations. Following their published guidance is a defensible position. Ignoring it is not.

What This Means for Your Business

  1. Stop assuming DNS is the problem. Train your team or IT provider to follow the five-step troubleshooting sequence: test another device, try another network, check resolver reachability, clear cache, compare IP responses. Write it on a card and pin it to the wall if necessary.

  2. Choose and document your DNS resolvers. Pick known-good options like Cloudflare’s 1.1.1.1, Google Public DNS 8.8.8.8, or Quad9’s 9.9.9.9. Document what you have chosen. Do not let every device wander off onto whatever DNS server it fancies.

  3. Consider protective DNS. The NCSC recommends it for a reason. Commercial PDNS services block access to known malicious domains before your users can reach them. For businesses with remote workers, a roaming DNS client extends that protection outside the office network.

  4. Monitor for unusual DNS activity. If devices suddenly start using unfamiliar DNS servers or resolver settings change without a planned reason, pay attention. That is not normal background noise. That is a question mark.

  5. Document every DNS change. The number of outages caused by someone tweaking a setting on Thursday and forgetting to mention it constitutes a national pastime. If you change DNS settings, write it down. If you changed them as a test, change them back and write that down too.

Listen to the full episode: [Podcast Link]

Next week on the podcast: We dig deeper into DNS security threats, protective DNS options, and what the NCSC’s latest guidance means for businesses that cannot access the public sector PDNS service.

SourceArticle
NCSCProtective DNS for the private sector
NCSCProtective Domain Name Service (PDNS)
NCSCNCSC enters new partnership for PDNS delivery
NCSCManaging Public Domain Names
DSIT / GOV.UKCyber Security Breaches Survey 2025
ISCBIND 9 CVE-2025-40778 Cache Poisoning Vulnerability
Cloudflare1.1.1.1 DNS Resolver Documentation
Quad9Quad9 DNS Security and Privacy

Filed under

  • smb-security
  • uk-business
  • business-risk
  • remote-access
  • vendor-risk
  • incident-response
  • compliance-failure