DNS över TLS plus en VPN: vilken del är skyddad

DNS över TLS krypterar utbytet mellan en klient och resolvern den valde, och resolvern läser fortfarande namnet. Den meningen avgör det mesta av förvirringen kring DoT plus en VPN. Tunneln bestämmer vilken väg den krypterade frågan tar, medan resolvern fortfarande får veta vad som frågades. Ingen av mekanismerna ersätter den andra, och ingen gör den andra överflödig.

Fyra kontroller avgör om upplägget du har är det du tror att du har.

Kontroll 1: vad krypteringen täcker

DoT packar in DNS-utbytet i TLS, så en observatör på vägen ser en anslutning till en adress och port i stället för ett namn i en fråga. Resolvern själv dekrypterar och svarar. Jämför med DNS över HTTPS: båda krypterar, och de använder olika transportmedel, så ett nätverk som tillåter webbtrafik tillåter inte automatiskt en DoT-anslutning.

Den skillnaden spelar roll när en captive portal eller en filtrerande mellanbox tillåter 443 och blockerar 853. Verktyget som fungerade där är inget bevis för att det andra kommer att göra det.

Kontroll 2: vilken väg frågan tar

Vägen är en fråga om klientpolicy. En DoT-resolver kan nås genom tunneln, utanför den eller via en väg som ändras med nätverket. Vilket som sker beror på vägarna och på om klienten skyddar sin egen DNS-socket. En tunnel som fångar all trafik tar vanligtvis frågan med sig, vad resolveradressen än säger.

Att se en tredjeparts resolveradress i ett test bevisar inte en kringgång, och att se kryptering bevisar inte den avsedda mottagaren. Läs resolvern och vägen var för sig och avgör sedan om paret är det du designade.

Kontroll 3: interna namn

En organisation som publicerar interna namn behöver en resolver som håller de posterna. En offentlig DoT-tjänst känner inte till ditt privata namnutrymme, och att peka klienten mot en sådan garanterar att de namnen misslyckas. Detta är den vanligaste praktiska regressionen när någon slår på krypterad DNS på en hanterad enhet.

Behåll den interna resolvern för interna suffix och kryptera det hoppet om policyn kräver det, i stället för att ersätta den med en offentlig leverantör.

Kontroll 4: beteende vid fel

En strikt resolverinställning utan en nåbar resolver ger ett namnupplösningsfel medan tunneln står kvar. Titta på plattformsläget och dess dokumenterade återfall i stället för att röra nycklar eller certifikat.

Ett återfall som tyst använder vanlig DNS är ett policybeslut, inte en bekvämlighet. Bestäm om felet ska vara synligt eller ska degraderas till något svagare, och skriv ner svaret.

Lita på certifikatet, inte på svaret

Använd leverantörens värdnamn och den verifieringskonfiguration som är dokumenterad för tjänsten. Att stänga av TLS-kontroller så att en okänd resolver svarar ger dig en krypterad kanal till en overifierad slutpunkt, vilket är sämre än den vanliga fråga den ersatte på ett bestämt sätt: det ser säkert ut. Specifikationen för DNS över TLS redogör för autentiseringsförväntningen bakom den kontrollen.

Ett svar från en resolver du inte kan autentisera är ett påstående, inte ett resultat.

Vad detta lämnar oförklarat

DoT döljer inte namnet för resolvern, döljer inte anslutningens destinationsadress för nätverket och avgör inte om frågan gick genom tunneln. Det är tre separata frågor med tre separata svar.

Skriv ner resolveridentiteten, transitvägen och policyn för interna namn som tre rader. Nästa DNS-fråga du får blir en av dem.