IPv6 DNS Records: Every Record Type That Touches IPv6, Explained

IPv6 Touches More of a DNS Zone Than People Expect

Ask most people what "IPv6 DNS" means and they'll say AAAA record, full stop. That's the headline record, but it's genuinely only one of several places IPv6 shows up in a properly configured DNS zone. Reverse lookups need their own dedicated zone structure. Nameserver delegation needs glue records that can carry IPv6 addresses. And the newest generation of DNS records — HTTPS and SVCB — can bundle IPv6 connection hints directly into the record clients fetch before they even try to connect. This guide maps the whole picture, not just the one record most tutorials stop at.

1. AAAA — The Forward Address Record

The record most people mean when they say "IPv6 DNS record." It maps a hostname directly to a 128-bit IPv6 address, playing the same role an A record plays for IPv4. A single hostname can hold multiple AAAA records for load balancing or geo-distribution, and it can coexist with an A record for the same name without conflict — that combination is what's called dual-stack. For a full breakdown of this record specifically, see our dedicated AAAA Record Explained guide.

2. PTR — Reverse DNS Under ip6.arpa

Reverse DNS answers the opposite question an AAAA record does: given an IPv6 address, what hostname does it belong to? IPv4 handles this through the in-addr.arpa zone; IPv6 uses a structurally different zone called ip6.arpa. Because a full IPv6 address is 128 bits, expressed as 32 hexadecimal nibbles, the ip6.arpa naming convention writes every single nibble as its own reversed DNS label — a visually striking, genuinely unfamiliar-looking zone file the first time you see one.

; Address: 2001:db8::1
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. IN PTR host.example.com.

Every hex digit of the fully expanded address becomes its own label, written in reverse nibble order, under the ip6.arpa suffix. Getting this right by hand is tedious and genuinely error-prone — most DNS management panels and provisioning scripts generate it automatically from the forward address, and that automation is worth trusting rather than hand-building nibble sequences yourself.

3. Glue Records — Nameserver Addresses That Can Be IPv6

When a domain's own nameservers live inside that same domain (a common setup — ns1.example.com serving example.com itself), the parent zone needs to supply a "glue record": the nameserver's actual IP address, delivered alongside the delegation, so resolvers don't hit a circular dependency trying to resolve the nameserver's name using the very nameserver they're trying to reach. Glue records can be IPv4 (A), IPv6 (AAAA), or both — and if a domain's nameservers are dual-stack, both glue record types should be present at the registrar level, not just the zone's own internal records.

4. HTTPS and SVCB — Modern Connection Hints

These are genuinely new record types (standardized via RFC 9460) designed to let a client learn key connection details — supported protocols (like HTTP/3), a target port, and IP address hints for both families — in a single DNS answer, before it even opens a TCP connection. An HTTPS record can carry an "ipv6hint" parameter directly, letting a sufficiently modern client skip a separate AAAA lookup entirely in some cases. Adoption is still growing, and not every recursive resolver or client fully leverages it yet, but it represents the direction DNS-assisted connection setup is heading, and IPv6 support is baked into its design from the start rather than bolted on.

Building a Reverse Zone: Step by Step

Real-World Scenarios

Common Mistakes

Best Practices

Treat IPv6 DNS as a complete package, not a single record: forward (AAAA), reverse (PTR under ip6.arpa), and delegation support (glue) all need to be correct together for a fully functional dual-stack or IPv6-only deployment. Let provisioning tools and DNS panels generate reverse-zone entries automatically rather than hand-constructing nibble sequences, verify every piece with a live lookup rather than trusting configuration alone, and treat HTTPS/SVCB adoption as a forward-looking enhancement layered on top of a solid AAAA foundation, not a replacement for it.

DNS Provider Support for IPv6 Records

Every major managed DNS provider treats AAAA, PTR, and glue records as first-class citizens today — there's no provider gap to worry about for the core record types. Where meaningful differences show up is in tooling around them: some providers auto-generate the correct ip6.arpa PTR label from a forward AAAA entry with a single click, some require manually constructing the reverse zone yourself, and HTTPS/SVCB record support specifically is still rolling out unevenly, with some dashboards exposing a dedicated record-type option and others requiring a raw TXT-style entry through an advanced or "raw record" editor.

One consistent theme across every provider: reverse DNS (PTR under ip6.arpa) for a public IPv6 address is typically controlled by whoever actually owns and announces that IP block — your ISP or hosting provider — not by whichever service manages your domain's forward DNS zone. This is a frequent point of confusion: adding a forward AAAA record in Cloudflare, for instance, does nothing to configure reverse DNS for the server's actual IPv6 address, because that reverse zone is delegated by a completely different party.

Command-Line Verification for Each Record Type

Beyond point-and-click DNS panels, every record type discussed here can be verified directly from a terminal:

The +trace flag is particularly useful when diagnosing a delegation-level problem, like a missing glue record — it walks the entire resolution chain manually, root servers through TLD through authoritative, showing exactly where the chain breaks rather than just returning a final failure with no context.

DNSSEC and IPv6 Records

DNSSEC signs DNS answers cryptographically to prevent tampering and cache poisoning, and it applies to AAAA, PTR, and every other record type in a signed zone exactly the same way it applies to A records — there's no special IPv6 carve-out in how DNSSEC itself works. What does matter operationally is that reverse zones (ip6.arpa) are frequently managed by a different party than your forward zone, which means DNSSEC coverage for reverse IPv6 lookups depends on whether your ISP or hosting provider has signed their delegated reverse zone — something worth explicitly asking about rather than assuming, since forward-zone DNSSEC on your own domain says nothing about the state of your reverse delegation.

Automation, CI/CD, and Monitoring Considerations

Infrastructure-as-code tools — Terraform, Pulumi, CloudFormation, and similar — universally support AAAA record management as a resource type, making it straightforward to keep forward IPv6 records in version control alongside everything else. Reverse DNS (PTR) automation is less standardized, largely because it depends on whichever party controls the actual IP block delegation, and CI/CD pipelines updating infrastructure rarely have direct API access to a provider's reverse-zone delegation the way they do to their own forward zone.

For monitoring, the practical guidance is simple but frequently skipped: uptime and health-check tooling needs to test AAAA-resolved endpoints independently from A-resolved ones, since a monitor that only ever checks the IPv4 path will report a domain as fully healthy even during an IPv6-specific outage that a meaningful share of visitors are actually experiencing.

Migration Checklist: Adding IPv6 DNS to an Existing Zone

Pros & Cons of a Full IPv6 DNS Setup

Expert Tips

Related Tools

Query the full record picture — including AAAA — with DNS Lookup. Check a single AAAA record directly with AAAA Record Lookup, or go the reverse direction with Reverse DNS Lookup. To understand the AAAA record itself in depth, read AAAA Record Explained, or move on to Dual Stack DNS for how these records combine in a production deployment.