Resolve addresses without waiting for every answer
01DNS discovery and connection establishment overlap so one slow answer need not block usable candidates.
After the chosen waiting interval, begin with available IPv4 candidates. A later positive AAAA may join the remaining list before a winner, subject to normal pacing.
Source for this drawing: RFC 8305 · Read RFC section 3 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
DNS record type and the IP transport to the DNS server are different choices.
- Happy Eyeballs is a name for reducing user-visible connection delay, not an acronym. A hostname can resolve to IPv6 addresses in AAAA records and IPv4 addresses in A records. RFC8305 coordinates asynchronous queries, destination ordering and staggered connection attempts, generally preferring IPv6. A different configured host preference can adapt this policy (§§1–2).
- For a dual-stack client with IPv4 and IPv6 connectivity, AAAA and A queries SHOULD be sent as soon after one another as possible, AAAA first and A immediately after. Resolution SHOULD be asynchronous; implementations SHOULD NOT wait for both families before connecting. Separate threads can simulate asynchronous queries if needed (§3).
- If a positive AAAA response arrives first, start the first IPv6 attempt immediately. If a positive A response arrives first, the client SHOULD wait briefly for AAAA. The recommended Resolution Delay is50ms. A positive AAAA answer within that delay starts IPv6; a negative AAAA response meaning no error/no data, or expiry of the delay without AAAA, SHOULD allow the available IPv4 candidates to proceed (§3). Errors are not silently renamed no-data.
- The example A answer arrives at20ms, so its chosen50ms waiting window ends at70ms. AAAA at40ms starts IPv6 at40; no AAAA by70 starts IPv4 at70. A no-data AAAA at35 would allow IPv4 at35. Equal-time response-versus-deadline handling in the helper processes the response first as an explicit example convention, not a new RFC requirement (§3).
- For multiple configured DNS-server addresses, queries SHOULD use an IPv6 server address first; an unresponsive address may be penalized and another used. This concerns transport to the resolver: either A or AAAA queries can be carried over either IP family. Clients SHOULD NOT impose an explicit configured-server limit; if hardware requires one, they SHOULD include at least one server address from each available family (§3.1).
Fictional offline examples. The default policy here prefers IPv6. V6-A/B/C and V4-A/B name distinct candidate destinations, not protocol fields. Helpers model selected decisions from already ranked addresses; they are not full DNS, RFC6724/source selection, TCP, TLS, NAT64 discovery or a network implementation. Times and equality ordering are stated example choices.
Read the RFC section ↗