Split-Horizon DNS: Can You Point a Public DNS Record at a Private IP?

Can you point a public DNS record at a private IP?

Yes. A public A record can hold any IPv4 address, including 10.0.0.5 or 192.168.1.50. No registrar blocks it and no RFC forbids it. The problem is not creating the record. The problem is that some resolvers refuse to hand the answer back.

The scenario shows up constantly in home labs. You own a domain. You run a NAS, a Home Assistant box, or a Proxmox host on your LAN. You want nas.example.com to work on your phone without typing an IP address.

The obvious move is to add an A record at your registrar pointing straight at the private address. It costs nothing and takes a minute. And for a lot of people it works fine on the first try.

Then a family member’s laptop cannot reach it. Or the name works on Wi-Fi but fails on the guest network. That inconsistency is the signature of this approach, and it has a specific cause.

What split-horizon DNS actually is

Split-horizon DNS serves different answers for the same hostname depending on who is asking. Queries from inside your network get the private address. Queries from the public internet get a public address or nothing at all. Two views of one name, chosen by the resolver that answers.

The term appears in vendor documentation as split-brain DNS or split-view DNS. All three mean the same design. Nobody has settled on one label, so expect to see each of them.

Mechanically it is simpler than it sounds. You are not running one clever server that inspects source addresses. In most home setups you are running two separate resolvers that happen to disagree.

Your public authoritative zone lives at your registrar or DNS host. It answers the world. Your local resolver sits on your LAN and answers your devices. When a device asks for nas.example.com, the local resolver replies first with the private address. The public zone never gets consulted.

Why private IPs in public DNS break for some users

DNS rebinding protection is the reason. It rejects answers from public DNS zones that contain private addresses. The feature exists to stop a browser attack, and several popular routers and resolvers turn it on by default. When it fires, your hostname simply fails to resolve.

What DNS rebinding protection is defending against

A rebinding attack works by abusing the browser’s same-origin policy. A malicious site resolves its own domain to a public IP, then re-resolves it to an address like 192.168.1.1.

The browser still treats both as the same origin. The attacker’s JavaScript can now talk to devices on your LAN and read the responses. Google describes this as letting a site deduce the structure of your local network.

The defence is blunt but effective. If a public domain returns a private address, drop it. That rule has no way to tell your NAS record apart from an attack.

Which resolvers and routers strip private answers

This is the part that catches people out. The big public resolvers are usually not the culprit. The breakage comes from the last hop, meaning your own router or a corporate resolver.

Two details are worth pulling out of that table. Unbound ships with no private ranges configured, but the Unbound documentation notes that enabling RFC 1918 by default is under consideration.

Meanwhile pfSense turns the check on out of the box. Its rebinding protection covers the RFC 1918 blocks plus loopback, link-local, and IPv6 unique local addresses.

Why you cannot fix this at the record level

Here is the trap in the guest-network version of this idea. You can hand clients a specific resolver over DHCP, such as 1.1.1.1 or 8.8.8.8.

You cannot make them use it. Modern browsers and operating systems ship DNS over HTTPS, and many devices carry a hardcoded resolver. Our guide on why DNS over HTTPS breaks Pi-hole covers the same bypass problem from the filtering side.

So the record either resolves or it does not, and you have no control over which. Tailscale documents this exact failure mode for internal dashboards reached over a tunnel.

Is publishing internal IPs in public DNS a real security risk?

Mildly. The addresses themselves reveal almost nothing, because RFC 1918 ranges are identical everywhere and trivially guessable. The hostnames are the real exposure, since they advertise which services you run. Those names also become public through Certificate Transparency logs anyway.

What the objection gets right

Names carry information that addresses do not. A record for backup-vcenter.example.com tells an attacker what you run and what it is for.

Published records are also enumerable. Passive DNS collectors index them, and subdomain discovery tools query wordlists against your zone. That turns a scattered guess into a map.

An internal address plan has some value too. Knowing you use 10.20.30.0/24 for management narrows a lateral-movement search. Our guide to public vs. private IP addresses explains why those ranges stay unreachable from outside regardless.

What the objection gets wrong

Treating 192.168.1.50 as sensitive is security through obscurity. Every home network on earth uses one of three ranges. An attacker inside your network can read the addresses directly.

The stronger point is that hiding the record does not hide the name. Every publicly trusted certificate is logged to Certificate Transparency logs, which are public and append-only.

Request a certificate for backup-vcenter.example.com and the name is published whether or not a DNS record exists. You can confirm this yourself with our SSL Certificate Checker, which reads those logs directly.

Four ways to make an internal hostname resolve

Four approaches cover nearly every case. You can publish the private IP publicly or run split-horizon DNS. You can also use NAT loopback, or reach the host over an overlay network. Each trades setup effort against reliability, and only one of them fails silently.

