| Internet-Draft | AAAA filtering considerations | June 2025 |
| Caletka | Expires 28 December 2025 | [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 28 December 2025.¶
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 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.¶
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 this algorithm for each address family supported by the operating system:¶
Read the routing table of the address family;¶
Remove all the routes towards Link-Local destinations from the routing table, ie. remove addresses from Section 2.5.6 of [RFC4291] for the IPv6 routing table and remove addresses from [RFC3927] for the IPv4 routing table;¶
If the routing table is not empty, send the corresponding name query to the DNS:¶
It is necessary to consider ANY routes towards non Link-Local address space and not just the default route and/or the default network interface. Such a detection would cause issues with Split-mode VPNs providing only particular routes for the resources reachable via the VPN.¶
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.¶