DNSSEC eller VPN: vilken döljer dina DNS-frågor?

Två mekanismer får samma uppgift och ingen av dem utför den. DNSSEC svarar på om data du tog emot verkligen kom från den zon som publicerar dem, och en VPN avgör vilken väg dina paket tar. Ingen av dem döljer i alla fall namnet du frågade efter, och inställningarna som ser ut att borde göra det handlar oftast om transport eller routing och inte om validering. Om du namnger lagret först blir en vag integritetsfråga en konkret fråga.

Tre påståenden som smälter samman till ett

Autenticitet är påståendet att svaret är det zonen publicerade och att det inte ändrades på vägen. Konfidentialitet är påståendet att ingen på vägen kan läsa frågan eller svaret. Routing är påståendet att paketen följer en väg du valde, och det är precis vad en tunnel ger.

DNSSEC behandlar det första och säger inget om de andra två. DoT och DoH behandlar det andra för hoppet till resolvern. En VPN behandlar det tredje och kan också påverka det andra, men bara som en bieffekt av var trafiken tar vägen.

Applikationstrafik är ett fjärde fall: HTTPS skyddar och autentiserar webbutbytet mellan din klient och webbplatsen, och inget DNS-lager ersätter det.

Vad signaturvalidering kan och inte kan

En validerande resolver kontrollerar signaturkedjan från zonen upp till ett konfigurerat förtroendeankare och returnerar sedan ett svar med flaggan för autentiserade data satt när kontrollen lyckas. Den flaggan är bevis om data, inte om anslutningen eller destinationens avsikter.

Det kan inte hindra en legitim zonägare från att publicera autentiska poster för en tjänst du inte borde lita på. Ett korrekt signerat svar från en komprometterad domän är fortfarande korrekt signerat, och DNSSEC har ingen åsikt om huruvida den domänen förtjänar dina inloggningsuppgifter.

Det döljer inte heller något. Frågan och svaret korsar nätverket i en form som en resolver och varje observatör på den vägen kan läsa, om inte ett annat lager skyddar transporten. Ett signerat svar och ett privat svar är olika egenskaper, och en driftsättning kan ha var och en för sig. Testa båda om någon av dem spelar roll för dig.

Var konfidentialiteten faktiskt kommer ifrån

Krypterad resolvertransport packar in DNS-utbytet i TLS, så resolvern ser fortfarande frågan men vägen mellan dig och den inte. Det förflyttar förtroende i stället för att ta bort det: du litar mer på resolvern och mindre på det lokala nätverket.

En VPN kan föra frågor till en resolver på andra sidan, vilket ändrar både vägen och resolvern som ser dem. Det är ett routingbeslut med en integritetskonsekvens, och i ett hanterat nätverk kan den interna resolvern vara den enda som kan svara på interna namn.

Kombinationen folk faktiskt vill ha är oftast tre saker samtidigt: validering på, krypterad transport till en resolver de valde och applikations-TLS på destinationen. Var och en är oberoende, och hoppar man över en lämnas ett annat hål.

Kontrollera validering och transport var för sig

Två tester löser det mesta av förvirringen. Det första frågar om resolvern validerade svaret, det andra om transporten var skyddad. De misslyckas på olika sätt och ingen av dem förutsätter den andra.

De här kommandona skriver ut flaggorna från en validerande fråga, upprepar frågan med kontrollen avstängd och kör lokal validering med delv:

dig +dnssec example.com | grep flags
dig +cd example.com | grep status
delv example.com

Ett svar med flaggan för autentiserade data och en närvarande signatur visar validering hos den resolvern. Ett valideringsfel med delv visar en bruten kedja någonstans mellan zonen och förtroendeankaret, vilket är ett publiceringsproblem och inte ett tunnelproblem. En tidsgräns helt utan flaggor är ett transport- eller nåbarhetsproblem, och att behandla det som ett signaturfel skickar dig till fel lager.

Vad du bör göra när en VPN förstör slagningar

Om slagningar fungerade före tunneln och slutar efter den, jämför resolvern som varje väg använder. Delad tunnling, en intern resolver som bara nås genom tunneln, och en klient som skriver över resolverinställningar ändrar alla svaret utan att röra DNSSEC.

Att stänga av validering globalt är fel första steg, eftersom det tar bort den enda mekanism som rapporterar manipulation och inte reparerar en resolver som inte går att nå. Begränsa felet först: uppslagning, transport, validering och sedan policy. Bara det tredje hör till DNSSEC, och bara det andra hör till krypterad transport.