Perché le risposte DNS64 cambiano appena si connette la VPN?

Le risposte DNS64 descrivono una disposizione di rete, non una proprietà del server. Il resolver sintetizza un indirizzo IPv6 da un IPv4, e il risultato funziona solo dove un traduttore si trova alla fine di quel prefisso. Portate una VPN nel percorso e quella disposizione può reggere, cambiare o smettere di essere vera a seconda di tre condizioni.

Queste condizioni sono il resolver che ha risposto, la rotta che il dispositivo ha verso il prefisso sintetizzato e se qualcosa su quella rotta esegue la traduzione. Ognuna è osservabile, ed è ciò che rende diagnosticabile il guasto.

A cosa punta davvero un record AAAA sintetizzato

Un resolver DNS64 risponde a una query AAAA per un nome solo IPv4 incorporando l'indirizzo IPv4 dentro un prefisso configurato per l'uso, e il prefisso noto per questo compito è 64:ff9b::/96 come descritto in RFC 6147. Il record appare all'applicazione come qualsiasi altro record AAAA, e questo è il punto: un client solo IPv6 può tentare una connessione senza sapere che la destinazione non ha mai avuto IPv6. Quella connessione dipende poi da una funzione NAT64 che traduce tra le due famiglie da qualche parte lungo il percorso. Senza quel traduttore, l'indirizzo sintetizzato è una destinazione dall'aspetto plausibile che non porta da nessuna parte.

Il record quindi codifica due cose insieme: l'indirizzo IPv4 originale e l'ipotesi che un traduttore sia raggiungibile. Solo la prima è visibile nella risposta stessa.

Tre condizioni decidono se funziona ancora

La prima condizione è quale resolver ha prodotto il record, perché uno senza DNS64 configurato non restituisce nulla per quel nome e l'applicazione fallisce in un altro modo. La seconda è se il dispositivo ha una rotta verso il prefisso sintetizzato, perché una risposta può essere valida mentre manca il percorso verso di essa. La terza è se il traduttore che possiede quel prefisso è sul percorso che usereste, perché un tunnel che porta 64:ff9b::/96 altrove raggiunge un'altra funzione o nulla. Tutte e tre possono valere prima del tunnel e fallire dopo, ed è per questo che il sintomo sembra una regressione improvvisa.

Controllatele in questo ordine. Una risposta mancante e una rotta mancante sembrano identiche in un browser e del tutto diverse in un log del resolver.

Quando cambia il resolver, cambia la risposta

Un client VPN spesso impone il proprio resolver o prende il controllo dell'intero percorso della query, e quel resolver può non sintetizzare nulla. Le query per nomi solo IPv4 allora non restituiscono alcun record AAAA, cosa che un client solo IPv6 vive come un nome irraggiungibile. Accade anche il contrario: un resolver che sintetizza davvero può darvi un prefisso che il vostro percorso in tunnel non trasporta.

La cache rende tutto questo più difficile da vedere. Un record sintetizzato ottenuto sulla rete dell'ufficio può sopravvivere al contesto che l'ha prodotto, così il client continua a connettersi a un indirizzo il cui traduttore non è più raggiungibile. Guardate il resolver che risponde ora e non quello che ha risposto quando la voce è stata salvata. Svuotare la cache senza annotare la risposta vecchia e quella nuova distrugge la prova che vi serve.

Provate la ricerca e il percorso separatamente

Interrogate il nome direttamente prima di coinvolgere l'applicazione, e annotate quale server ha risposto. I comandi qui sotto mostrano il record AAAA, il resolver in uso e se esiste una rotta verso il prefisso sintetizzato. Eseguiteli con il tunnel abbassato e poi di nuovo con il tunnel alzato.

dig AAAA ipv4only.example.com +short
dig AAAA ipv4only.example.com | grep -E '^;; SERVER'
ip -6 route get 64:ff9b::c000:0216
curl -6 -sS -o /dev/null -w '%{http_code} %{time_connect}\n' --max-time 8 http://ipv4only.example.com/

Leggete i risultati come una catena. Un record AAAA mancante significa che il resolver davanti a voi non sintetizza, quindi un percorso solo IPv6 non funzionerà per quel nome, qualunque cosa faccia il client. Un record presente senza rotta significa che il prefisso non è trasportato dal percorso attuale, e quella è una decisione di instradamento e non un guasto del resolver. Una rotta presente mentre la richiesta fallisce ancora punta al traduttore stesso, e quello appartiene a un altro proprietario.

Annotate il resolver, il contesto di rete e la famiglia di indirizzi accanto a ogni risultato. È quella nota che permette al confronto successivo di separare un cambio di resolver da un cambio di instradamento.