IPv6 DNS Uses a Separate Transport from the Address in the Answer

Find IPv6 DNS server addresses and test IPv4 and IPv6 resolver paths without confusing query transport, AAAA records, and website connections.

NTNamefi TeamAuthorOct 21, 2026est. 5 min read
  • dns
  • networking
  • guide

An IPv6 DNS server address identifies a resolver that a client can contact over IPv6. The address does not restrict the resolver to IPv6 answers. A client can request A or AAAA records over either IPv4 or IPv6. RFC 3596 explicitly separates query transport from record content.

For a quick distinction, dig -6 @2001:4860:4860::8888 example.com. A requests IPv4 address records through an IPv6 resolver connection. Conversely, dig -4 @8.8.8.8 example.com. AAAA requests IPv6 address records through an IPv4 connection. These commands are examples, not reported test results.

Use this guide when choosing an IPv6 resolver address or diagnosing a failing DNS connection. Use the AAAA record guide when publishing your website's IPv6 destination.

The resolver connection and the requested record answer different questions

All four combinations of IPv4 or IPv6 transport and A or AAAA queries are valid.

Three choices matter during diagnosis. The client chooses a connection to a DNS resolver. The query specifies a DNS record type. Later, an application establishes its own connection to a destination.

ChoiceExampleWhat the choice establishes
Resolver transportIPv6 to Google's resolverHow the DNS query reaches that resolver
Requested recordAAAA for example.comWhich address records the client requests
Application connectionA browser connection to a websiteWhether the application reaches the destination

An AAAA answer alone proves neither IPv6 DNS transport nor working IPv6 access to the website. Likewise, an A answer over IPv6 does not mean that the DNS connection used IPv4. Keep the connection and the returned address separate when recording results.

The client's connection also does not determine every upstream connection. A recursive resolver can contact authoritative servers through different available transports. RFC 3901 describes how an unreachable transport in the referral chain can prevent resolution. Contacting a recursive resolver through IPv6 therefore does not prove an entirely IPv6 resolution chain.

IPv6 also does not automatically encrypt DNS. Traditional DNS over UDP or TCP lacks transport encryption. Google documents DoH and DoT as separate encrypted transports. The example dig commands in this article do not enable either encrypted transport.

Public resolver operators publish separate IPv6 addresses

IPv4 and IPv6 addresses provide two entry points to one DNS service.

The following addresses come from the operators' documentation, checked on October 21, 2026. The table identifies specific service variants. The table does not rank speed or guarantee reachability from a particular network.

ServiceIPv6 resolver addressesCorresponding IPv4 addresses
Google Public DNS2001:4860:4860::8888, 2001:4860:4860::88448.8.8.8, 8.8.4.4
Cloudflare standard, without content filtering2606:4700:4700::1111, 2606:4700:4700::10011.1.1.1, 1.0.0.1
Quad9 Secure, with threat blocking2620:fe::fe, 2620:fe::99.9.9.9, 149.112.112.112

Copy both IPv6 addresses from the chosen service's official instructions. Preserve the complete address, including every colon. Cloudflare and Quad9 publish other variants with different addresses and policies. An address from a neighboring table row can select a different service.

Choose the operator and policy before changing settings. The public resolver guide compares privacy, filtering, validation, and recovery requirements. An IPv6 address does not replace that decision.

Before changing a device, save the existing automatic or manual configuration. Google recommends preserving the previous DNS settings. Follow the current device documentation because fields and configuration scope differ across platforms.

Test direct queries before changing the network default. A public IPv6 resolver needs a usable IPv6 path from the testing device. Entering a resolver address cannot supply missing IPv6 connectivity. On a managed network, preserve required private DNS behavior and involve the network administrator.

Paired queries isolate failures in the resolver connection

A successful DNS answer and a successful website connection require separate checks.

Start with one provider and one public hostname. Keep the hostname and query type unchanged while comparing transports. The BIND dig manual documents server selection, record types, and the -4 and -6 options.

Run dig -4 @8.8.8.8 example.com. A, then dig -6 @2001:4860:4860::8888 example.com. A. Repeat with AAAA instead of A. Each command directly selects a resolver without changing stored DNS settings. The four queries test transport and record type independently.

Keep the complete output. Record the command, time, response status, answer section, and reported server. Avoid +short during the first diagnosis because compact output omits context.

Use the following table to decide which boundary needs investigation. The table gives diagnostic leads, not confirmed causes.

ObservationNext investigation
IPv4 responds, but IPv6 times out for both record typesCheck the IPv6 route, resolver address, and network access rules
Both transports return an AAAA answer, but the website failsCheck the website connection separately
The resolver returns NXDOMAINCheck the exact queried name
A response lacks the requested record typeInspect the full answer and authoritative configuration
Direct queries work, but the application failsInspect the application's actual resolver path

A timeout differs from a negative DNS response. NXDOMAIN indicates a name error. A response can also report an existing name without data for the requested type. RFC 2308 distinguishes name errors from missing-type answers. A missing AAAA answer does not establish a broken IPv6 connection to the resolver.

For an IPv6 timeout, check the device's assigned IPv6 connectivity and the route toward the exact resolver address. Review relevant firewall or VPN rules with the network operator. Do not publish or delete website AAAA records to repair a client-to-resolver connection.

If direct queries succeed while a browser fails, identify the browser's configured resolver and encrypted-DNS mode. The direct command proves only the tested command's path. The DoH and DoT guide explains application scope and fallback checks.

If both DNS paths work while the website fails, continue with separate application tests in the AAAA record guide. A correct DNS answer does not configure the website's listener, certificate, or routing.

For a self-hosted resolver, distinguish the client's IPv6 listener from the resolver's upstream connectivity. A local listener can answer cached queries while an upstream problem remains. Preserve the query evidence and inspect the operating configuration before changing several settings together.

Finish with a short incident record: resolver address, transport, queried name, record type, result, and next failed boundary. The record should explain the observed failure without treating every IPv6 symptom as an AAAA problem.

These sources support the guide

All sources were opened on October 21, 2026, America/Los_Angeles. Commands describe checks to perform, not measurements from a particular network.

About the author(s)

Namefi Team • Namefi
NTAuthor

Namefi is a collective of engineers, designers, and operators who obsess over building tools that make managing your onchain domain names effortless.

Related guides

Discuss this post

View the discussion on Namefi Discuss