What Is Internal DNS and When You Need It

Internal DNS is a DNS server that resolves resource names inside a closed network — corporate, local, or cloud. It lets you reach servers and services by friendly names instead of IP addresses. Internal names don't have to be published on the internet. Instead of connecting to a server at 10.0.0.15, employees can use files.corp or git.internal. For a small network this might just be a convenience, but for a larger infrastructure it becomes a necessary part of the architecture.

How internal DNS differs from public DNS

Public DNS serves domain names that are reachable from the internet. When a user types a website address, their DNS resolver fetches information about the corresponding public records. Internal DNS operates within a specific network. Its zone and records are meant for internal clients only, and the server itself shouldn't be reachable for arbitrary queries from the internet.

With internal DNS, records describe servers, databases, internal panels, file storage, printers, and other resources that don't need a public domain name at all. But that doesn't mean internal names are automatically protected from discovery. Security depends on how the DNS server is configured, network access, ACLs, firewalls, and other mechanisms. Simply using internal DNS is not a complete network defense on its own.

What is split-horizon DNS

Another common scenario is split-horizon DNS, also called split DNS. With it, the same domain can resolve differently depending on where the DNS query originated.

Inside the network: app.example.com - 10.0.0.20

From the internet: app.example.com - 203.0.113.20

An employee inside the network reaches the internal server directly, while an external user gets the public address. This lets you use a single domain name for both internal and external access without exposing the internal IP address in the public DNS zone.

How an internal DNS server works

In its simplest form, internal DNS is just a regular DNS server with its own zone for internal names.

A local network might include:

• router.home

• nas.home

• server.home

• git.corp

• monitoring.corp

The DNS server stores the corresponding records and answers queries from devices allowed to use it. For example, a computer requests git.corp. Internal DNS finds this record in its local zone: git.corp - 10.0.0.15, and returns the IP address. If a user requests an external site like example.com, the internal server can forward the query to a public DNS resolver. This scheme is called DNS forwarding.

As a result, a single internal DNS server becomes the first point of contact for clients on the network:

1. The client sends a DNS query to the internal server.

2. Internal DNS checks its own zones.

3. If the record belongs to an internal resource, it answers directly.

4. If the name is external and forwarding is configured, the server passes the query to another DNS resolver.

5. The resulting answer is returned to the client.

This is convenient: computers and servers don't have to decide on their own where to send different types of DNS queries.

When you actually need internal DNS

Corporate network with Active Directory

For an Active Directory infrastructure, internal DNS isn't just a nice-to-have. A Windows domain relies heavily on DNS to locate domain controllers and other services. That's why, in a corporate Windows infrastructure, DNS is usually a core part of the Active Directory architecture itself. Internal machines need to be able to find domain controllers and required services through DNS names.

This is exactly where the idea of "just hardcode the IP addresses everywhere" quickly falls apart: the infrastructure grows too large, and addresses can change.

Microservices, Docker, and Kubernetes

In a microservices infrastructure, dozens or hundreds of components are constantly talking to each other. Picture an application made of several services: frontend - api - database - redis

If every service addresses another by IP, changing that address means updating the configuration of every dependent component.

It's far more convenient to use names instead: api - database - redis

Docker provides its own DNS mechanisms for container and service discovery, and Kubernetes has built-in DNS-based service discovery. So here, internal DNS can be part of a broader service discovery system rather than necessarily a dedicated BIND9 server. The core idea stays the same: a service cares more about a stable dependency name than about its current IP address.

Home lab and self-hosted infrastructure

Internal DNS is especially handy in a home lab with several servers, virtual machines, and network devices.

For example:

• nas.home;

• pve.home;

• grafana.home;

• git.home;

• docker.home.

Instead of memorizing several IP addresses, the user reaches services by name. This is also useful for self-hosted projects. You can set up your own DNS server using, for example, BIND9, dnsmasq, or Pi-hole. In a cloud infrastructure, you can achieve the same with a VPS and a private network between instances, provided the platform supports this kind of networking feature.

For instance, internal DNS can live on one VPS, while several applications run on other servers within the same private network. In this setup, internal names let you connect infrastructure components without exposing them to the public internet.

Isolating internal services from public DNS

Sometimes a service needs to be reachable by employees or other infrastructure components, but doesn't need to be exposed externally.

For example:

• grafana.corp

• git.corp

• database.corp

• registry.corp

If these names are served only by internal DNS, there's no need to add them to the public DNS zone. This reduces the amount of information exposed externally, but it doesn't replace a firewall, authentication, or access control. If an internal service is reachable from an untrusted network, internal DNS alone isn't enough to protect it.

When you don't need internal DNS

You shouldn't set up internal DNS just because it's considered "proper" server practice. If you have one VPS, one site, and one domain, regular public DNS is enough. You can point the domain to the server with an A record, and a separate internal DNS server in that setup would add an extra component rather than real value.

The same applies to a simple home network with a handful of devices, if the DNS provided by the router or ISP already works fine for them. A simple rule of thumb: if you have few internal resources and they don't require centralized name resolution, internal DNS can be overkill.

Which software is most commonly used for internal DNS?

Depending on the infrastructure, options include BIND9, dnsmasq, Windows DNS Server, Pi-hole, and Unbound. They differ in purpose and capabilities, so the choice depends on the specific network; understanding internal DNS itself doesn't require knowing the differences between them.

Is internal DNS secure by itself?

No. Internal DNS limits the scope of DNS record exposure, but it doesn't protect the network automatically. Security requires additional mechanisms: network segmentation, firewalls, ACLs, authentication, and access control.

Conclusion

Internal DNS becomes useful once a network develops its own infrastructure that needs to be tied together with human-readable names. Multiple servers, internal services, Active Directory, containers, virtual machines, and self-hosted applications are all typical situations where DNS names are more convenient and resilient than constantly working with IP addresses.

But there's no need to complicate infrastructure unnecessarily. A single website or a single home server doesn't need a dedicated internal DNS. As the number of internal resources grows, though, your own DNS zone turns from a nice convenience into an important architectural component.

For self-hosted infrastructure, internal DNS can be moved to a separate VPS and linked to other servers through a private network. This approach is especially appealing when internal services need to talk to each other but shouldn't be exposed to the internet.