DNS Is the First Gate: Why “Safer DNS” Misses the Point

By Cliff Potts, CSO, and Editor-in-Chief of WPS News

Baybay City, Leyte, Philippines — April 14, 2026

Start Simple: What DNS Is Supposed to Do

When a user types a web address, the Domain Name System (DNS) translates that name into a numerical address so the connection can happen. That is its intended role: translation, not judgment (Mockapetris, 1987).

DNS was designed to function as a neutral directory. It does not decide what content is acceptable. It does not evaluate intent. It simply answers the question: “Where is this located?” (Mockapetris, 1987; Cloudflare, n.d.).

That neutrality matters, because DNS happens before anything else. If DNS does not resolve a name, the connection never begins.

Where the Shift Happens

In practice, DNS no longer always behaves as a neutral directory.

Modern DNS services can:

• Block domains
• Redirect users
• Filter categories of content
• Apply policy decisions at the resolution stage (Cisco, n.d.)

At that point, DNS is no longer just translating. It is deciding.

The system shifts from:

• “Here is where it is”

to:

• “Here is what you are allowed to reach”

This is not a technical error. It is a structural change.

The First Gate Problem

Because DNS happens before the connection, control at this layer becomes upstream of everything else.

If a domain does not resolve:

• The site is effectively invisible
• The user never reaches it
• No further safeguards or freedoms apply

That makes DNS the first gate in the system.

Not the loudest gate. Not the most visible.

But the earliest one.

And early control is the most efficient form of control.

The “Safer DNS” Argument

A common response to concerns about DNS is to recommend services such as Cisco/OpenDNS.

These services provide:

• Malware blocking
• Content filtering
• Parental controls
• Network-wide enforcement (Cisco, n.d.)

All of that is accurate.

All of that is useful in specific contexts.

And none of it addresses the issue being raised here.

What Cisco/OpenDNS Actually Does

Cisco/OpenDNS is a centralized DNS resolver that applies policy decisions at the resolution layer (Cisco, n.d.).

It decides:

• Which domains resolve
• Which domains do not
• How categories of content are handled

This is valuable for:

• Families managing access for children
• Schools enforcing acceptable use
• Enterprises reducing risk exposure

But it operates by introducing control at the DNS layer.

Where It Misses the Point

The issue is not whether DNS can be made safer.

The issue is that DNS has become a point where control can be applied at scale.

Recommending a centralized DNS provider does not solve that problem.

It changes who exercises that control.

(See also: DeNardis, 2014)

This is the core misunderstanding.

The discussion is not about choosing a better tool.

It is about recognizing what the tool has become.

Centralization and Chokepoints

When large numbers of users rely on a small number of DNS providers, resolution becomes concentrated.

That concentration creates a chokepoint.

Not necessarily through overt censorship.

But through the ability to:

• Shape access
• Apply policy quietly
• Influence visibility upstream (DeNardis, 2014; Mueller, 2017)

The risk is not hypothetical.

DNS has already been used globally for:

• Domain blocking
• Traffic redirection
• Policy enforcement at the network level (DeNardis, 2014)

The Structural Difference

There are two different approaches to this problem.

One approach says:

• Choose a trusted authority to filter DNS
• Improve safety through centralized control

The other approach says:

• Reduce the amount of control any single authority has
• Preserve DNS as neutral infrastructure

These approaches are not compatible.

They solve different problems.

Why This Matters

If DNS remains a layer where a small number of actors can decide how names resolve—or whether they resolve at all—then it remains a structural gate.

It does not need to block loudly.

It does not need to announce itself.

It only needs to sit upstream, quietly determining what resolves and what does not.

That is enough.

The Bottom Line

This discussion is not about whether a DNS service is useful.

Many are.

This discussion is about what DNS becomes when control is concentrated at that layer.

You do not solve that problem by selecting a different controller.

You solve it by recognizing that the layer itself has become a point of control.

And deciding whether that is acceptable.

For more social commentary, please see Occupy 2.5 at https://Occupy25.com

If you read this and it matters, help me keep it going: https://www.patreon.com/cw/WPSNews

References

Cisco. (n.d.). OpenDNS home internet security. https://www.opendns.com/home-internet-security/

Cloudflare. (n.d.). What is DNS?. https://www.cloudflare.com/learning/dns/what-is-dns/

DeNardis, L. (2014). The global war for internet governance. Yale University Press.

Mockapetris, P. (1987). Domain names – Concepts and facilities (RFC 1034). Internet Engineering Task Force. https://doi.org/10.17487/RFC1034

Mueller, M. (2017). Will the internet fragment? Sovereignty, globalization and cyberspace. Polity Press.

The Rise of Modern, Open and Intelligent Fibre Networking Architectures

Speaker: Jean-Francois Richard

TORNOG 1 Full Agenda: https://tornog.ca/events/tornog-1/agenda/

#NetworkAutomation #Toronto #NetworkArchitecture #technology

There was a massive Verizon outage on January 14. Reuters reported that it lasted 10 hours. Downdetector said it received 2.2 million reports of problems with Verizon’s service, but other estimates are as low as 180,000. As of this writing, Verizon hasn’t announced a reason for the outage. Cybersecurity concerns are possible, but have been mostly ruled out. It appears to have been an internal “technical issue.”

