Home / Blog / IPv6 Reverse DNS
IPv6 Guide

IPv6 Reverse DNS: The Complete Guide for ISPs

February 5, 2026 7 min read
IPv6 Reverse DNS ip6.arpa RIPE Automation

IPv4 reverse DNS is manageable — painful, but manageable. A /22 gives you 1,024 addresses. A /16 gives you 65,536. For each, you create PTR records, manage the in-addr.arpa zones, and accept that it takes effort. IPv6 changes the scale entirely. A single /48 allocation — a standard customer assignment in many ISP deployments — contains 280 trillion addresses. A single ISP might hand out thousands of /48s.

The approaches that work for IPv4 PTR management don't scale to IPv6. This guide explains how IPv6 reverse DNS is structured differently, what delegation from regional registries looks like, and what automation is required to operate it responsibly.

How IPv6 Reverse DNS Differs from IPv4

In IPv4, PTR records live in the in-addr.arpa domain. The address is written in reverse octet order. For 203.0.113.45, the PTR record is at 45.113.0.203.in-addr.arpa. Clean, predictable, with one record per IP.

In IPv6, PTR records live in the ip6.arpa domain. The structure is similar in concept but operates at nibble (4-bit) granularity instead of octet (8-bit) granularity. The full 128-bit IPv6 address is expanded into 32 hex nibbles, reversed, and each nibble separated by a dot.

For the IPv6 address 2001:0db8:85a3:0000:0000:8a2e:0370:7334, the PTR record lives at:

4.3.3.7.0.7.3.0.e.2.a.8.0.0.0.0.0.0.0.0.3.a.5.8.8.b.d.0.1.0.0.2.ip6.arpa.

This format makes the zone structure far more granular. IPv4 delegations typically happen at /8, /16, or /24 boundaries (corresponding to full octets in the in-addr.arpa name). IPv6 delegations happen at nibble boundaries — /4, /8, /12, /16, /20, /24, /28, /32, /36, /40, /44, /48, etc. The most common delegation points for ISPs are /32 (the ISP's full allocation from the RIR) and /48 (per-customer delegations to the ISP's customers).

Scale Challenges: The Mathematics of IPv6 rDNS

IPv4 and IPv6 address spaces are not comparable in size:

An ISP that receives a /32 IPv6 allocation from RIPE or ARIN gets 2⁹⁶ addresses — approximately 79 octillion. Even if only a fraction of those addresses are ever used, the potential PTR record count is incomprehensible.

The answer is not to create PTR records for every possible address. It is to:

  1. Create PTR records for addresses that are actually assigned and in use
  2. Delegate reverse DNS zones to customers who want to manage their own PTR records
  3. Use wildcard PTR records or synthesized records for large blocks where individual records aren't practical
  4. Automate everything — manual record-by-record management is not viable
Key point: Unlike IPv4, where you typically create PTR records for all routed IPs, IPv6 rDNS management is about creating records for used addresses and delegating zones to entities responsible for sub-blocks. No one manages individual PTR records for an entire /32.

Delegation from Regional Internet Registries

Regional Internet Registries (RIPE NCC for Europe/Middle East, ARIN for North America, APNIC for Asia-Pacific, LACNIC for Latin America, AFRINIC for Africa) are responsible for the top-level ip6.arpa zones corresponding to their allocated ranges. ISPs receive their IPv6 allocations from these RIRs, and the RIR delegates the corresponding ip6.arpa zone to the ISP's nameservers.

For example, if an ISP receives the allocation 2001:db8::/32 from RIPE NCC, RIPE will delegate the zone:

8.b.d.0.1.0.0.2.ip6.arpa.

to the ISP's authoritative nameservers. This delegation is managed through the RIR's member portal (RIPE's LIR portal, ARIN's RPKI portal, etc.) and requires the ISP to have functioning nameservers with correct SOA and NS records before the delegation is created.

Configuring the delegation at the RIR

The exact process differs by RIR, but the general steps are:

  1. Configure your authoritative DNS servers with the ip6.arpa zone for your allocation
  2. Create NS records pointing to your nameservers in that zone
  3. Log into the RIR portal and update the reverse delegation object to point to your nameservers
  4. Verify the delegation using dig NS 8.b.d.0.1.0.0.2.ip6.arpa.

