Every time someone in your office opens a website, sends an email, connects to a cloud application, or joins a video call, there’s an invisible system working behind the scenes to make it happen. That system is the Domain Name System — DNS — and it’s one of the most overlooked yet business-critical components of your IT infrastructure.
DNS is often described as the “phone book of the internet,” but that analogy barely scratches the surface. For UK businesses, DNS affects everything from website loading speeds and email deliverability to cybersecurity posture and regulatory compliance. A poorly configured DNS setup can slow your team down, leave you vulnerable to attacks, and cause intermittent outages that are maddeningly difficult to diagnose.
In this comprehensive guide, we’ll break down exactly how DNS works, explore the security and performance decisions you need to make, and show you how to optimise DNS for your business — whether you’re running a 10-person office or a multi-site enterprise operation.
How DNS Actually Works
Before we discuss optimisation, you need to understand the mechanics. DNS translates human-readable domain names (like cloudswitched.com) into the numerical IP addresses (like 104.21.56.78) that computers use to find each other on the internet. Without DNS, you’d have to memorise IP addresses for every website and service you use.
Here’s what happens every time someone in your office types a URL into their browser:
Step 1 – The Local Cache Check
The browser first checks its own cache to see if it’s looked up that domain recently. If not, it asks the operating system, which checks its own cache. If the answer is already stored locally, the process stops here — fast and efficient.
Step 2 – The Recursive Resolver
If the answer isn’t cached locally, the query goes to a recursive resolver — typically provided by your internet service provider or a third-party DNS service like Cloudflare (1.1.1.1) or Google (8.8.8.8). This resolver does the heavy lifting of finding the answer.
Step 3 – The Root Name Servers
If the recursive resolver doesn’t have the answer cached, it starts at the top of the DNS hierarchy: the root name servers. There are 13 root server clusters worldwide (identified as A through M), and they direct the resolver to the correct top-level domain (TLD) server — for example, the .com, .co.uk, or .org.uk servers.
Step 4 – The TLD Name Servers
The TLD server knows which authoritative name server is responsible for the specific domain being queried. For a .co.uk domain, Nominet’s TLD servers direct the query onwards.
Step 5 – The Authoritative Name Server
This is the final stop. The authoritative name server holds the actual DNS records for the domain — A records (IPv4 addresses), AAAA records (IPv6), MX records (mail servers), CNAME records (aliases), TXT records (verification and policy data), and more. It returns the requested information to the recursive resolver.
Step 6 – The Response
The recursive resolver caches the answer (for the duration specified by the record’s TTL — Time to Live) and passes it back to the user’s device. The browser can now connect to the correct server. This entire process typically takes between 20 and 200 milliseconds — but those milliseconds add up across thousands of queries per day.
A typical office worker generates between 1,000 and 3,000 DNS queries per day just through normal work activity — web browsing, email, cloud apps, background updates, and telemetry. In an office of 50 people, that’s up to 150,000 DNS lookups daily. Every millisecond of unnecessary delay in each query represents real, cumulative productivity loss.
Public DNS vs. Private DNS
One of the most impactful DNS decisions a business can make is choosing between public and private DNS resolvers — or, more commonly, understanding when to use each.
Public DNS Resolvers
These are free, publicly accessible DNS services operated by major technology companies. The most popular options include:
| Provider | Primary IP | Secondary IP | Key Feature |
|---|---|---|---|
| Cloudflare | 1.1.1.1 | 1.0.0.1 | Fastest global response times, strong privacy commitment |
| Google Public DNS | 8.8.8.8 | 8.8.4.4 | Massive global infrastructure, high reliability |
| Quad9 | 9.9.9.9 | 149.112.112.112 | Built-in threat blocking, Swiss-based non-profit |
| OpenDNS (Cisco) | 208.67.222.222 | 208.67.220.220 | Content filtering, enterprise management dashboard |
| ISP Default | Varies | Varies | Usually slowest, may log browsing data for commercial use |
Private / Internal DNS
Private DNS is a DNS infrastructure you operate internally, typically on a Windows Server running the DNS Server role as part of Active Directory (which we’ll cover in detail later). Private DNS resolves internal hostnames — things like fileserver.yourdomain.local or printer-floor2.office.lan — that don’t exist on the public internet.
Most UK businesses with on-premises infrastructure need both: private DNS for internal name resolution and a public recursive resolver for internet queries. Getting this interplay right is critical for performance and reliability.
Public DNS Resolvers
Private / Internal DNS
DNS Security: Protecting Your Business from DNS-Based Attacks
DNS was designed in the 1980s with functionality, not security, in mind. The original protocol sends queries and responses as unencrypted plain text, making it trivially easy for attackers to intercept, modify, or spoof DNS traffic. For businesses, this is a serious vulnerability that demands attention.
DNSSEC – Domain Name System Security Extensions
DNSSEC adds a layer of authentication to DNS responses by digitally signing DNS records. When your resolver receives an answer, it can verify that the response genuinely came from the authoritative name server and hasn’t been tampered with in transit.
Without DNSSEC, your business is vulnerable to DNS cache poisoning — an attack where a malicious actor injects forged DNS responses into a resolver’s cache, redirecting your staff to fraudulent websites. Imagine your team thinking they’re logging into your banking portal but actually entering credentials on an attacker’s clone site. DNSSEC prevents exactly this.
Key points for UK businesses:
- DNSSEC validation should be enabled on your recursive resolver — most major public resolvers (Cloudflare, Google, Quad9) support it by default
- DNSSEC signing should be enabled on your own domain’s authoritative DNS — your domain registrar or DNS hosting provider can enable this
- Nominet (the .uk registry) fully supports DNSSEC for all .uk and .co.uk domains
- DNSSEC does not encrypt queries — it only authenticates responses. You still need DoH or DoT for privacy.
DNS over HTTPS (DoH)
DoH encrypts DNS queries by wrapping them inside standard HTTPS traffic on port 443. This means your DNS lookups are indistinguishable from normal web browsing traffic, making it extremely difficult for anyone — including your ISP, a coffee-shop Wi-Fi operator, or an attacker on your network — to see which domains your devices are querying.
Most modern browsers (Chrome, Firefox, Edge) now support DoH natively, and it can be configured at the operating system level on Windows 11 and macOS.
DNS over TLS (DoT)
DoT encrypts DNS queries using the TLS protocol on a dedicated port (853). Unlike DoH, which blends into web traffic, DoT is identifiable as DNS traffic — which has pros and cons. Network administrators can see that DNS queries are happening (useful for monitoring and compliance), but the content of those queries remains encrypted.
DoT is generally preferred in business environments because it maintains the visibility that network admins need while still protecting query privacy from external eavesdroppers.
Be cautious about enabling DoH on individual employee devices without a central policy. When browsers use DoH directly, they bypass your company’s DNS infrastructure entirely — which means your DNS filtering, logging, and security policies stop working. If you want encrypted DNS (and you should), configure it at the network level through your firewall or internal resolver, not on individual endpoints.
Common DNS Attack Vectors
| Attack Type | How It Works | Business Impact | Mitigation |
|---|---|---|---|
| DNS Cache Poisoning | Forged responses injected into resolver cache | Staff redirected to phishing sites, credential theft | DNSSEC validation on resolvers |
| DNS Tunnelling | Data exfiltrated by encoding it inside DNS queries | Sensitive data stolen without triggering firewalls | DNS monitoring, anomaly detection |
| DNS Hijacking | Attacker alters DNS settings on device or router | All traffic routed through malicious servers | Router hardening, DNS change monitoring |
| DDoS via DNS Amplification | Open resolvers exploited to amplify attack traffic | Network overwhelmed, services unavailable | Disable open resolvers, rate limiting |
| Typosquatting / Lookalike Domains | Attackers register domains similar to yours | Phishing attacks targeting your staff or customers | DNS filtering, domain monitoring services |
DNS Filtering: Your First Line of Cyber Defence
One of the most cost-effective security measures any UK business can implement is DNS-level filtering. Instead of waiting for malware to reach an endpoint and relying on antivirus to catch it, DNS filtering blocks connections to known malicious domains before any data is exchanged.
Here’s how it works: when a device on your network tries to resolve a domain name, the DNS filter checks it against continuously updated threat intelligence feeds. If the domain is associated with malware, phishing, command-and-control servers, or other threats, the query is blocked — and the user sees a block page instead of reaching the dangerous site.
What DNS Filtering Can Block
DNS filtering isn’t a silver bullet — it won’t catch everything, particularly zero-day threats — but it blocks the vast majority of known threats at virtually zero performance cost. It’s one of the few security measures that’s genuinely “set and forget” once properly configured.
Popular DNS Filtering Solutions for UK Businesses
| Solution | Best For | Typical Cost | Key Differentiator |
|---|---|---|---|
| Cisco Umbrella | Mid-to-large businesses | £2–£4/user/month | Industry-leading threat intelligence, Talos integration |
| Cloudflare Gateway | Businesses of all sizes | Free (basic) to £5/user/month | Fast performance, Zero Trust integration |
| DNSFilter | SMEs, MSPs | £1–£3/user/month | AI-powered categorisation, easy deployment |
| Infoblox BloxOne Threat Defense | Enterprise | Custom pricing | Deep DNS analytics, hybrid on-prem/cloud |
| Pi-hole (Open Source) | Small offices, technical teams | Free (self-hosted) | Fully customisable, ad-blocking included |
For UK businesses subject to Cyber Essentials certification, DNS filtering directly contributes to the “Malware Protection” control. Implementing DNS-level filtering alongside endpoint protection demonstrates a layered security approach — exactly what auditors want to see.
Choosing the Right DNS Provider
Not all DNS services are created equal. The difference between a well-chosen DNS provider and a default ISP resolver can mean faster page loads, stronger security, and greater reliability for your entire organisation. Here’s what to evaluate:
Performance Factors
For most UK businesses, the practical recommendation is: use Cloudflare (1.1.1.1) or Quad9 (9.9.9.9) as your external recursive resolvers. Both offer excellent performance from UK data centres, strong privacy commitments, and DNSSEC validation by default. If you need content filtering and management dashboards, Cisco Umbrella or Cloudflare Gateway are the leading choices.
Crucially, stop using your ISP’s default DNS resolvers. They are almost universally slower, less reliable, and less private than the dedicated alternatives. Some UK ISPs also inject advertising or tracking into DNS responses, and many do not support DNSSEC validation.
Internal DNS for Active Directory
If your business runs Windows Server with Active Directory — and the vast majority of UK SMEs with on-premises infrastructure do — then internal DNS isn’t optional. It’s mandatory. Active Directory depends entirely on DNS to function.
Why Active Directory Needs DNS
Active Directory uses DNS to locate domain controllers, authenticate users, replicate data between servers, and resolve internal resource names. Without properly functioning internal DNS, Active Directory simply stops working — and when AD stops working, nobody can log in, access shared drives, print documents, or use group policies.
Key DNS records that Active Directory depends on include:
- SRV records — Service locator records that tell domain-joined machines where to find domain controllers, Kerberos authentication servers, LDAP services, and Global Catalogue servers
- A records — Standard host records mapping server names to IP addresses
- PTR records — Reverse lookup records that map IP addresses back to hostnames — essential for authentication and logging
- CNAME records — Alias records used for service discovery and load distribution
Best Practices for AD-Integrated DNS
- Always use AD-integrated DNS zones — Store DNS data in Active Directory itself, not in standard zone files. This provides automatic replication, secure dynamic updates, and eliminates single points of failure.
- Point all domain-joined machines to internal DNS servers — Never point workstations directly at external resolvers like 8.8.8.8. They need to query internal DNS first to find domain controllers.
- Configure DNS forwarders on your internal servers — Your internal DNS servers should forward external queries (for public websites) to your chosen external resolver (Cloudflare, Quad9, etc.).
- Run DNS on at least two domain controllers — Redundancy is essential. If your sole DNS server fails and it’s also your only domain controller, your entire network goes down.
- Enable DNS scavenging — Stale records accumulate over time as devices leave the network. Scavenging automatically removes outdated records, keeping your DNS zones clean and accurate.
One of the most common — and most damaging — DNS misconfigurations we encounter in UK SMEs is workstations pointed directly at external DNS servers like Google (8.8.8.8) instead of their internal domain controllers. This causes intermittent authentication failures, Group Policy not applying, mapped drives disconnecting randomly, and printers disappearing. If your staff experience “phantom” connectivity issues that come and go, check your DNS client settings immediately.
Split-Brain DNS (Split-Horizon DNS)
Split-brain DNS — also called split-horizon DNS — is a configuration where the same domain name resolves to different IP addresses depending on whether the query comes from inside or outside your network. It’s a common and powerful pattern for UK businesses that host their own services.
When You Need Split-Brain DNS
Consider a business that runs a web application internally at app.yourcompany.co.uk. When an employee in the office accesses it, you want them to connect directly to the internal server (say, 192.168.1.50) without their traffic leaving the network. But when a remote worker or customer accesses the same domain from the internet, they need to reach the public IP address (say, 203.0.113.25) which routes through your firewall.
Without split-brain DNS, internal users would resolve the public IP, their traffic would go out to the internet and come back in through the firewall — a process called hairpinning or NAT loopback — which is slower, increases firewall load, and often doesn’t work at all depending on your router’s capabilities.
How to Implement It
- Create an internal DNS zone matching your public domain on your internal DNS servers
- Add records for internal services that point to private IP addresses
- Use conditional forwarders for any subdomains you don’t want to override internally
- Document everything — split-brain DNS is a common source of confusion during troubleshooting because the same domain gives different answers depending on where you query from
Split-brain DNS is particularly useful for businesses running Microsoft Exchange, SharePoint, remote desktop services, or any internally hosted application that also needs to be accessible externally.
DNS Caching: The Silent Performance Multiplier
DNS caching is one of the simplest yet most effective ways to improve network performance. Every DNS record has a TTL (Time to Live) value that tells resolvers how long to cache the answer before asking again. Optimising your caching strategy can dramatically reduce DNS lookup times and external query volumes.
Where DNS Caching Happens
- Browser cache — Chrome, Firefox, and Edge maintain their own DNS caches, typically for 60 seconds
- Operating system cache — Windows, macOS, and Linux cache DNS responses at the OS level
- Local DNS server — Your internal DNS server caches responses from upstream resolvers
- Recursive resolver — Your chosen external resolver (Cloudflare, Google, etc.) caches responses from authoritative servers
- Firewall / router cache — Many business firewalls include a DNS proxy with caching capabilities
TTL Optimisation Guidelines
| Record Type | Recommended TTL | Rationale |
|---|---|---|
| A / AAAA (stable services) | 3600–86400 (1–24 hours) | Reduces query load; change infrequently |
| A / AAAA (pre-migration) | 300 (5 minutes) | Allows fast cutover when changing IP addresses |
| MX (mail servers) | 3600–14400 (1–4 hours) | Balances caching with reasonable failover time |
| CNAME (aliases) | 3600 (1 hour) | Standard caching for stable aliases |
| TXT (SPF, DKIM, DMARC) | 3600–86400 (1–24 hours) | Rarely change; longer caching improves email auth speed |
| NS (nameserver) | 86400–172800 (1–2 days) | Very rarely change; long cache is appropriate |
A common mistake is setting all TTLs to very low values “just in case.” This generates unnecessary query traffic, increases latency, and puts more load on your DNS infrastructure. Set TTLs high for stable records and only lower them temporarily when you’re planning a change.
Monitoring DNS Performance
You can’t optimise what you don’t measure. DNS performance monitoring is essential for maintaining a fast, reliable, and secure network. Yet the majority of UK SMEs have zero visibility into their DNS performance.
Key Metrics to Monitor
Monitoring Tools
Effective DNS monitoring doesn’t require enterprise-grade investment. Here are practical options at various budget levels:
- PRTG Network Monitor — Includes DNS sensor types that track response time, resolution success, and server availability. The free tier covers up to 100 sensors.
- Zabbix — Open-source monitoring with DNS query templates. Excellent for businesses with technical staff who can manage the platform.
- Cloudflare Radar / Cloudflare Gateway Analytics — If you use Cloudflare for DNS, their built-in analytics provide query-level visibility at no extra cost.
- Windows DNS Debug Logging — Built into Windows Server DNS. Generates detailed logs of all queries and responses, useful for troubleshooting but resource-intensive if left running permanently.
- DNSPerf.com — Free external tool that benchmarks authoritative DNS provider performance from multiple global locations.
Common DNS Issues and How to Fix Them
After managing DNS infrastructure for hundreds of UK businesses, we’ve identified the problems that come up time and time again. Here’s a troubleshooting reference for the most frequent DNS issues.
Issue 1: Slow DNS Resolution
Symptoms: Websites load slowly (especially the initial connection), cloud apps feel sluggish, but once loaded everything is fast.
Common causes: Using slow ISP DNS resolvers, DNS server overloaded, misconfigured forwarders, no local caching, high TTL churn.
Fix: Switch to a fast external resolver (Cloudflare 1.1.1.1 or Quad9 9.9.9.9), verify forwarder configuration on internal DNS servers, check that DNS caching is working (monitor cache hit ratio), and review TTL values on frequently queried records.
Issue 2: Intermittent Name Resolution Failures
Symptoms: Staff randomly can’t reach websites or internal resources. The problem comes and goes. Restarting the computer sometimes fixes it temporarily.
Common causes: DHCP assigning incorrect DNS servers, one of multiple DNS servers failing, DNS server running out of resources, stale DNS cache entries.
Fix: Check DHCP scope settings for correct DNS server assignments, verify all DNS servers are healthy and responding, flush the DNS cache on affected machines (ipconfig /flushdns on Windows), and review DNS server event logs for errors.
Issue 3: Internal Resources Not Resolving
Symptoms: Staff can browse the internet but can’t access file servers, SharePoint, or internal applications by name.
Common causes: Workstations pointing at external DNS instead of internal, missing DNS records for internal resources, DNS suffix not configured, Dynamic DNS registration failed.
Fix: Ensure all domain-joined machines use internal DNS servers as their primary resolver, verify internal DNS zones contain correct records, check that the DNS suffix search list includes your AD domain, and confirm Dynamic DNS updates are working.
Issue 4: Email Delivery Problems
Symptoms: Emails not being received, emails landing in spam, SPF/DKIM/DMARC failures.
Common causes: Incorrect MX records, missing or malformed SPF TXT record, DKIM DNS record not published, DMARC policy not configured.
Fix: Audit all email-related DNS records using tools like MXToolbox or Google Admin Toolbox. Verify MX records point to the correct mail servers with proper priority values. Ensure SPF, DKIM, and DMARC TXT records are correctly published and validated.
Issue 5: DNS Propagation Delays After Changes
Symptoms: You’ve changed a DNS record but the old value is still being returned. Some people see the new value; others see the old one.
Common causes: High TTL values on the old record mean caches haven’t expired yet. Multiple layers of caching (browser, OS, resolver) each holding the old value.
Fix: Before making DNS changes, lower the TTL to 300 seconds (5 minutes) at least 24 hours in advance. After making the change, wait for the old TTL to expire. Use nslookup or dig to query specific resolvers directly and verify propagation. After confirming the change, raise the TTL back to its normal value.
Breakdown of DNS support tickets we handle for UK SME clients (2024–2025 data).
Bringing It All Together: A DNS Optimisation Checklist
To summarise everything we’ve covered, here’s a practical checklist for optimising DNS across your business. Work through it from top to bottom, and you’ll address the most impactful areas first.
| Priority | Action | Complexity | Impact |
|---|---|---|---|
| 1 | Switch external DNS resolvers from ISP default to Cloudflare or Quad9 | Low | High |
| 2 | Implement DNS filtering (Cisco Umbrella, Cloudflare Gateway, or equivalent) | Low–Medium | High |
| 3 | Verify all workstations use internal DNS servers as primary resolver | Low | High |
| 4 | Enable DNSSEC validation on your resolvers and signing on your domains | Medium | High |
| 5 | Audit and optimise TTL values across all DNS records | Low | Medium |
| 6 | Configure split-brain DNS for internally hosted services | Medium | Medium |
| 7 | Enable encrypted DNS (DoT or DoH) at the network level | Medium | Medium |
| 8 | Set up DNS performance monitoring and alerting | Medium | Medium |
| 9 | Review and harden internal DNS server configurations | Medium–High | Medium |
| 10 | Document your complete DNS architecture (internal, external, forwarders, zones) | Low | Medium |
DNS is one of those areas where a relatively small investment of time and expertise yields disproportionately large returns in performance, security, and reliability. Most of the optimisations above can be implemented in a matter of hours by someone who knows what they’re doing — and the benefits are felt immediately across your entire organisation.
If you’re not sure where your DNS infrastructure stands today, or you’d like an expert to review your setup and recommend improvements, that’s exactly the kind of work Cloudswitched does for UK businesses every day. We can audit your current DNS configuration, identify gaps and risks, and implement a properly optimised, secure DNS architecture tailored to your business needs.
Optimise Your DNS — Improve Speed, Security & Reliability
Whether you need a full DNS overhaul, help implementing DNS filtering, or simply want an expert review of your current setup, Cloudswitched can help. We work with UK businesses of all sizes to build fast, secure, and properly managed DNS infrastructure that just works.
CloudSwitched
London-based managed IT services provider offering support, cloud solutions and cybersecurity for SMEs.