I can’t tell you what the specific technical issue was, but I can tell you what the general issue was: massive centralization.

Companies design systems with massive geographic centralization for cost and convenience, not for resilience – or, for that matter – cybersecurity.

Information and communications industries as a whole have been moving steadily towards massive centralization for several years now. Decentralize command and control. Centralization is a military-grade problem. There will be bigger and more impactful outages across all industries while we re-learn this lesson.

#CallMeIfYouNeedMe #FIFONetworks

#cybersecurity #NetworkArchitecture #SystemDesign

Winter weather – power failures – what’s a good design?

In theory – in a perfect world – the backup batteries only need to last long enough for the generator(s) to start up and stabilize with the load of your choice. But, in the real world, the backup batteries should hold the system up in the following scenario:

1. Power goes out.
2. Batteries/UPS take the load.
3. Power failure alarm is issued to the technician on call.
4. Generator fails to start.
5. Generator failure alarm is issued to the technician on call.
6. The tech on call requests service from the generator maintenance contract company.
7. The generator company rolls a truck.
8. The generator service person identifies the problem, repairs it, and starts the generator.

If continuous operation through a power failure is the goal, I design battery/UPS systems for a minimum six hours of run time, and if the generator company has to roll a truck that’s really not enough. Six hours is only enough if you have in-house technicians on call who live close to the monitored system.

If it’s impractical to support a system with the appropriate amount of battery capacity for a generator repair, then the solution is a second generator. If, and only if, the system is protected with a second generator, is it feasible to reduce the battery capacity. Keep in mind that battery capacity decreases over the life of the battery, or with temperature variations, etc. Also, equipment gets added over time, so if the system is built with marginal capacity (generator startup and RPM stabilization), then when you have an outage six months or a year after initial installation, the batteries may no longer be adequate.

Design with lots of margin, not just to load transfer time.

#CallMeIfYouNeedMe #FIFONetworks

#resilience #NetworkArchitecture #infrastructure

A few months ago I discovered a law firm’s financial information (specifically billing and payment information), online. It’s a nationally known law firm, and the records in question were for the Seattle office.

Broken down by customer.
Itemized hourly billing.
Hourly billing rate.
Other expenses.
Customer account number.
Customer payment information, including bank account number.
Law firm’s bank account number.
Amounts paid.
Payment dates.
Balance due.
The information did NOT include details of the services provided.

I found it entirely by accident, with a Google search that wasn’t targeted in nature.

No, I didn’t report it to the law firm. In Washington, “Good faith acquisition of personal information . . . is not a breach of the security of the system when the personal information is not used or subject to further unauthorized disclosure.” (RCW 19.255.005(1))
I believe that protects me, but I don’t want to test it in court, and if the law firm knew about it, they might feel compelled to take some sort of action other than securing their information better.

THE LESSON
Do not store your company records, and host your website, on the same server. I can’t believe I have to write that sentence.

#CallMeIfYouNeedMe #FIFONetworks

#cybersecurity #NetworkArchitecture #SystemsDesign #policy

Concerned about AI-generated malware bringing down your company? Then get your critical data off the Internet.

This isn't rocket science. This is Occam’s Razor.

The Internet is for social media and retail sales.

PII, PHI, employee records, customer information - nothing important should ever be Internet accessible.

Ever heard of private data circuits? Private data circuits are a real thing. People quit using them because the Internet was cheaper.

"It'll be secure," they said.

No. The Internet has never been secure. The Internet cannot ever be secure, because authenticated users will always be tricked into doing stuff for cybercriminals.

If there was ever a time to rethink your business strategy as it relates to information storage and processing, that time is now.

It's going to get worse quickly. Your best defense is to get sensitive data out of the public cloud.

#CallMeIfYouNeedMe #FIFONetworks

#cybersecurity #NetworkArchitecture #SystemsDesign #policy

“Basically it's a 1995 AOL chat room and you have, like, a wheel-speed sensor that's shouting AGE/SEX/LOCATION over and over in group chat.

Now you can understand how your corroded backup camera will strand you.” #car #networkarchitecture https://zeroes.ca/@subjacentish/115432294616786461

A lot of the work I do is in high security systems where sensitive data isn’t connected to the Internet, and isn’t hosted on commercial public cloud platforms, because such an architecture can’t meet the design criteria.

A recurring issue I face is educating new decision makers who get ill-informed notions that they can reduce costs (thereby becoming heroes, or so they think), by centralizing information storage or processing on rented commercial platforms. So I go through it all again, patiently, politely, with the new person.

The other recurring threat I deal with is C-level people who want what I refer to as Data Ubiquity: “I want access to all of the data, at any time, from any location, on any of my devices.”

Data Ubiquity = Maximum Vulnerability.

Even “perfect” authentication won’t prevent this vulnerability. Why? Phishing. The authenticated user will be tricked into opening the door for the cybercriminal.

When the data is in no way Internet connected, how does the victim deliver the data to the cybercriminal? Do they print it out and ship reams of paper in boxes to the criminal via FedEx?

Offline Data = More Secure Data.

The cloud is for retail sales and social media, NOT for PHI, PII, corporate secrets, intellectual property, employee records, industrial controls...

#CallMeIfYouNeedMe #FIFONetworks

#cybersecurity #NetworkArchitecture #policy #privacy