| Internet-Draft | AAAA filtering considerations | June 2025 |
| Caletka | Expires 26 December 2025 | [Page] |
Since IPv4 and IPv6 addresses are represented by different resource records in the DNS, operating systems capable of running both IPv4 and IPv6 need to make two queries when resolving a host name. This document discusses conditions, under which the 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/.¶
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 26 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 IPv6 and 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 IPv4 address, one for a AAAA record representing 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 need to be sent: there is no point of sending out AAAA record query if the host has no IPv6 connectivity or sending out A query if the host has no IPv4 connectivity. Such an optimization however has to consider any possible mean of obtaining connectivity for 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 address family, stub resolver follows this algorithm for each address family supported by the operating system:¶
Read routing table of the address family.¶
Remove all routes towards Link-Local destinations from the routing table, ie. remove addresses from Section 2.5.6 of [RFC4291] for IPv6 routing table and remove addresses from [RFC3927] for IPv4 routing table.¶
If the routing table is not empty, send the corresponding name query to the DNS: AAAA query for IPv6, A query for IPv4.¶
It is necessary to consider ANY route towards non Link-Local address space and not just default route and/or default network interface. Such a detection would cause issues with Split-mode VPNs providing only particular routes for the resources reachable via VPN.¶
If the host does not have a 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 applications, since [RFC6724] requires applications to try connecting to all addresses received from the stub resolver.¶
However, in order to minimize 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 a 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 fall through the list of addresses to 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 networks, this might overload parts of the DNS infrastructure, since the number of queries doubles.¶
Reducing the number of queries allows an attacker observing the DNS traffic to figure out which address families the host uses.¶
Sudden disabling of the optimization can overload parts of the DNS infrastructure due to doubling the number of queries.¶
This document has no IANA actions.¶
TODO acknowledge.¶