3. Gestione delle Query di Risoluzione dei Nomi Host (Hostname Resolution Query Handling)
Quando un client ha sia connettività IPv4 che IPv6 e sta tentando di stabilire una connessione con un host denominato, deve inviare sia query DNS AAAA che A. Entrambe le query SHOULD essere effettuate il più rapidamente possibile l'una dopo l'altra, con la query AAAA effettuata per prima e immediatamente seguita dalla query A.
Le implementazioni SHOULD NOT attendere che entrambe le famiglie di risposte vengano restituite prima di tentare lo stabilimento della connessione. Se una query non riesce a restituire risultati o impiega molto più tempo a restituirli, attendere la seconda famiglia di indirizzi può ritardare significativamente lo stabilimento della connessione della prima. Pertanto, il client SHOULD trattare la risoluzione DNS come asincrona. Si noti che se la piattaforma non offre un'API DNS asincrona, questo comportamento può essere simulato effettuando due query sincrone separate su thread diversi, una per famiglia di indirizzi.
L'algoritmo procede come segue: se viene ricevuta per prima una risposta AAAA positiva (una risposta con almeno un record AAAA valido), il primo tentativo di connessione IPv6 viene immediatamente avviato. Se viene ricevuta per prima una risposta A positiva a causa di un riordinamento, il client SHOULD attendere un breve periodo per la risposta AAAA per garantire che venga data preferenza a IPv6 (è comune che la risposta AAAA segua la risposta A di pochi millisecondi). Questo ritardo sarà denominato "Resolution Delay" (Ritardo di Risoluzione). Il valore raccomandato per il ritardo di risoluzione è di 50 millisecondi. Se viene ricevuta una risposta AAAA positiva entro il periodo del ritardo di risoluzione, il client avvia immediatamente il tentativo di connessione IPv6. Se viene ricevuta una risposta AAAA negativa (nessun errore, nessun dato) entro il periodo del ritardo di risoluzione o la risposta AAAA non è stata ricevuta entro la fine del periodo del ritardo di risoluzione, il client SHOULD procedere all'ordinamento degli indirizzi (vedere Sezione 4) e ai tentativi di connessione scaglionati (vedere Sezione 5) utilizzando qualsiasi indirizzo IPv4 restituito finora. Se la risposta AAAA arriva mentre questi tentativi di connessione sono in corso ma prima che sia stata stabilita una connessione, allora gli indirizzi IPv6 appena ricevuti vengono incorporati nell'elenco degli indirizzi candidati disponibili (vedere Sezione 6) e il processo di tentativi di connessione continuerà con gli indirizzi IPv6 aggiunti, fino a quando non viene stabilita una connessione.
3.1. Gestione di Più Indirizzi di Server DNS (Handling Multiple DNS Server Addresses)
Se sono configurati più indirizzi di server DNS per la rete corrente, il client può avere l'opzione di inviare le proprie query DNS tramite IPv4 o IPv6. In conformità con l'approccio Happy Eyeballs, le query SHOULD essere inviate prima tramite IPv6 (si noti che questo non si riferisce all'invio di query AAAA o A, ma piuttosto all'indirizzo del server DNS stesso e alla versione IP utilizzata per trasportare i messaggi DNS). Se le query DNS inviate all'indirizzo IPv6 non ricevono risposte, quell'indirizzo può essere contrassegnato come penalizzato e le query possono essere inviate ad altri indirizzi di server DNS.
Man mano che le distribuzioni IPv6 native diventano più prevalenti e gli indirizzi IPv4 si esauriscono, ci si aspetta che la connettività IPv6 riceva un trattamento preferenziale all'interno delle reti. Se un server DNS è configurato per essere accessibile tramite IPv6, IPv6 dovrebbe essere presunto come la famiglia di indirizzi preferita.
I sistemi client SHOULD NOT avere un limite esplicito al numero di server DNS che possono essere configurati, sia manualmente che dalla rete. Se tale limite è richiesto da limitazioni hardware, il client SHOULD utilizzare almeno un indirizzo da ciascuna famiglia di indirizzi dall'elenco disponibile.