Waarom veranderen DNS64-antwoorden zodra de VPN verbindt?

DNS64-antwoorden beschrijven een netwerkopstelling, niet een eigenschap van de server. De resolver synthetiseert een IPv6-adres uit een IPv4-adres, en het resultaat werkt alleen waar een vertaler aan het eind van dat prefix zit. Breng een VPN in het pad en die opstelling kan standhouden, veranderen of ophouden waar te zijn, afhankelijk van drie voorwaarden.

Die voorwaarden zijn de resolver die antwoordde, de route die uw apparaat naar het gesynthetiseerde prefix heeft, en of iets op die route de vertaling uitvoert. Elk ervan is waarneembaar, en dat is precies wat de storing diagnoseerbaar maakt.

Waar een gesynthetiseerd AAAA-record werkelijk naar wijst

Een DNS64-resolver beantwoordt een AAAA-query voor een naam met alleen IPv4 door het IPv4-adres in een prefix te embedden waarvoor hij geconfigureerd is, en het bekende prefix voor die taak is 64:ff9b::/96 zoals beschreven in RFC 6147. Het record ziet er voor de toepassing uit als elk ander AAAA-record, en dat is het punt: een client met alleen IPv6 kan een verbinding proberen zonder te weten dat de bestemming nooit IPv6 had. Die verbinding hangt dan af van een NAT64-functie die ergens op het pad tussen de twee families vertaalt. Zonder die vertaler is het gesynthetiseerde adres een geloofwaardig lijkende bestemming die nergens heen gaat.

Het record codificeert dus twee dingen tegelijk: het oorspronkelijke IPv4-adres en de aanname dat een vertaler bereikbaar is. Alleen het eerste is in het antwoord zelf zichtbaar.

Drie voorwaarden bepalen of het nog werkt

De eerste voorwaarde is welke resolver het record heeft gemaakt, want een zonder geconfigureerde DNS64 levert niets op voor die naam en de toepassing faalt op een andere manier. De tweede is of uw apparaat een route naar het gesynthetiseerde prefix heeft, want een antwoord kan geldig zijn terwijl de weg ernaartoe ontbreekt. De derde is of de vertaler die dat prefix bezit op het pad ligt dat u zou gebruiken, want een tunnel die 64:ff9b::/96 elders heen draagt, bereikt een andere functie of niets. Alle drie kunnen vóór de tunnel gelden en erna falen, en daarom lijkt het symptoom op een plotselinge regressie.

Controleer ze in die volgorde. Een ontbrekend antwoord en een ontbrekende route zien er in een browser identiek uit en in een resolverlog volstrekt anders.

Als de resolver verandert, verandert het antwoord

Een VPN-client duwt vaak zijn eigen resolver naar voren of neemt het hele querypad over, en die resolver synthetiseert misschien niets. Queries voor namen met alleen IPv4 geven dan geen AAAA-record terug, wat een client met alleen IPv6 ervaart als een naam die hij niet kan bereiken. Het omgekeerde gebeurt ook: een resolver die wél synthetiseert kan u een prefix geven dat uw getunnelde pad niet draagt.

Caching maakt dit moeilijker te zien. Een gesynthetiseerd record dat op het kantoornetwerk is opgehaald, kan de context overleven die het heeft gemaakt, zodat de client blijft verbinden met een adres waarvan de vertaler niet meer bereikbaar is. Kijk naar de resolver die nu antwoordt en niet naar degene die antwoordde toen de invoer werd opgeslagen. De cache leegmaken zonder het oude en het nieuwe antwoord vast te leggen, vernietigt het bewijs dat u nodig hebt.

Test de opzoeking en het pad apart

Vraag de naam rechtstreeks op voordat u de toepassing erbij haalt, en noteer welke server antwoordde. De opdrachten hieronder tonen het AAAA-record, de gebruikte resolver en of er een route naar het gesynthetiseerde prefix bestaat. Voer ze uit met de tunnel omlaag en daarna opnieuw met de tunnel omhoog.

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/

Lees de resultaten als een keten. Een ontbrekend AAAA-record betekent dat de resolver voor u niet synthetiseert, dus een pad met alleen IPv6 werkt niet voor die naam, wat de client ook doet. Een record aanwezig zonder route betekent dat het prefix niet door het huidige pad wordt gedragen, en dat is een routeringsbeslissing en geen resolverfout. Een route aanwezig terwijl het verzoek nog steeds faalt, wijst op de vertaler zelf, en dat hoort bij een andere eigenaar.

Noteer de resolver, de netwerkcontext en de adresfamilie naast elk resultaat. Die notitie is wat de volgende vergelijking een resolverwissel van een routeringswissel laat scheiden.