You have no items in your shopping cart.
Menu

It Has to Be DNS: Why Every ISP Should Run Their Own DNS Infrastructure

“DNS is the lifeblood of the internet.”

If you’ve worked in networking long enough, you’ve heard the phrase: “It has to be DNS.”
Right up there with “It’s always MTU.” And more often than not, it really is DNS.

This article exists for one reason: As an Internet Service Provider, you should be running your own DNS infrastructure. DNS is not optional. It is a core dependency of your service, just like routing, switching, and transport. If you don’t control it, you don’t truly control your network.

Why Running Your Own DNS Matters

DNS directly impacts:

  • Page load speed
  • Application performance
  • Security
  • Customer perception of “internet speed”
  • Outage response time
  • Your ability to troubleshoot issues

If all your customers use 8.8.8.8 or 1.1.1.1, you have:

  • Zero visibility
  • Zero control
  • Zero influence during outages
  • Zero ability to prioritize your own customers

Ask yourself this: If Google or Cloudflare DNS has an outage, what leverage do you have?

The answer is simple: None.

Hardware Options: From Budget to Enterprise

Your DNS hardware doesn’t need to be fancy. It just needs to be reliable.

Under 500 Users

  • Two Raspberry Pi systems running Pi-hole
  • Or two used small-form-factor PCs from eBay
  • Example: HP EliteDesk 800 (i5, 8GB RAM, 256GB SSD) for under $100
  • Intel NUCs work great too
  • Anything is better than nothing. Just make it redundant.

Enterprise Deployment

What we commonly deploy:

  • Dell R640 servers
  • Redundant power supplies
  • Redundant storage
  • RAID-protected OS and data
  • Built for real uptime

With six 800GB SAS drives, you’re looking at roughly $3,200 per server, but these platforms:

  • Last for years
  • Survive hardware failures
  • Allow zero-downtime maintenance

They are absolutely overpowered for just DNS, which is why we typically run Proxmox or Hyper-V and host additional services as well.

The Core Software Stack: Pi-hole + Unbound

What matters most is how you run DNS, not just the hardware.

Pi-hole

  • Acts as the front-end caching DNS server
  • Default cache: 10,000 entries
  • We tune ours to 250,000 cached entries
  • Network-wide telemetry, ad, malware, and phishing blocking
  • Full visibility into DNS behavior

Unbound

  • High-performance recursive DNS resolver
  • Talks directly to root servers
  • Eliminates reliance on Google, Cloudflare, or upstream forwarders
  • Provides secure, authoritative recursion

How We Use Them Together

  • Clients → Pi-hole
  • Pi-hole → Unbound
  • Unbound → Root DNS Servers

This gives you:

  • Full recursion
  • Full caching
  • Full visibility
  • Full control
  • No dependency on public DNS vendors

Security Without Becoming “The ISP That Blocks Everything”

As an ISP, you typically don’t want aggressive filtering. But malware and phishing domains should never be accessible.

We implement:

  • 1–2 strictly malware and command-and-control focused blocklists
  • About 500,000 malicious DNS entries
  • No ad blocking by default
  • No content filtering

This protects customers from:

  • Botnet command servers
  • Phishing landing pages
  • Malware distribution domains

Even if a device becomes compromised, blocking DNS-based command and control often prevents the malware from functioning at all.

Real Performance Gains

On production networks, we consistently see:

  • 90–91% cache hit rate
  • Only 9–10% of queries ever leave the server
  • DNS answers delivered locally at wire speed

On a 32-core 3.2GHz Xeon DNS VM, usage is typically:

  • Under 3% CPU
  • 8–12GB RAM is more than enough

DNS is lightweight. Performance is not the challenge. Architecture is.

Alternative: Windows-Based Recursive DNS

For Windows-based environments:

  • SimpleDNS
  • Can function as authoritative DNS and recursive DNS
  • Free for recursion
  • Licensing applies only to authoritative domains

It’s a solid option for Windows-heavy infrastructures.

Placement Matters: Keep DNS at the Network Edge

DNS should live:

  • Inside your network
  • Close to customers
  • On low-latency infrastructure

It should not live in AWS, Azure, or third-party cloud platforms unless you are specifically engineering global anycast DNS. Lower latency equals faster lookups and faster perceived internet speed.

The Business Reality

Here’s the real question every ISP must answer:

If your customers’ DNS is broken, can you directly fix it?

If you rely on:

  • Google DNS
  • Cloudflare DNS
  • Other third-party resolvers

Then the answer is no.

And if you have:

  • No control
  • No monitoring
  • No logs
  • No escalation path

Then you are outsourcing one of the most critical components of your network, for free, to companies that owe you nothing.

That’s not engineering. That’s gambling.

Final Thought

DNS is not an optional service. It is not an add-on. It is not a nice-to-have.

DNS is a core requirement of the internet.

If you are an Internet Service Provider:

  • You should control your recursive DNS
  • You should own your cache
  • You should protect your customers from malware
  • You should have visibility during outages
  • You should not bet your reputation on a free public service

Run your own DNS.
Your customers, your engineers, and your uptime will thank you.

Leave your comment

*