Forward DNS turns a name into an address. Reverse DNS runs the other way: given 192.0.2.25, what is this machine called? The answer lives in a strange corner of the tree, under in-addr.arpa and ip6.arpa, written backwards and run by whoever holds the address. If addresses, prefixes and subnet masks are hazy, start with networks · IP addresses & subnets; for what DNS is and how a lookup works, networks · DHCP & DNS. This chapter picks up from there.
Common mix-up: owning example.com does not let you set the reverse name of your server. The PTR record for 192.0.2.25 sits in a zone belonging to whoever holds that address, usually your hosting provider or ISP. You can point mail.example.com at any address you like, but to make the address point back, you have to ask the address holder.
The DNS is a tree of labels, and a name is read from the leaf up to the root: in www.example.com, www is the most specific part and com the most general. Each dot is a place where one party can hand authority down to another.
An IPv4 address is written the other way round. In 192.0.2.25, the 192 is the broadest piece, a big slice of the address space, and the 25 picks out one machine inside a small network. If you wanted addresses to live in the DNS tree, with the broad part near the root and the specific part at the leaf, you would have to turn them around. That is exactly what the DNS designers did. RFC 1035 §3.5 defines a domain called IN-ADDR.ARPA in which an address is written as its four numbers in reverse order, each one a label, with in-addr.arpa on the end:
Because each octet is its own label, the tree has natural cut points every 8 bits. 192.in-addr.arpa covers the whole 192.0.0.0/8 range; 2.0.192.in-addr.arpa covers the 256 addresses of 192.0.2.0/24, and so on down to the single address. A reverse lookup is an ordinary DNS query for an ordinary name; nothing in the protocol is special. The resolver walks from the root to arpa, to in-addr.arpa, then through the reversed octets, following referrals exactly as Chapter 3 describes. The command-line tools hide the reversing for you:
; simulated output: documentation addresses, reserved names $ dig -x 192.0.2.25 +noall +answer 25.2.0.192.in-addr.arpa. 3600 IN PTR mail.example.net. $ dig mail.example.net A +noall +answer mail.example.net. 3600 IN A 192.0.2.25
The second query is the check you will meet again later in this chapter: the name the address claims, looked up forward, leads back to the same address. When both directions agree, a reverse name means something. When they don't, it is just a string somebody typed.
The name is a leftover from the ARPANET. arpa started life as the home for hosts during the move from the old ARPANET host tables to the DNS, and the reverse-mapping tree was built under it. RFC 3172 (2001) kept the domain for infrastructure use and redesignated the name as an acronym, "Address and Routing Parameter Area," precisely so it would stop implying a link to the US agency.
Today IANA manages .arpa in cooperation with the Internet Architecture Board, and it holds only infrastructure zones: in-addr.arpa, ip6.arpa, the telephone-number zone e164.arpa, the home-network zone home.arpa (Chapter 10) and a handful of others. IANA lists them on its .arpa page in the sources.
IPv6 addresses are 128 bits long and written in hex, in eight groups of four digits separated by colons, with leading zeros dropped and the longest run of all-zero groups squeezed into ::. The reverse tree for IPv6, defined in RFC 3596 §2.5, lives under ip6.arpa, and it does not use groups at all. Every single hex digit becomes a label. A hex digit is four bits, a nibble, so a full address becomes 32 labels.
To build one by hand you have to undo all the shorthand first. Take 2001:db8::1:
Nobody does this by hand twice; dig -x and the builder below do it for you. But the steps matter when you configure a zone, because the place you are allowed to cut the tree follows from them. A delegation can only happen at a dot, so IPv6 reverse zones are delegated on 4-bit boundaries: a /32 is 8 nibbles, a /48 is 12, a /56 is 14, a /64 is 16.
| Prefix | Labels in the zone name | Zone for 2001:db8:42::/prefix | Typical holder |
|---|---|---|---|
| /32 | 8 nibbles | 8.b.d.0.1.0.0.2.ip6.arpa | An ISP's allocation from a regional registry |
| /48 | 12 nibbles | 2.4.0.0.8.b.d.0.1.0.0.2.ip6.arpa | A site or business customer |
| /56 | 14 nibbles | 0.0.2.4.0.0.8.b.d.0.1.0.0.2.ip6.arpa | A home connection, often |
| /64 | 16 nibbles | 0.0.0.0.2.4.0.0.8.b.d.0.1.0.0.2.ip6.arpa | One network segment |
A /50 ends two bits into a nibble, so there is no single zone name for it. The holder needs one zone for each value the partly-used nibble can take within the prefix: two free bits give four zones, each a /52. IPv4 has the same problem at every non-octet boundary, only worse, because an octet is 8 bits: a /26 would need 64 one-address zones. That is why IPv4 got the CNAME trick in the next section and IPv6 mostly gets nibble-aligned allocations.
Two cautions when you read IPv6 addresses from logs. The compressed form is not unique unless it follows RFC 5952 (lowercase, no leading zeros, the longest zero run compressed, the first one if there is a tie), so 2001:DB8:0::1 and 2001:db8::1 are the same address. And an address with an interface suffix such as fe80::1%en0 carries a zone index that only means something on one machine; it never appears in a DNS name. The builder strips it and says so.
Type any IPv4 or IPv6 address, in any valid shorthand, or paste a reverse name ending in in-addr.arpa or ip6.arpa to decode it. A real parser checks the input, expands it step by step and builds the owner name of the PTR record. The picture shows each label leaving its place in the address and landing reversed in the DNS name. Move the prefix slider to see which zone a prefix of that length would be, and what happens when the prefix does not end on a label boundary.
Forward names are delegated along the path of domain registration: the root hands com to its registry, the registry hands example.com to whoever registered it. Reverse names are delegated along a completely different path, the path that addresses take.
IANA holds the top of the address space and hands large blocks to the five Regional Internet Registries: AFRINIC, APNIC, ARIN, LACNIC and the RIPE NCC. Each registry allocates smaller blocks to ISPs, hosting companies and large organizations. Every time an address block changes hands, the matching reverse zone is delegated along with it, with NS records pointing at the new holder's name servers. So the zone 2.0.192.in-addr.arpa belongs to whoever holds 192.0.2.0/24, and only they can publish a PTR inside it.
That has a practical consequence everyone runs into once. You rent a server, it gets an address from the provider's block, you create mail.example.com pointing at it, and the reverse lookup still says something like 203-0-113-77.cust.provider.example. Your registrar can't change it. Your DNS host can't change it. Only the provider can, usually through a control-panel setting or a support ticket, because the reverse zone is theirs. With your own address block, the registry delegates the zone to your name servers and you run it like any other zone (Chapter 6).
The commonest reverse-DNS fault is a registry delegation to name servers that no longer answer for the zone, after a provider renumbers or moves DNS hosting and forgets to update the registry. Every reverse lookup for those addresses then waits for timeouts before failing. RFC 8501 notes that some services, SSH servers among them, wait for any reverse answer, even NXDOMAIN, before they respond, so a fast "no such name" is much better than silence, and a delegation to servers that don't exist should be avoided.
Large ISPs fill their IPv4 reverse zones with generated names, one per address, often with the address and a region baked in, and some create matching forward records so both directions agree (RFC 8501 §1.1 shows the pattern). Those generic names tell a log reader which network a visitor came from. They say nothing about who is using the address today.
The octet boundaries cause a real problem. Suppose your provider gives you 192.0.2.64/26, sixty-four addresses. The smallest reverse zone that contains them is 2.0.192.in-addr.arpa, and it also contains the other 192 addresses, which belong to other customers. A zone can be delegated only once, so it seems the provider must keep it and edit your PTR records for you forever.
RFC 2317, published in March 1998, solved this without changing any DNS software. The provider creates a new, made-up child zone underneath the /24, named after your block, for example 64/26.2.0.192.in-addr.arpa, and delegates it to your name servers. Then, in its own /24 zone, it adds one CNAME per address in your block, pointing each normal reverse name into your child zone:
; the provider's zone (simulated, after RFC 2317 §4) $ORIGIN 2.0.192.in-addr.arpa. 64/26 NS ns1.customer.example. 64/26 NS ns2.customer.example. 65 CNAME 65.64/26 ; = 65.64/26.2.0.192.in-addr.arpa. 66 CNAME 66.64/26 ; ... one CNAME for every address in the block ; the customer's zone, on the customer's own servers $ORIGIN 64/26.2.0.192.in-addr.arpa. 65 PTR gateway.customer.example. 66 PTR mail.customer.example.
A resolver looking up 192.0.2.66 asks for 66.2.0.192.in-addr.arpa as usual. The provider's server answers with the CNAME, the resolver follows it into the delegated child zone, and the customer's server returns the PTR. The customer edits their own records whenever they like; the provider sets the CNAMEs once, and since they follow mechanically from the block, they can be generated by a script. RFC 2317 says as much: some people find the CNAMEs ugly, and it declines to argue the point.
The name of the child zone is a convention, not a rule. The RFC uses the first address and the prefix length (64/26), and also shows how to point the CNAMEs at an entirely different part of the tree. Common variants use a hyphen, either 64-26 or the address range 64-127, because some provisioning tools choke on a slash. Resolvers don't care; the CNAME tells them where to go.
Yes. RFC 2181 §11 is blunt about it: the DNS itself restricts only lengths (1 to 63 octets per label, 255 for the whole name), and any binary string can be a label. The familiar letters-digits-hyphen rule applies to host names, which a reverse zone name is not. Applications are free to be stricter, which is why the hyphen variants exist.
RFC 2317 §5.1 adds an operational tip from the days when some servers would hand back a bare CNAME without chasing it: make the provider's servers secondaries for the customer's child zone, so they can answer the whole chain themselves. Modern resolvers chase CNAMEs on their own, but it remains good advice for speed and resilience.
Enter a block smaller than a /24, between /25 and /32, and pick a naming style. The designer checks that the block starts on its own boundary, then writes both zones: the provider's NS and CNAME records and the customer's PTR records. Pick a host and press Run to watch a resolver chase the lookup through the CNAME, computed from the records shown. Then break the provider's side and run it again. All records are simulated, using documentation addresses and reserved names.
A PTR record is a claim made by the address holder: "this address is called mail.example.net." Nothing stops the holder from claiming any name at all, including names in domains they have nothing to do with. The forward zone, on the other hand, belongs to the domain owner. So the standard sanity check uses both: look up the PTR, then look up that name's A or AAAA records, and see whether the original address is among them. If it is, both owners agree, and the result is called forward-confirmed reverse DNS, or FCrDNS.
RFC 1912, the 1996 list of common DNS mistakes, puts the operator's side plainly: make sure your PTR and A records match, because failing to can cost you service. RFC 8501 lists where PTR lookups actually get used:
| Use | What the lookup is for | How much weight it can bear |
|---|---|---|
| Mail receivers | Many refuse or penalize a sending server whose address has no PTR or does not forward-confirm | A spam signal, one of many. Chapter 8 covers the real mail authentication. |
| Log files | Annotating an address with a name so a human can tell which network it came from | Fine as a label next to the address, never instead of it |
| Traceroute | Naming each router hop; operators often encode city and interface in the name | Very useful for troubleshooting; names can be stale |
| SSH and other servers | Recording or matching the client's host name | Weak; RFC 8501 calls the inference a poor one |
| Service discovery | DNS-SD uses PTR records to list services, a different use of the same type | Unrelated to address lookups |
FCrDNS is a consistency check, not an identity check. A pass shows that the address holder and the domain owner agree, which is useful, because a spammer on a hijacked home connection usually can't arrange that. But a pass doesn't show who is behind the address, and the names in both directions can belong to the same careless or hostile party.
An address may carry more than one PTR record, and a name may have several A or AAAA records. A careful checker tries each reverse name and passes if any forward answer contains the original address; the instrument below does exactly that for the addresses list. In practice operators keep one PTR per address, because plenty of software only looks at the first answer.
RFC 1912 also says a PTR should point at a name with a real A record, not at an alias defined by a CNAME. A PTR that targets an alias makes the forward check harder for the software doing it, and it is a common source of mismatches after a server is renamed.
Pick an address. The checker looks up its PTR in a small simulated DNS, looks up the name it gets back, and compares. Each scenario is internally consistent: the reverse records belong to the address holders, the forward records to the domain owners. Edit either field to play address holder or domain owner yourself. The last scenario is the one CWE-350 warns about: an address holder who simply claims somebody else's name, and an access rule that believes it.
MITRE's Common Weakness Enumeration has an entry for this exact mistake: CWE-350, Reliance on Reverse DNS Resolution for a Security-Critical Action. The pattern is software that takes a client's address, looks up its PTR, and grants something because the name looks right: an admin page that allows anything ending in .example.com, a database that trusts "our own" hosts by name, an old-style host-based login.
It fails for a simple reason you have now seen twice. The PTR is written by the address holder. Anyone who controls a block, a small hosting customer with an RFC 2317 delegation included, can make their addresses claim to be admin.example.com. On top of that, unless the answers are signed and validated, a DNS response can be forged or poisoned in transit (Chapter 13).
Forward confirmation closes the first hole for a rule like "ends in .example.com", because the attacker can't make example.com's forward zone agree. It does not make reverse names a credential. It still depends on unsigned DNS answers, it adds lookups an attacker can delay, and it proves only that two DNS records agree. CWE-350 lists forward-and-reverse checking as a partial mitigation, and recommends verifying identity some other way.
| Instead of | Do this | Why it holds |
|---|---|---|
| Allow if PTR ends in our domain | Authenticate the client: TLS client certificates, SSH keys, signed tokens | Proof comes from a secret key the client holds, not from a record someone else wrote |
| Trust "our hosts" by name | Restrict by address or prefix at the network layer as well, as defense in depth | Routing is harder to fake than a PTR, though addresses alone are not identity either |
| Log only the reverse name | Log the address as the fact; add the name as an annotation, with the time it was resolved | The address is what actually connected; the name can change or lie |
| Resolve names during every request | Resolve asynchronously, off the critical path, with short timeouts | Slow or lame reverse zones can't stall your service |
If the reverse zone is signed and your resolver validates, you know the PTR really came from the zone's owner and was not altered on the way (Chapter 11). That removes forgery in transit. It does nothing about the main problem: the zone's owner is free to sign a lie. A validated PTR saying admin.example.com is still only the address holder's claim. RFC 8501's security section says the same thing in other words: reverse records are easily forged unless DNSSEC or other measures are used, and the chain of inferences people draw from them is questionable anyway.
A useful review question for any access rule: "who can write the data this rule trusts?" For a reverse name the answer is "whoever holds the address," which is almost never the party you meant to trust.
Every network that uses private addresses such as 10.0.0.0/8 or 192.168.0.0/16 generates reverse lookups for them: a log server naming its clients, a printer dialog, a traceroute. Those addresses mean something only inside one site, so the public DNS can't possibly answer. If the local resolver forwards the queries upstream anyway, they travel to public servers that can only say "no such name," leaking a little about the inside of the network and adding load for nothing.
RFC 6303 (2011) fixes this by naming a set of locally served zones that resolvers should answer themselves, usually with an empty zone that returns NXDOMAIN at once. The list includes the RFC 1918 private ranges (10.in-addr.arpa, the sixteen zones 16.172 through 31.172.in-addr.arpa, and 168.192.in-addr.arpa), loopback, link-local, the three IPv4 documentation blocks, IPv6 unique-local addresses (d.f.ip6.arpa), IPv6 link-local and the IPv6 documentation prefix. RFC 7793 later added the shared address space 100.64.0.0/10 used by carrier-grade NAT, and IANA keeps the current list as a registry. Many resolvers ship with these zones built in. For queries that escape anyway, the AS112 project (RFC 7534) runs volunteer anycast servers that absorb them.
IPv6 brings a different emptiness. A single /64 has 264 possible addresses, and hosts usually pick their own with SLAAC, often rotating temporary privacy addresses (RFC 8981) so they can't be tracked. Nobody can write a PTR for every address that might be used, and RFC 8501 points out that even at 1,000 entries a second, filling one /48 would take tens of trillions of years. Its survey of the options:
| Approach (RFC 8501 §2) | How it works | Catch |
|---|---|---|
| Negative response | Answer NXDOMAIN for subscriber addresses | Most honest; fails any "must have a PTR" check, which mail receivers may welcome |
| Wildcard | One wildcard PTR per customer prefix | Scales, but the forward lookup can't lead back, so FCrDNS fails |
| Dynamic DNS | Hosts send AAAA and PTR updates when they get an address | No standard way to tell hosts where to send updates; must be secured |
| Delegate | Hand the customer their prefix's reverse zone | Most accurate, but home users rarely run name servers |
| On the fly | The server synthesizes a PTR (and matching AAAA) from the address when asked | Generic names; needs special software, and complicates DNSSEC signing |
The practical upshot: give every server, router interface and mail sender with a stable address a PTR that forward-confirms, and don't be surprised, or alarmed, when the IPv6 laptops on a network have none. RFC 8501 also warns about privacy. A PTR that spells out a customer's name or street turns every server log into a directory, so the default for subscriber addresses should identify nobody.
A quick test from inside a network: ask your resolver for the PTR of a private address that is not in use, such as dig -x 10.255.255.254. A resolver serving the RFC 6303 zones answers NXDOMAIN immediately, and the authority section shows a locally generated SOA rather than one from the public tree. A long pause followed by an answer from far away means the queries are leaving the building. Chapter 14 shows how to read that output line by line, and Chapter 10 covers the rest of the names that should stay local.