| Internet-Draft | AAAA filtering considerations | July 2025 |
| Caletka | Expires 7 January 2026 | [Page] |
Since IPv4 and IPv6 addresses are represented by different resource records in the Domain Name System, operating systems capable of running both IPv4 and IPv6 need to execute two queries when resolving a host name. This document discusses the conditions under which a stub resolver can optimize the process by not sending one of the queries if the host is connected to a single-stack network.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://oskar456.github.io/ietf-aaaa-filtering/draft-caletka-aaaa-filtering.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-caletka-aaaa-filtering/.¶
Discussion of this document takes place on the v6ops Working Group mailing list (mailto:v6ops@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/v6ops/. Subscribe at https://www.ietf.org/mailman/listinfo/v6ops/.¶
Source for this draft and an issue tracker can be found at https://github.com/oskar456/ietf-aaaa-filtering.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 7 January 2026.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Most operating systems support both the IPv6 and the IPv4 networking stack. When such a host is connected to a dual-stack network, whenever a process requests resolution of a DNS name, two DNS queries need to be issued - one for an A record representing an IPv4 address, and one for a AAAA record representing an IPv6 address. The results of such queries are then merged and ordered based on [RFC6724] or used as input for the Happy Eyeballs algorithm [RFC8305].¶
When such a host is connected to a single-stack network, only one DNS query needs to be performed: there is no reason for querying for a AAAA record if the host has no IPv6 connectivity, the same way there is no reason to look for an A record if the host has no IPv4 connectivity. Such an optimization however has to consider any possible means of obtaining connectivity for a particular address family, including but not limited to IPv6 Transition Mechanisms or VPNs.¶
Please note that Multicast DNS [RFC6762] or similar link-local name resolution protocols are not considered in scope of this document.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Whenever an application asks the stub resolver to resolve a domain name without specifying the address family, the stub resolver follows one of the algorithms specified below:¶
This algorithm assumes that the host has connectivity of particular address family if there is at least one route to a destination that is not in Link-Local address space. If there are only routes for destinations in the Link-Local address space, the host is not able to send any packets towards any destination address that could be possibly obtained from the DNS. Therefore, sending an address query for that particular address family is unnecessary.¶
For each address family supported by the operating system:¶
As an alternative to analyzing the routing tables, the stub resolver might
choose to determine the connectivity by looking at the addresses configured on
all network interfaces. This is similar to an application using the flag
AI_ADDRCONFIG when interacting with the stub resolver using getaddrinfo()
function [GAI].¶
For each address family supported by the operating system:¶
When detecting the connectivity presence, it is necessary to consider ANY routes towards non Link-Local address space and/or IP addresses on ALL interfaces and not just the default route and/or just the default network interface. The implementations SHOULD NOT try to determine connectivity by hardcoding a particular publicly reachable IP address [CHROME].¶
Improper detection can cause issues for:¶
If the host does not have full connectivity for both address families (there are no default gateways for both IPv4 and IPv6), it is possible that the IP(v6) address obtained from the DNS falls into the address space not covered by a route. This should not be problem for a properly written application, since [RFC6724] requires applications to try connecting to all addresses received from the stub resolver.¶
However, in order to minimize the impact on poorly designed applications, the stub resolver MAY remove addresses not covered by an entry in the routing table from the list of DNS query results sent to the application.¶
As an extension to the filtering of DNS results, the stub resolver MAY also remove IPv4-mapped IPv6 addresses (Section 2.5.5.2 of [RFC4291]) from the list of DNS query results sent to the application.¶
IPv4-mapped IPv6 addresses are not valid destination addresses [IANA], therefore they should never appear in AAAA records. Sending IPv4-mapped IPv6 address to the application might cause address family confusion for applications using IPv4 compatibility of IPv6 sockets [RFC3493].¶
The optimization described above is OPTIONAL. A stub resolver of a dual-stack capable host can always issue both A and AAAA queries to the DNS, merge and order the results and send them to the application even if it has only single-stack connectivity. Sending packets to a destination not covered by an entry in the routing table will be immediately refused, so a properly written application will quickly iterate through the list of addresses and finally select the one using the same address family as the connectivity of the host.¶
However, it should be noted that such behavior increases load on the DNS system. If such an optimization is removed (for instance by a software update) on a large single-stack network, this might overload parts of the DNS infrastructure, since the number of queries will double.¶
Reducing the number of queries allows an attacker observing the DNS traffic to figure out which address families the host uses.¶
Suddendly disabling the optimization can overload parts of the DNS infrastructure due to doubling the number of queries.¶
This document has no IANA actions.¶
TODO acknowledge.¶