Delegating sub-zones to customers

When an ISP assigns a /48 to a customer, it can delegate the corresponding ip6.arpa sub-zone to the customer's nameservers. This allows the customer to manage their own PTR records without the ISP having to handle each request individually.

For a customer assigned 2001:db8:1234::/48, the ISP delegates:

4.3.2.1.8.b.d.0.1.0.0.2.ip6.arpa.    IN    NS    ns1.customer.example.
4.3.2.1.8.b.d.0.1.0.0.2.ip6.arpa.    IN    NS    ns2.customer.example.

This is the correct operational model for business customers who manage their own mail servers and need full control over PTR records. For residential customers or customers who don't manage DNS, the ISP maintains the zone.

Strategies for Managing IPv6 PTR at Scale

Synthesized PTR records

For large blocks of customer IPs where individual PTR records aren't necessary (residential broadband, for example), synthesized PTR records are a practical approach. Instead of creating individual records, a scripted zone generation system creates PTR records by transforming the IP address into a hostname pattern.

Example: for any IPv6 address in a residential /48, automatically generate a PTR of the form:

2001-db8-5678-0-0-0-0-1.dynamic.yourisp.net

This can be accomplished with BIND's built-in $GENERATE directive for smaller ranges, or with dynamic DNS generation tools for larger ones. The result: every address has a valid PTR record without manually creating billions of entries.

Delegation-first for business customers

For business customers, the goal is delegation rather than management. When you provision a /48 to a business customer:

  1. Ask if they want to manage their own reverse DNS
  2. If yes, collect their nameserver details and create the delegation
  3. If no, create default PTR records for the addresses they identify as servers

A dedicated rDNS management portal handles both flows — delegation management for self-managing customers and PTR record management for the ISP's own zones.

Event-driven PTR creation for servers

For data center customers or business customers provisioning individual servers, the correct approach is event-driven PTR creation tied to the server provisioning workflow. When a server is deployed with an IPv6 address, the PTR record is created immediately as part of the provisioning process — not days later when the customer notices email isn't working.

Common mistake: ISPs often handle IPv6 PTR requests identically to IPv4 — via support tickets, one record at a time. This breaks down quickly because IPv6 customers may have thousands of routable addresses, not just a handful. The workflow must be designed for scale from the start.

Validating IPv6 PTR Records

Testing IPv6 PTR records follows the same logic as IPv4 but requires specifying the record type explicitly:

# Reverse lookup for an IPv6 address
dig -x 2001:db8:85a3::8a2e:370:7334

# Or using the expanded ip6.arpa format
dig PTR 4.3.3.7.0.7.3.0.e.2.a.8.0.0.0.0.0.0.0.0.3.a.5.8.8.b.d.0.1.0.0.2.ip6.arpa.

# Verify forward lookup matches
dig AAAA mail.example.com

FCrDNS (Forward Confirmed Reverse DNS) validation for IPv6 requires confirming that:

  1. The IPv6 PTR lookup returns a hostname
  2. The AAAA record for that hostname resolves to the original IPv6 address
  3. Both lookups complete without error

Why IPv6 rDNS Is Now a Deliverability Requirement

As IPv6 email traffic grows, major mail providers are applying the same PTR requirements to IPv6 that they have long applied to IPv4. Google, Microsoft, and large enterprise mail platforms check IPv6 PTR records when connections arrive over IPv6. An IPv6 address without a PTR record will fail the same checks that an IPv4 address without a PTR would fail.

For ISPs, this means that IPv6 PTR management is no longer optional infrastructure. Any customer using IPv6 for mail must have functioning PTR records. Given the scale of IPv6 address space, this is only achievable with automation — manual management of IPv6 PTR records is not a realistic operational approach.

Summary

IPv6 reverse DNS is structurally similar to IPv4 — PTR records, ip6.arpa zones, RIR delegation — but operates at a scale that breaks every manual management approach. The operational model for ISPs managing IPv6 rDNS must include:

IPv6 rDNS Management for ISPs

WebPTR handles both IPv4 and IPv6 reverse DNS management — delegation tracking, bulk PTR operations, customer zone delegation, and API integration for automated provisioning workflows.

Learn about WebPTR →