IPv6 DNS Server Addresses and How to Test Them

An IPv6 DNS server accepts DNS queries over IPv6. That is different from returning an AAAA record, which contains an IPv6 address. You can request an AAAA record from a server reached over IPv4, or request an A record from a server reached over IPv6.

If you need an IPv6 address for a public recursive resolver, use the provider addresses below. If you operate a domain’s authoritative DNS, check its delegation and transport separately. The current DNS transport guidance treats IPv4 and IPv6 reachability as separate operational requirements.

Public IPv6 DNS server addresses

These addresses are for recursive DNS: a device asks the resolver to look up names on its behalf. They are not addresses to publish as your domain’s authoritative name servers.

The two addresses in each row belong to the same provider. Check that your device or router can reach IPv6 destinations before replacing its existing DNS settings. Record the old settings first, particularly on a managed network where an internal resolver may answer private names that a public resolver cannot.

Choose a provider based on the DNS policy you need, not an unsourced “fastest server” ranking. Filtering, DNSSEC validation, encrypted DNS support, and your network’s route to the provider are separate considerations. The plain IPv6 addresses above identify where to send conventional DNS queries; entering one does not, by itself, enable DNS over HTTPS or DNS over TLS.

An IPv6 connection and an AAAA answer are different tests

An AAAA lookup asks for a hostname’s IPv6 address. It says nothing about how the query reached the DNS server. This command requests an AAAA answer over IPv4:

dig -4 @1.1.1.1 example.com AAAA

This command requests the same record type over IPv6:

dig -6 @2606:4700:4700::1111 example.com AAAA

BIND’s dig manual defines -4 and -6 as query-transport choices. The AAAA argument selects the record type. To make that distinction especially clear, you can request an IPv4 address record from a server reached over IPv6:

dig -6 @2606:4700:4700::1111 example.com A

Inspect the response status, answer section, and SERVER line rather than relying only on a terse answer. A timeout on the IPv6 command does not prove the name lacks an AAAA record. First check whether the client has usable IPv6 connectivity and whether its network permits DNS traffic to that resolver.

Test UDP and TCP over IPv6

Ordinary dig queries usually start with UDP. Test TCP separately because DNS needs it when a response cannot fit the UDP path, and firewall rules sometimes treat the two transports differently:

dig -6 @2606:4700:4700::1111 example.com AAAA
dig -6 @2606:4700:4700::1111 example.com AAAA +tcp

The first command tests the default query path; +tcp explicitly requests TCP. A successful UDP query followed by a TCP timeout points toward a transport or firewall problem, not automatically bad DNS records. The BIND manual documents these switches, while the DNS transport RFC calls for TCP support on authoritative servers.

Run the checks from the network that has the problem. A successful lookup from a laptop on another connection does not verify the affected router, VPN, container, or IPv6-only subnet.

Configure a recursive resolver without losing internal DNS

On a personal device, add the two IPv6 addresses for your chosen provider using the operating system’s network settings. On a managed network, first establish whether the current DNS service handles internal zones, split-horizon records, or local hostnames. Moving clients straight to a public resolver can make those names stop working even while public websites still resolve.

A network with its own recursive resolver can keep that resolver as the client-facing address and decide separately how it reaches authoritative servers. The resolver’s client-facing IPv6 address and its ability to resolve names across the wider Internet are different capabilities. RFC 10001 recommends dual-stack recursive resolution to avoid names becoming unreachable when part of the authoritative path supports only one address family. An IPv6-only resolver needs an appropriate transition or forwarding arrangement for IPv4-only authoritative paths.

After changing settings, test a public name, an internal name if applicable, and a service your users actually need. Also confirm which DNS server the client queried; browser-level encrypted DNS or a VPN may use a different resolver from the one configured in the operating system.

Check authoritative DNS over IPv6

A domain’s authoritative servers publish its DNS records. Public recursive resolver addresses from the table are not substitutes for the NS records in your domain delegation.

For a domain you operate, check these items together:

• Delegation: The parent zone lists the intended authoritative NS names. If a name server’s address needs parent-side glue to break a lookup dependency, confirm the required A and AAAA glue is present.
• Name-server addresses: The NS names have reachable A and AAAA addresses where the service is meant to support both families. RFC 10001 calls for at least two authoritative servers reachable over each address family. An application hostname’s AAAA record does not establish that its authoritative name servers are IPv6-reachable.
• Transport: Each intended IPv6 name-server address answers DNS queries over both UDP and TCP on port 53. Test from outside the server’s local network.
• Consistent answers: Queries over IPv4 and IPv6 return equivalent zone data. Check the actual authoritative servers, not only a cached recursive answer.
• Security and scope: Keep recursion disabled or tightly restricted on a public authoritative-only service. If the zone is DNSSEC-signed, validate the signing and delegation chain during changes.

These checks follow the distinction between authoritative and recursive service in RFC 10001. A particular DNS provider may manage name-server addresses, signing, and glue through separate interfaces; verify the published delegation after making changes.

Use DNS64 with NAT64 on IPv6-only networks

On an IPv6-only network with a NAT64 path to IPv4 destinations, DNS64 can synthesize an AAAA answer from an A record when the queried name has no AAAA answer. NAT64 then handles the network translation. DNS64 alone cannot provide IPv4 connectivity.

Do not switch a normal dual-stack network to a DNS64 resolver as a generic IPv6 “upgrade.” Cloudflare’s DNS64 documentation limits its use to networks with NAT64 and notes a DNSSEC caveat: a client that independently validates signatures cannot validate a synthesized answer as though the destination published it. Test the resolver and the NAT64 gateway together before applying the change to clients.

Troubleshoot the failing layer

When an IPv6 DNS lookup fails, isolate where it fails before editing a zone:

1. No response from a public resolver over IPv6: Check the client’s IPv6 address, route, and firewall path. Compare UDP and TCP queries.
2. Resolver responds, but a name fails: Compare its response with another resolver. Check the name’s authoritative delegation and whether those name servers are reachable.
3. Only an internal name fails: Confirm the client is still using the organization’s resolver or forwarding rules. A public resolver normally has no access to private DNS data.
4. IPv4 transport works but IPv6 transport fails: Query the intended authoritative server over each family. Verify its listener, address records, firewall policy, and parent delegation.
5. Responses differ across servers: Check that the authoritative instances serve the same zone version and that caches have had time to follow the record’s TTL.
6. A signed name returns SERVFAIL: Investigate DNSSEC validation and the authoritative response. SERVFAIL has other possible causes, so do not assume DNSSEC without evidence.

For a persistent problem, capture the query name, record type, server address, transport, response status, and time of the failed lookup. Avoid broad query logging unless its contents, access, and retention are appropriate for your environment. If your DNS software emits operational events through syslog, Fluxtail’s log management tools can help search those events beside related service logs; the exact fields available depend on the DNS software’s emitted log format.

For a broader diagnosis after the transport checks, see how to fix DNS issues.