NAT and Private IP Address Ranges

The private and special-purpose ranges

IANA keeps the full list in its IPv4 Special-Purpose Address Registry. These are the ranges you are most likely to meet in DNS and network work:

Watch the 172.16.0.0/12 boundary. It covers 172.16.x.x through 172.31.x.x, not every address that starts with 172. An address like 172.32.0.1 is public. If CIDR prefixes are unfamiliar, start with IP Addresses, Subnets and CIDR.

How NAT works

The most common form is network address and port translation (NAPT), described with other variants in RFC 3022. Because many internal hosts share one public address, the router also rewrites the source port so it can tell their connections apart. It keeps a translation table of each mapping:

This has some consequences worth knowing:

• Inbound connections need explicit rules. An unsolicited packet arriving at the public address has no table entry, so the router drops it unless a port forward or static mapping sends it to an internal host.
• Mappings expire. UDP mappings in particular time out after a period of silence. That rarely affects DNS, which is a single request and reply, but it matters for long-lived UDP sessions.
• NAT is not a firewall, although the "drop unknown inbound traffic" behavior looks like one. Policy should still be written as firewall rules.
• Port randomization can suffer. Resolvers randomize their UDP source port to resist forged answers. A NAT that rewrites ports in a predictable sequence removes some of that protection, so resolvers are best placed where their source ports reach the Internet unchanged.

Carrier-grade NAT and RFC 6598

With IPv4 addresses scarce, many providers no longer give each customer a public address. They run carrier-grade NAT (CGNAT) inside their own network, so the customer's router gets an address from 100.64.0.0/10 and the provider translates again before traffic reaches the Internet. RFC 6598 reserved that block so it would not clash with the RFC 1918 ranges customers already use at home.

Address on the home router's WAN interface:

$ ip -4 addr show dev wan0 | grep inet
    inet 100.72.18.41/22 brd 100.72.19.255 scope global wan0

100.64.0.0/10 runs from 100.64.0.0 to 100.127.255.255, so this router is behind the provider's CGNAT.

CGNAT is why some customers cannot host services at home: there is no public address to forward ports on. It also means one public address can represent many unrelated subscribers at the same moment. Abuse reports and server logs that record only an IP address cannot identify a single user behind CGNAT, which is why RFC 6302 recommends that Internet-facing servers log the source port and an accurate timestamp as well.

Private addresses in public DNS

A common leak is an internal name, such as intranet.example.com, published in the public zone with its private address:

$ dig @ns1.example.com intranet.example.com A +noall +answer
intranet.example.com.  3600  IN  A  10.20.30.40

This causes three kinds of trouble. External users who look up the name get an address they cannot reach, or one that happens to exist on their own network, so traffic goes somewhere unintended. The record tells anyone who asks which internal hosts exist and how the network is numbered. And security-conscious resolvers may strip the answer: several resolvers offer DNS rebinding protection that removes private addresses from answers for public names, so behavior varies from network to network. Some organisations publish private addresses on purpose, for example so VPN users resolve internal hosts without split DNS. That is a valid choice if it is deliberate and the exposure of internal names is acceptable.

The usual fix is split-horizon DNS: internal clients query an internal view that includes the private records, and the public zone contains only what outsiders need. Split-Brain DNS / Split Horizon covers how to set that up and how the two views drift apart. Reverse lookups need the same care. Queries for private reverse zones such as 10.in-addr.arpa should be answered locally, as RFC 6303 recommends, rather than leaking to the public Internet; see Reverse DNS and PTR Records.

The opposite problem: hairpin NAT

The reverse situation also trips people up. An internal client looks up www.example.com, gets the public address 203.0.113.7, and sends its request to that address. The traffic reaches the NAT router from the inside, aimed at the router's own public address. Unless the router supports hairpinning (sometimes called NAT loopback or NAT reflection) and is configured for it, the connection fails even though the same site works perfectly from outside.

There are two common fixes. One is to enable hairpinning on the router, so it translates the request back to the internal server. The other is to give internal clients an internal DNS answer that points straight at the server's private address, which is split-horizon DNS again. The DNS approach avoids sending internal traffic through the router at all, but it means maintaining two views of the same name and keeping them in step. Whichever you choose, document it: "works outside, fails inside" is a symptom that often gets blamed on DNS caching when it is really address translation.

How DNS Panopticon helps

Zone Analyzer is the most direct way to find private addresses in a zone you manage. Load an export, then add custom filter rules on the record data, for example data that starts with 10., 192.168. or 172.16.. The built-in sample zone includes a Private IPs shortcut that applies exactly those three rules. Because a single 172.16. rule only matches part of the /12, add rules for 172.17. through 172.31. as well, plus 100. if you want to catch CGNAT space and then review those rows by eye.

When you select A or AAAA rows for Visual Verification, Zone Analyzer marks any record that points to an RFC 1918 private address, a loopback address, or an IPv6 unique local or link-local address as an internal server that is not reachable externally, instead of attempting a screenshot. Export the filtered rows as CSV to hand the list to whoever owns the internal view.