Happy Eyeballs non è un record DNS, non è HTTP/3 e non è il CNAME all’apice. È un modo di aprire la connessione quando un nome risolve in più indirizzi. Lo standard è l’RFC 8305, dicembre 2017, che rende obsoleto l’RFC 6555. Rilettura del testo il 18 ottobre 2026.
In breve: non si parte in parallelo su tutti gli IP. Si tenta un indirizzo, poi il successivo dopo un ritardo. Il valore consigliato di quel ritardo è 250 millisecondi. Il minimo consigliato è 100 millisecondi, e un tentativo successivo non deve partire entro 10 millisecondi dal precedente. Il massimo consigliato è 2 secondi. Se IPv6 è rotto e IPv4 risponde, l’utente può non accorgersene: l’RFC lo scrive come limite, non come pregio.
Cosa specifica l’RFC 8305
L’algoritmo si chiama, nel documento, «Happy Eyeballs Connection Setup». Quattro fasi, sezione 2: query DNS asincrone; ordinamento degli indirizzi; tentativi di connessione asincroni; una connessione che riesce e che dovrebbe cancellare le altre. Il documento assume che la policy dell’host preferisca IPv6 a IPv4. Se l’host è configurato al contrario, le stesse raccomandazioni si adattano. Non è un bit da accendere nel DNS. Il cluster è Infrastruttura. Un record CAA resta un’altra riga, in un’altra RFC.
Sezione 5: i tentativi non vanno fatti tutti insieme, per non caricare la rete. Si parte da un solo indirizzo. Partire il successivo non chiude il precedente: per un po’ i tentativi convivono. Quando uno completa in genere l’handshake TCP, gli altri che non sono ancora riusciti vanno annullati (SHOULD). Gli indirizzi non ancora provati si ignorano. La query DNS asincrona si può annullare, ma il resolver dovrebbe ancora accettare risposte per circa un secondo, così riempie la cache.
Sezione 9.2: se il DNS restituisce più indirizzi di server applicativi diversi, non è detto che TLS o HTTP funzionino su tutti. La corsa della connessione non controlla l’applicazione.
250 millisecondi non sono un timeout da manuale
| Parametro, sezione 5 | Valore nell’RFC 8305 |
|---|---|
| Connection Attempt Delay, default consigliato | 250 millisecondi |
| Minimo consigliato | 100 millisecondi |
| Divieto | Un tentativo successivo non deve partire entro 10 millisecondi dal precedente |
| Massimo consigliato | 2 secondi |
| Implementazione più fine | Circa il tempo del secondo SYN TCP, timer dell’RFC 6298, non i ritrasmessi successivi con backoff |
Un’implementazione può usare l’RTT già misurato verso lo stesso host o prefisso. Il ritardo resta un intervallo tra un tentativo e il prossimo, non l’attesa massima di una pagina. Il 18 ottobre 2026 non ho misurato il ritardo di un browser preciso: riporto il numero dello standard, non un benchmark.
Il TTL che scade non cancella il tentativo già partito
Sezione 6. Se durante la connessione il DNS toglie un indirizzo, per esempio perché il TTL è scaduto, e il tentativo su quell’indirizzo è già partito, il tentativo non dovrebbe essere cancellato. Se l’indirizzo non era ancora stato provato, va tolto dalla lista. Se ne arriva uno nuovo, va inserito nell’ordine. Happy Eyeballs non è la scadenza del record, e non è un failover che aspetta il timeout intero del sistema operativo prima di guardare l’altra famiglia.
Può nascondere un IPv6 rotto
Sezione 9.3, titolo «Hiding Operational Issues». In pratica Happy Eyeballs può nascondere guasti di rete. Esempio dello stesso testo: una misconfigurazione fa fallire sempre IPv6 mentre IPv4 funziona, e l’algoritmo può ridurre la capacità dell’operatore di accorgersene. La raccomandazione è un monitoraggio esterno su tutte le famiglie di indirizzi. Non è un motivo per spegnere IPv6. È un motivo per non usare «il sito si apre» come prova che l’AAAA è sano.
Sezione 10: l’applicazione non deve appoggiarsi a una mappa stabile nome-indirizzo per una proprietà di sicurezza, perché il DNS può cambiare tra una query e l’altra. Happy Eyeballs rende più probabile che due connessioni successive allo stesso nome usino IP diversi.
Errori da evitare
Chiamarlo un record DNS o un header HTTP. Non sta né nell’uno né nell’altro.
Confonderlo con HTTP/3. Quello è un altro protocollo, su QUIC, già trattato a parte.
Pensare che partano dieci socket insieme. L’RFC chiede di non farlo.
Usare 250 millisecondi come timeout dell’intera pagina. È il ritardo prima del tentativo successivo.
Scendere sotto i 10 millisecondi tra un tentativo e il successivo. È un MUST NOT.
Dedurre che IPv6 funziona perché la home si è aperta. La sezione 9.3 dice il contrario possibile.
In sintesi
Un indirizzo alla volta, il successivo dopo un ritardo. Consigliato 250 millisecondi, non meno di 100, mai entro 10, tetto consigliato 2 secondi. La policy assunta preferisce IPv6, ma il documento si adatta se l’host preferisce IPv4. Il successo di una connessione dovrebbe chiudere le altre. Un AAAA rotto può restare invisibile a chi guarda solo la pagina. Non è un CNAME e non è HTTP/3.
Foto di copertina: Raimond Spekking, «CAT8 Ethernet Cable», Wikimedia Commons, CC BY-SA 4.0. È un cavo, non un diagramma dell’handshake.
