Reverse DNS for IPv4 vs IPv6: Why ip6.arpa Delegation Works So Differently from in-addr.arpa

IPv4 reverse DNS and IPv6 reverse DNS use the same underlying concept — but the practical experience of setting them up is completely different, and the reason comes down to how each address space was carved up for delegation

Reverse DNS (translating an IP address back to a hostname, via PTR records) works through special DNS zones — in-addr.arpa for IPv4 and ip6.arpa for IPv6. Both use the same fundamental mechanism (a reversed representation of the address, used as a domain name within these special zones) — but IPv6's vastly larger address space and different allocation practices mean that who controls reverse DNS delegation, and how granular that control is, differs significantly between the two.

The in-addr.arpa zone for IPv4

For an IPv4 address like 203.0.113.42, the corresponding reverse DNS lookup queries:

42.113.0.203.in-addr.arpa

(the octets are reversed, then .in-addr.arpa is appended) — and the PTR record at this name provides the hostname associated with this IP.

Delegation granularity: in-addr.arpa delegation typically happens at IP block boundaries that correspond to how IP address allocations are made — IPv4 address blocks are allocated by Regional Internet Registries (RIRs — ARIN, RIPE NCC, APNIC, etc.) to ISPs and organisations, often in blocks aligned to specific size boundaries (e.g., a /24 block, containing 256 addresses). Reverse DNS delegation for a /24 block can be configured as a single delegation, with the organisation controlling that block then managing PTR records for all 256 addresses within it.

Who controls IPv4 PTR records: generally, whoever controls the IP address block — for most individuals and small businesses, this means their ISP or hosting provider, since they don't own IP blocks directly; for organisations with their own allocated IP blocks (common for larger enterprises, especially those with older, larger allocations from when IPv4 space was less scarce), the organisation itself may control reverse DNS delegation for their block.

The ip6.arpa zone for IPv6

