🌐 IP address spaces: public, private, documentation

Three categories of IP address show up in DNS conversations: public (routable on the Internet, identifies you), private (RFC 1918 / ULA, routable only inside your network), and documentation (RFC 5737 / 3849, reserved so authors can write examples that don't accidentally point at someone's real network). Knowing which is which keeps you from leaking infrastructure or breaking examples.

TL;DR#

Public addresses#

Real, routable, identifying. These are the addresses your ISP hands you (IPv4 WAN, IPv6 delegated prefix), the addresses cloud providers assign to your VMs, the addresses you'd put in DNS for a service you want the world to reach.

Two important properties:

1. They identify you. An IPv6 prefix is unique to your subscriber line; the first 24–32 bits identify the carrier (publicly looked up in WHOIS), the next chunk narrows it to a region or subscriber pool. An IPv4 WAN is less precise but trivially geo-located.

1. They appear in DNS PTR records. Reverse DNS for public IPs is delegated by the RIR/ISP; you usually can't set your own PTR unless you have a static allocation and your ISP gives you delegation control.

Private addresses#

Reserved for use inside your network. They are guaranteed to not route on the public Internet. Two devices anywhere in the world can both use 192.168.0.10 without conflict, those packets stay on their respective LANs.

IPv4: RFC 1918#

IPv6: RFC 4193 Unique Local Addresses (ULA)#

Other reserved-but-not-RFC-1918 spaces you'll meet#

Why this matters for DNS#

• PTR for RFC 1918 space never resolves in the public tree. If you want reverse lookups for your 192.168.0.0/24, you have to stand up your own reverse zone. In the public tree, 192.in-addr.arpa is administered by ARIN, and ARIN delegates 168.192.in-addr.arpa to the AS112 project sink servers, blackhole-1.iana.org and blackhole-2.iana.org (RFC 7534). Those servers host the zone as empty: they answer authoritatively with NXDOMAIN for every name inside it. Nobody can get a real delegation for their private space, because RFC 1918 space is not assigned to any single organization. See reverse-dns.

In practice your query rarely even reaches AS112. Watch what a public resolver does with the zone itself:

curl -s -H 'accept: application/dns-json' \
  'https://cloudflare-dns.com/dns-query?name=168.192.in-addr.arpa&type=NS'

{"Status":3,"TC":false,"RD":true,"RA":true,"AD":false,"CD":false,"Question":[{"name":"168.192.in-addr.arpa","type":2}]}

Status 3 is NXDOMAIN, with no Answer and no Authority section, and 8.8.8.8 returns the same. That answer comes from the resolver itself, not from recursion: ask an AS112 server this exact question directly and it answers NOERROR with the two blackhole-*.iana.org NS records. A resolver that had really walked the tree would have returned those. Both resolvers instead answer RFC 1918 reverse space from their own local zones, which is exactly the behavior RFC 6303 asks for.

RFC 6303 says recursive resolvers SHOULD serve these reverse zones locally instead of leaking the queries upstream. BIND does it by default (empty-zones-enable yes;); Unbound ships the same zones as built-in local-zone defaults (opt a zone back out with local-zone: "168.192.in-addr.arpa." nodefault). Queries that escape anyway land on the AS112 sinks and get NXDOMAIN there.

• A wide-open recursive resolver can leak internal addresses. Queries for 1.1.168.192.in-addr.arpa going to public resolvers expose your internal IP scheme. Configure your resolver to authoritatively return NXDOMAIN for unrouted reverse space. Most DNS server implementations have an "empty zones" feature that does this automatically.
• Split-horizon DNS (a.k.a. DNS views) often returns RFC 1918 internally and a public IP externally. The authoritative server picks a different record set based on the client's source IP, matched against an ACL. See authoritative zones for the working example.

Documentation addresses#

These ranges are reserved by IANA/RFCs explicitly so authors have something they can put in tutorials, books, and docs without accidentally pointing at someone's real production network. They are guaranteed to not route on the public internet. Safe to publish anywhere.

Where you'll see them in DNS#

