Varför en DNS-landsetikett inte bevisar en VPN-läcka

Utländskt utseende resolveradresser dyker ständigt upp i DNS-testresultat, och slutsatsen folk drar är alltid densamma: frågorna måste ha sluppit ut ur tunneln. Ibland gjorde de det. Oftare beskriver rapporten vilken rekursiv tjänst som svarade och var en databas tycker att adressen ligger, och det är ett påstående om infrastruktur, inte om dina paket. Att skilja iakttagelsen från slutsatsen kräver tre fakta: vem som svarade, hur namnet reste och vilken policy du faktiskt konfigurerade.

Läs vad testet faktiskt observerade

De flesta testsidor fungerar på samma sätt: de ber klienten slå upp ett unikt värdnamn och tittar sedan på vilken resolver som hämtade det, eller så skickar de bara tillbaka resolveradressen som klienten rapporterar. Det identifierar en rekursiv tjänst och, om frågan bar klientens subnätinformation, en grov nätverksposition. Det bevisar inte att frågan lämnade enheten utanför tunneln, och bevisar absolut inte att samma väg användes för varje namn. En enda iakttagelse av en enda sökning generaliseras till ett påstående om all trafik.

Ett test som visar resolveradressen är mer användbart än ett landsmärke, eftersom adressen kan jämföras med den resolverlista som klienten faktiskt fick.

Anycast och vidarebefordran förklarar de flesta överraskningarna

Stora offentliga resolvers annonserar samma adress från många platser, och nätverket dirigerar varje fråga till den plats som ligger närmast i routingtermer. En geolokaliseringsdatabas kopplar sedan adressen till en enda plats, som kan vara en företagsregistreringsadress på en annan kontinent eller ett datacenter som inte är det som svarar. RFC 4786 täcker operativ praxis för anycast-tjänster och svårigheten att koppla en sådan adress till en enda fysisk plats. Kartan är en förenkling av ett routingbeslut, och den förenklar i den riktning som ger alarmerande resultat.

Vidarebefordran lägger till ett andra lager. En lokal stub-resolver, en router eller en ISP-resolver kan skicka frågor vidare till en tjänst högre upp, och namnet som visas i testet speglar den sista operatören i kedjan snarare än den första. Klientens subnätsutvidgningar kan göra ett svar ovanifrån anpassat till ditt nätverk samtidigt som den rapporterade platsen ser ut som en plats du aldrig besökt.

En konfigurerad resolver kan därför vara korrekt och ändå ge ett utländskt utseende resultat, och en resolver i ditt eget land kan vara den felaktiga eftersom den tillhör en part du inte valde.

Vem tog emot namnet, och via vilken rutt

Två frågor besvarar den praktiska delen: vilken server klienten använder, och om den servern nås genom tunneln. Jämför resolverlistan med adressen i testresultatet innan du drar slutsatser om routing, och kontrollera sedan att frågan till den adressen går ut genom tunnelgränssnittet. Om de två adresserna skiljer sig är det intressanta fyndet att något skrev om eller kringgick den avsedda resolvern, och det förtjänar en närmare titt än landnamnet.

resolvectl query example.com
resolvectl status | grep -A3 'DNS Servers'
dig +short TXT whoami.akamai.net

Det första kommandot visar vilken server som svarade för ett namn, det andra visar den konfigurerade listan och dess omfång, och det tredje rapporterar resolveradressen så som en offentlig tjänst ser den. När alla tre stämmer gör policyn det den konfigurerades för, vad landsetiketten än säger.

Jämför med policyn du valde

En VPN som tvingar fram en resolver, en webbläsare konfigurerad att använda sin egen krypterade DNS och ett operativsystem som föredrar inställningarna för ett gränssnitt kan var för sig vara korrekta medan de tillsammans motsäger varandra. Moderna webbläsare kan skicka frågor över krypterad transport till en leverantör som valts i webbläsaren, vilket medvetet kringgår systemets resolverlista. Det är inte en läcka i betydelsen bruten tunnel; det är en policy vald någon annanstans, och att ta reda på var den valdes är den egentliga uppgiften.

Arbetsenheter lägger till domänspecifika regler: interna namn måste gå till organisationens resolver, medan allt annat följer standardvärdet. Att ersätta den ordningen eftersom en testsida visade ett oväntat land är hur interna namn slutar slås upp för ett helt team.

Håll testerna smala och säkra

Att fråga en offentlig testtjänst om ett internt värdnamn avslöjar namnet för en part som inte har något med det att göra, och svaret säger dig inget som en lokal läsning av resolverlistan inte skulle säga.

Använd i stället namn som avslöjar infrastruktur, registrera resolveradressen, omfånget och det gränssnitt som användes, och jämför den registreringen med den dokumenterade avsikten. En kartetikett är sammanhang för ett samtal snarare än ett godkänt eller underkänt resultat, och att behandla den som en dom skapar konfigurationsändringar i stället för diagnos.