markdown formatted blog content

DNS Is for People, Not Machines: Why Internal Infrastructure Should Skip the Name Resolution Step

Let's be honest: DNS is brilliant for humans. Remembering that 104.21.1.5 points to a Cloudflare-hosted site is a cognitive burden nobody needs. But here's the thing — machines don't care about readability. A server talking to another server doesn't need a hostname to feel comfortable. It just needs an IP address.

Yet somewhere along the way, we started treating DNS as the default answer for everything — including internal service discovery, inter-service communication, and infrastructure configuration. And that default has quietly become a significant operational liability.

The Haiku Says It All

If you've spent any time in IT operations, you've heard it:

It's not DNS. There's no way it's DNS. It was DNS.

This isn't just a joke. It's a confession. DNS failures have knocked out entire platforms, locked employees out of physical buildings, and caused cascading outages that took hours to untangle. The Facebook/Meta outage of 2021 is the canonical example — a misconfigured BGP update took down DNS infrastructure, and the ripple effects went so far that badge readers stopped working.

Here's what's interesting: in most of these cases, DNS wasn't the root cause. The root cause was something else entirely — a bad configuration, a hardware failure, a routing error. But because DNS sits in the critical path for nearly every service, the blast radius is enormous. When DNS goes down, everything that depends on name resolution goes down with it.

That's a terrifying amount of power to hand a single service.

DNS Adds Unnecessary Components

Reliable systems are built on simplicity. Every additional component is a potential failure point, and failure points can interact in ways you didn't anticipate. DNS adds a service. That service needs to be running, monitored, replicated, and kept in sync across your infrastructure. You need to manage TTLs, handle cache behavior, and troubleshoot why Server B isn't seeing the same record as Server A despite them being on the same network.

For human-facing services, this complexity is justified. Your users need a memorable domain name. Your marketing team needs coolstartup.io instead of 10.203.44.17. But for internal infrastructure? Your servers don't care about brand identity.

Here's a better approach: inject the IP addresses directly into your configuration files. Tools like Ansible, Terraform, and PyInfra make this trivially easy at scale. You write your config once, the IP gets baked in, and nothing resolves at runtime because nothing needs to resolve.

The /etc/Hosts Renaissance

"But wait," someone will say. "Configuration files with hardcoded IP addresses are hard to read. How will I troubleshoot?"

Enter /etc/hosts. This ancient, wonderfully simple file lets you define hostname-to-IP mappings on any Unix-like system. No DNS server required. No caching behavior to debug. No TTL to fight. The lookups are instantaneous, and you still get human-readable hostnames in your configuration.

You get all the readability benefits of DNS without any of the operational overhead. Your configuration says db-primary instead of 10.203.44.17, and your servers resolve that name instantly through a locally managed file. It's not elegant by modern standards, but it's reliable, predictable, and eliminates an entire failure domain from your architecture.

DNS as a Security Risk You Probably Haven't Considered

Here's where things get uncomfortable. Most network traffic today is encrypted by default. TLS, SSH, WireGuard — encryption is the norm, not the exception. DNS is the outlier.

By default, your DNS queries are sent in plaintext. For internal infrastructure, this is especially problematic. Many organizations assume their internal network is a trusted environment, so they skip egress filtering. A compromised service can query arbitrary external DNS servers, downloading attack tools or exfiltrating data without anyone noticing.

And yes — DNS can be used as a data exfiltration channel. An attacker who compromises a server can encode sensitive data into DNS queries to an attacker-controlled domain. Each query carries a small payload, and the authoritative nameserver logs everything. It's slow, but it's nearly impossible to detect if you're not actively inspecting DNS traffic.

DNSSEC exists to address the integrity problem, but it introduces its own complexity. Misconfigured DNSSEC can cause outages just as easily as a failed DNS server. And if your internal infrastructure doesn't even support DNSSEC (many don't), you're left with a security gap that most teams haven't thought about.

So What Should You Actually Do?

This isn't a call to eliminate DNS entirely. DNS is indispensable for services that humans interact with — websites, APIs that external parties call, anything with a brand or product attached to it. NameOcean's own DNS hosting exists because these use cases are exactly why DNS was invented.

But for internal infrastructure? Consider the following:

• Skip DNS for machine-to-machine communication. Hardcode IPs or use /etc/hosts. It's more predictable.
• Treat DNS as a service, not a utility. Monitor it, have redundancy, and understand your blast radius if it goes down.
• Audit your egress rules. Even on internal networks. Especially on internal networks.
• Ask yourself what the failure mode looks like. If DNS is the only path between Service A and Service B, what happens when DNS is unavailable? Can your systems tolerate that?

The principle is simple: use DNS where it earns its complexity. For everything else, keep it simple.