• In tutorials and RFCs. Every protocol document uses these so reading code or running examples doesn't generate real traffic against unrelated hosts.
• In live example records. A zone can publish a real DNS record that returns a documentation address. The record resolves and dig returns a normal answer, but the address goes nowhere. This wiki does exactly this: example.isitdns.net (a name that lives inside the isitdns.net zone, not a delegated zone of its own) has an A record returning 192.0.2.1 and an AAAA record returning 2001:db8::1. Both resolve; neither routes.

dig @1.1.1.1 example.isitdns.net A

;; QUESTION SECTION:
;example.isitdns.net.           IN  A

;; ANSWER SECTION:
example.isitdns.net.    300     IN  A   192.0.2.1

(The record's TTL is 300. You'll see exactly 300 on a fresh fetch; on a cache hit the resolver shows the remaining time, counting down toward 0.)

nslookup example.isitdns.net 1.1.1.1

Server:     1.1.1.1
Address:    1.1.1.1#53

Non-authoritative answer:
Name:   example.isitdns.net
Address: 192.0.2.1
Name:   example.isitdns.net
Address: 2001:db8::1

Note that plain nslookup shows both addresses: modern nslookup (BIND 9) queries A and AAAA by default, so one command returns the whole pair.

dig @1.1.1.1 example.isitdns.net AAAA

;; QUESTION SECTION:
;example.isitdns.net.           IN  AAAA

;; ANSWER SECTION:
example.isitdns.net.    300     IN  AAAA    2001:db8::1

nslookup -type=AAAA example.isitdns.net 1.1.1.1

Server:     1.1.1.1
Address:    1.1.1.1#53

Non-authoritative answer:
Name:   example.isitdns.net
Address: 2001:db8::1

• In TLDs reserved for testing. .test, .example, .invalid, and .localhost will never be issued as real TLDs. You can build a test rig under lab.test knowing it will never collide with the public Internet. One trap to avoid: .local is not on that list. It belongs to multicast DNS (RFC 6762), and naming a LAN under .local fights with mDNS on macOS and on any Linux client running an mDNS stack (Avahi/nss-mdns, a desktop default but absent on most headless servers). Use .test (or RFC 8375's home.arpa for home networks) instead.

Why documentation addresses exist: two reasons#

1. Privacy. An ISP-delegated IPv6 prefix is fingerprintable to a subscriber line. The first 24–32 bits identify the carrier (publicly resolvable via WHOIS); the next chunk narrows it to a region or a specific subscriber pool. A residential IPv4 WAN address is less precise but trivially geo-located. Documentation ranges give authors something safe to publish that carries no identifying information.

2. Reproducibility. Documentation addresses do not change with your ISP. Someone reading these notes does not have to mentally substitute "your prefix" at every example. They see 2001:db8::/32, recognize it as documentation, and the example stays valid regardless of their own network.

Why mix documentation IPs with real domain names?#

Because it makes hands-on examples runnable. A record like example.isitdns.net A 192.0.2.1 actually resolves, you can dig it, you can see the DNS query in motion, you can practice. But the address doesn't route, so nothing on the other end accidentally receives your packets. Best of both worlds.

Practical hygiene#

If you're editing a doc and you're not sure whether a particular address should be in plaintext:

• Anything inside RFC 5737 / RFC 3849 / RFC 1918 / RFC 4193 / link-local / loopback → safe to publish.
• Anything that looks like your ISP's WAN address or IPv6 prefix → treat it as identifying. Don't put it in shared docs.
• Cert files, .p12, .pem, .key → never in any repo, not even private ones.
• Full MAC addresses → anonymize unless the doc is specifically teaching Layer 2 / ARP / OUI identification. The RFC 9542 documentation range (00:00:5E:00:53:xx, inside the IANA OUI) exists for this purpose, the same way RFC 5737 exists for IPv4.

When in doubt: substitute a documentation address. They were created exactly so you don't have to make this call under pressure.

See also#

• Reverse DNS: in-addr.arpa and ip6.arpa, where private vs public addressing changes who's authoritative
• A record · AAAA record · PTR record, the records that carry these addresses
• split-horizon, how one name resolves differently inside vs outside your network
• Authoritative zones, for how views and ACLs are configured
• query-types, for the full menu of DNS record types
• rfc-index, for the primary references: RFC 1918, RFC 5737, RFC 3849, RFC 4193, RFC 6598, RFC 6303, RFC 7534