NAT loopback deserves a note. It lets a device on your LAN reach your own public IP and get looped back inside. A port forward must exist first. Our guide on port forwarding and how NAT routes traffic covers the forwarding side. Our explainer on what NAT is covers the translation itself.

Overlay networks sidestep DNS politics entirely. Tailscale assigns its own addresses and its own naming, so rebinding protection never enters the picture. Our walkthrough on reaching your home network with Tailscale covers subnet routers and route approval.

Setting up split-horizon DNS on common gear

Most home-lab resolvers support this as a single local record. You add a hostname and a private address to your local DNS. That entry wins over the public zone for any device using it. The exact menu differs by platform, but the concept never changes.

Pi-hole

Open Settings, then Local DNS, then DNS Records. Add the hostname and its private IP as a pair. Pi-hole runs dnsmasq underneath, so these entries answer authoritatively before anything is forwarded upstream.

AdGuard Home

Go to Filters, then DNS rewrites. Add a rewrite mapping the hostname to the private address. Wildcards are supported, so *.lab.example.com can point at one host.

pfSense and OPNsense

Use Services, then DNS Resolver, then Host Overrides. Add the hostname, the parent domain, and the IP address. Rebinding protection is on by default here. Add a private-domain line in Custom Options if you also keep the public record.

OpenWrt and dnsmasq

Add an address=/nas.example.com/192.168.1.50 line to your dnsmasq configuration. The dnsmasq documentation also describes --rebind-domain-ok for exempting a domain from rebinding checks.

The step most people miss

A local record only works for devices that actually query your resolver. Hand out the resolver address over DHCP, and block or redirect outbound port 53 if you want to be thorough.

Devices using DNS over HTTPS still escape. That is a browser setting, not a network one, and it needs handling per device.

Which domain name should you use internally?

Use a subdomain of a domain you own when you need valid TLS certificates. Use .internal when you do not, since ICANN permanently reserved it for private use in 2024. Avoid .local, which belongs to multicast DNS and causes real conflicts.

The .internal reservation is recent enough that many guides predate it. ICANN’s board resolved in July 2024 to reserve it from delegation permanently. That closes a long-standing gap where admins invented names like .corp or .lan and risked collisions.

There is a catch. No public certificate authority will issue a certificate for a name under .internal. Nobody can prove ownership of it. Browsers will warn on every visit unless you run your own internal CA.

home.arpa is the standardised option for residential networks, defined in RFC 8375. It carries the same certificate limitation.

Getting a valid TLS certificate for an internal-only host

Use the DNS-01 challenge. It proves you control the domain by placing a TXT record under it. The server never needs to be reachable from the internet. This is why many people put internal hostnames in public DNS. It works without publishing any private address.

Let’s Encrypt describes DNS-01 as writing a token to _acme-challenge under your domain. The challenge types documentation notes it works where HTTP-01 cannot. It is also the only method that issues wildcard certificates.

A wildcard suits a lab well. One certificate for *.lab.example.com covers every service you add later, with no new DNS work each time.

Automation matters more than it used to. Certificate lifetimes are shrinking fast. Our guide on how SSL certificates work covers the current 200-day ceiling and the reductions already scheduled.

How to test what DNS is actually returning

Query the name from two places and compare. Ask your local resolver, then ask a public resolver directly. If the public answer is empty while the local one works, you found the cause. Rebinding protection or a missing public record explains it.

On Windows, run nslookup nas.example.com 8.8.8.8 to bypass your local resolver. On macOS or Linux, dig @8.8.8.8 nas.example.com does the same.

Then repeat without specifying a server. That uses whatever resolver the device is configured for, which is the answer your applications actually receive.

Our DNS Lookup tool queries A, AAAA, CNAME, and other records over DNS over HTTPS. That gives you a third-party view which ignores your local setup. Comparing that against your device output isolates the problem quickly.

One more check is worth running. If you changed a public record recently, confirm it has actually spread. The DNS Propagation Checker shows what public resolvers currently return.

Related Tools & Resources

NetworkCheckr has several tools that help with split-horizon DNS work. The DNS Lookup tool shows what public resolvers return for any name. The SSL Certificate Checker reads Certificate Transparency logs to reveal which hostnames are already public.

• DNS Lookup — query A, AAAA, CNAME, MX, and TXT records for any domain.
• DNS Propagation Checker — compare what Google and Cloudflare currently return.
• SSL Certificate Checker — see every certificate issued for a domain, and every hostname on it.
• Subnet Calculator — confirm an address falls inside the range you expect.
• How DNS Works — the full resolution chain, from stub resolver to authoritative answer.
• DNS Records Explained — what A, AAAA, CNAME, and the rest actually do.
• Networking Glossary — plain-language definitions for over 200 networking terms.

Frequently Asked Questions