The internet that we all know and love has gone through some significant changes to become what it is today. When the Domain Name System (DNS), the system by which internet domain names and addresses are tracked and regulated, was first introduced in 1987, the version of Internet Protocol addresses used was version 4, or IPv4. An IPv4 address is made up of 32 bits of data expressed in dotted decimal format like 156.154.100.100. This provided just over 4 billion IP addresses that could be assigned to devices on the internet.

While this seemed like a tremendous number of IP addresses, with the advent of personal computers, large hosting centers, and home broadband networks, it was clear that the supply of IPv4 addresses would not be infinite and would in fact be running out in short order. Thus, Internet Protocol version 6 (IPv6), and by extension, the AAAA DNS record, was born.

IPv6 means more IP addresses.

There were many additions in IPv6 beyond the capabilities of IPv4, but its main purpose was to greatly expand the number of IP addresses available for use. An IPv6 address uses 128 bits for the IP address, creating 3.4×1038 IPv6 addresses, truly a limitless supply for the ever-expanding Internet of Things.

A DNS “A” Record that provides an IPv4 address for a hostname could not accommodate the format of an IPv6 address, so the AAAA DNS record was created. In a nutshell, an AAAA, or “Quad A,” record is equivalent to a DNS A record but for IPv6. It essentially gives the answer to the question, “what’s the IPv6 address for a web site you want to visit?”

NAT leads to dual-stack V4 and V6.

Due to tricks such as Network Address Translation (NAT) that extended the life of IPv4, the adoption of IPv6 was slow to take off. With the advent of Windows Vista, an IPv6 stack was added as a base part of the operating systems and allowed both IPv4 and IPv6 addresses to be deployed concurrently. This dual-stack system led to DNS queries being sent for not just the A record of an application but the AAAA record as well.

This double query occurs whether there is an AAAA record for the application or not. In the packet capture below a Firefox browser is requesting the web site www.charlieisadog.xyz from a dual-stack computer. You can see that it requests both an A and an AAAA record for the website by default, even though the FQDN has no AAAA record.

In addition to A and AAAA records, most modern browsers are now also requesting HTTPS DNS records that can provide additional information about the host.

UltraDNS and AAAA records.

As an authoritative DNS provider, the primary responsibility of UltraDNS is to ensure the highest level of service and compatibility for all our subscribers. This responsibility includes responding to AAAA queries for several key reasons:

• Universal Service Protocol: Our DNS infrastructure is designed to adhere to global internet standards, which include support for both IPv4 and IPv6 protocols. Responding to AAAA queries is a part of these standards, ensuring that our service is universally compatible and future-proof.
• Network Diversity of End Users: The end users accessing your services may be on a variety of networks, some of which are IPv6-only. To ensure uninterrupted and seamless access for these users, our DNS service needs to respond to AAAA queries. This is crucial for maintaining a consistent user experience across diverse network infrastructures.
• Operational Consistency: Providing a uniform service across all subscribers simplifies our operational model. This consistency in service ensures that we can maintain high performance and reliability for all our customers, regardless of their individual network setups.
• Preparedness for Future Technologies: The internet is evolving, and IPv6 is becoming increasingly prevalent. By handling AAAA queries as a standard practice, we are not only aligning with current standards but also preparing your domain for future technological shifts without requiring immediate action or additional investment on your part.
• Cost and Complexity Reduction: Implementing a selective response system for AAAA queries based on individual subscriber’s infrastructure would significantly increase the complexity and cost of our DNS services. Our approach ensures that we can provide a high-quality, cost-effective service to all our customers.

AAAA queries when no IPv6 records are present.

When end-users and their recursive servers make AAAA queries against UltraDNS but no IPv6 records exist, the following process takes place:

• AAAA Query Made: A client (web browser, web service, mobile device, IoT device, etc.) requests the (un-cached) IPv6 address of a domain by making a AAAA DNS query.
• UltraDNS Processes the Query: The authoritative nameserver for the domain receives the query. It checks its records for an IPv6 address corresponding to the requested domain.
• IPv6 Absence: If no IPv6 address is found due to the domain being IPv4 only, the server moves to the next step without locating an AAAA record.
• NOERROR Status: The nameserver issues a NOERROR response, signifying that the query was valid and processed correctly, but an IPv6 address was not found.
• Answer Section: An empty answer section accompanies the NOERROR status, confirming the domain’s absence of an IPv6 address.
• Empty Answer Section: Along with the NOERROR status, the nameserver response will include an empty answer section, indicating that while the domain exists and the server can process the query, no AAAA record is available for the domain. In other words, it says, “You are at the right place but maybe ask again in a different way,” i.e., try IPv4.  The NOERROR status with an empty answer section conforms to DNS standards per the relevant RFCs, ensuring that the DNS response accurately reflects the absence of an IPv6 record without suggesting that the domain itself does not exist.
• Client Fallback: In the absence of an IPv6 address, the client will typically attempt an A record query to obtain the IPv4 address and continue the communication.
• Client Handling: The resolver and client that made the query will interpret this response. Since no IPv6 address is provided, the client will typically fall back to an A record query (requesting the IPv4 address) if IPv4 connectivity is available. This allows the client to reach the domain using IPv4.
• Continued Communication: The client then continues communication using IPv4, as the IPv6 query did not yield a usable address but did not indicate a fundamental error with the domain itself.
• RFC Compliance: This behavior is in line with DNS standards and RFCs. The RFCs governing DNS behavior (such as RFC 1035 and others related to DNS extensions) dictate that a response should accurately reflect the state of the queried records in the DNS. Returning NOERROR with an empty ANSWER section for a non-existent AAAA record is a way to comply with these standards.
• Avoiding NXDOMAIN Responses: Returning NXDOMAIN in this situation could be misleading, as it implies that the entire domain does not exist, which is not the case if the domain is only lacking IPv6 support. Therefore, NOERROR with an empty ANSWER section is the appropriate response to avoid misinterpretation and ensure proper DNS resolution, prompting the client to try IPv4 resolution instead.

Creating a reliable DNS infrastructure with UltraDNS.

Responding to AAAA queries is a fundamental part of our service offering, designed to ensure compatibility, future readiness, and the highest quality of service for all our subscribers. This approach is in line with industry best practices and is crucial for maintaining a robust and reliable DNS infrastructure.

To learn more about UltraDNS and how it can help you create a more reliable infrastructure, visit our product page.