IPv6 addresses are 128 bits (vs IPv4's 32 bits) — represented in reverse DNS as a sequence of individual hexadecimal nibbles (4-bit groups), each separated by dots, in reverse order, under ip6.arpa.

Example: the IPv6 address 2001:db8::1 (which expands to the full form 2001:0db8:0000:0000:0000:0000:0000:0001) would have a reverse DNS query name consisting of all 32 hex digits, each as a separate label, reversed, followed by .ip6.arpa — resulting in a very long domain name (32 labels for the address itself, plus ip6.arpa).

Why nibble-based rather than larger groupings: this granular, nibble-by-nibble structure allows delegation at any bit boundary that's a multiple of 4 bits — which provides flexibility for delegating reverse DNS for IPv6 blocks of various sizes (since IPv6 allocations, while following their own conventions, can occur at various prefix lengths), at the cost of reverse DNS zone files for IPv6 being structurally more complex (more labels, more entries) than their IPv4 equivalents for a comparable "amount" of address space from a human perspective.

Why IPv6 reverse DNS delegation is often less complete in practice

The scale problem: an IPv6 /64 prefix (a common allocation size for an individual subnet, e.g., what might be assigned to a home network or a single server's subnet) contains 2^64 addresses — an astronomically large number. Configuring individual PTR records for "all addresses" in even a single /64 isn't a meaningful concept the way it might be for an IPv4 /24 (256 addresses, where individually configuring 256 PTR records, while tedious, is at least conceptually bounded).

Common approaches for IPv6 reverse DNS:

• Wildcard/pattern-based PTR records: generating PTR records dynamically based on the address itself (e.g., a PTR record that algorithmically reflects the IPv6 address in the hostname, generated for any address within a range, rather than requiring individual configuration per address) — common for ISPs providing reverse DNS for dynamically-assigned customer IPv6 addresses
• PTR records only for specific, individually-assigned addresses (e.g., servers with static IPv6 addresses that are specifically configured, while the broader allocated range has no PTR records at all for addresses not specifically in use)
• No reverse DNS configured at all for many IPv6 ranges — particularly for smaller allocations or less formally-managed deployments, where IPv6 reverse DNS delegation simply hasn't been set up, resulting in PTR lookups for those addresses returning no result

The practical consequence: IPv6 reverse DNS coverage is generally less consistent/complete across the internet than IPv4 reverse DNS coverage — which matters for any application that relies on reverse DNS lookups succeeding (such as the email deliverability use case covered in a previous article on PTR records and email) — a mail server sending from an IPv6 address without a properly configured PTR record may face the same "no reverse DNS" concerns discussed for IPv4 in that context, but the prevalence of "no reverse DNS configured" is higher for IPv6 in practice, which is part of why IPv6 email sending configuration often specifically calls out reverse DNS as something to verify carefully (since it's more likely to be missing/misconfigured by default compared to IPv4, where ISPs/hosting providers have had more time and more established practices for reverse DNS provisioning).

Delegation: who you ask to set up reverse DNS

For IPv4: if you have a dedicated IP address from a hosting provider, the hosting provider typically controls the in-addr.arpa delegation for the block your IP belongs to — setting up a custom PTR record usually involves a request to the hosting provider (often via their control panel, a relatively routine self-service operation for many providers) rather than something you configure in your own domain's DNS zone (since in-addr.arpa is a separate zone hierarchy, tied to IP address ownership/allocation, not to domain name ownership).

For IPv6: similarly, the entity controlling the IPv6 allocation (hosting provider, ISP) controls ip6.arpa delegation — but as discussed, whether they've set up delegation in a way that allows custom PTR records for your specific addresses (as opposed to only wildcard/pattern-based records for the range as a whole, or no reverse DNS at all) varies significantly between providers, and is worth verifying specifically if reverse DNS matters for your use case (e.g., email sending) and you're using IPv6.

Checking delegation depth: where in the chain reverse DNS "stops"

For both IPv4 and IPv6, the in-addr.arpa/ip6.arpa hierarchy follows the same delegation principles as regular DNS (covered in previous articles on glue records and delegation) — the root of in-addr.arpa/ip6.arpa delegates to RIRs, which delegate to ISPs/organisations for their allocated blocks, which may further delegate to sub-allocations (e.g., an ISP delegating reverse DNS for a specific customer's block to that customer's own nameservers, if the customer wants to manage their own PTR records).

"Reverse DNS delegation stops" at whatever point in this chain doesn't have further delegation — querying a PTR record for an address within a block where delegation "stops" (at an RIR, or at an ISP that hasn't further delegated, or at any point where the relevant zone simply doesn't have a record for that specific address) results in no PTR record being found — which, for IPv6 particularly, is a common and often "by design" (or at least "not specifically addressed") outcome for large portions of IPv6 address space that aren't individually provisioned with specific PTR records.

How to use the Reverse DNS Lookup tool on sadiqbd.com

1. Check PTR records for both IPv4 and IPv6 addresses — understanding that "no PTR record found" is a much more common (and often unremarkable) result for IPv6 addresses than for IPv4
2. For email sending infrastructure specifically: verify PTR records exist and are correctly configured for both the IPv4 and IPv6 addresses your mail server might send from — given the higher likelihood of IPv6 reverse DNS being incomplete by default, this is worth checking explicitly rather than assuming it's configured just because IPv4 reverse DNS is
3. For diagnosing "no PTR record" results: understanding the delegation chain (RIR → ISP/org → possibly further delegation) helps identify which party would need to be contacted to configure a PTR record, if one is needed for a specific address

Frequently Asked Questions

Can I set up my own PTR records without involving my hosting provider/ISP? Generally no — PTR records live in the in-addr.arpa/ip6.arpa zone hierarchy tied to the IP address allocation, not in your own domain's zone. Unless your hosting provider/ISP has specifically delegated reverse DNS for your IP range to nameservers you control (which some providers offer for customers with their own IP allocations, but isn't universal or automatic), configuring PTR records requires going through whoever does control that delegation — typically via a request to your provider.

Does every IPv6 address need a PTR record? No — given the scale of IPv6 address space, the practical expectation is that PTR records exist for addresses that are specifically in active use for purposes where reverse DNS matters (e.g., mail servers) — not for "every possible address," which wouldn't be meaningful given how vast IPv6 allocations are. The relevant question for any specific address is whether that address, given what it's being used for, has the reverse DNS configuration appropriate to that use — not whether the entire containing range has universal PTR coverage.

Is the Reverse DNS Lookup tool free? Yes — completely free, no sign-up required.

Try the Reverse DNS Lookup tool free at sadiqbd.com — look up PTR records for any IPv4 or IPv6 address instantly.