DNS-resolverloggar kontra VPN-anslutningsloggar: vad var och en innehåller

En DNS-resolverlogg och en VPN-anslutningslogg är båda nätverksposter, båda användbara och inte utbytbara. Resolvern tar emot de namn den ombads svara på. VPN-ändpunkten hanterar tunnelanslutningar och registrerar vad dess implementation valde att registrera om dem. De kan ligga i samma byggnad, drivas av samma team och omfattas av samma integritetsmeddelande, och ändå beskriver de olika händelser med olika identifierare och olika bevarande. Att läsa den ena som om den vore den andra är hur utredningar hamnar snett.

Två loggar, två händelser

En resolverpost besvarar en fråga om namngivning: den här klienten bad om det här namnet vid den här tiden, och svaret var detta. En VPN-post besvarar en fråga om anslutning: den här peeren upprättade eller förlorade en tunnel, tilldelades den här adressen och överförde ungefär så mycket data innan den försvann. Ingen av dem är en registrering av vad användaren gjorde inne i en HTTPS-session, och ingen av dem ersätter den andra.

Skillnaden har en praktisk konsekvens för löften. Påståendet att en VPN-leverantör inte loggar tunnelaktivitet säger ingenting om den resolver den delar ut, och en resolvers bevarandepolicy säger ingenting om vem som anslöt till tunneln. Varje påstående tillhör sin egen operatör och sitt eget system.

Följ frågan innan du läser någon av loggarna

En fråga når bara en resolver om vägen faktiskt frågar den. En applikation kan använda operativsystemets resolver, köra sin egen krypterade DNS-klient eller läsa ett cachat svar och aldrig skicka något. Så en resolverlogg som inte visar något är inte bevis för att ett namn aldrig användes; det är bevis för att den här resolvern inte tillfrågades.

resolvectl status
dig @127.0.0.53 build.corp.example +qr
journalctl -u systemd-resolved -n 20 --no-pager

Det sista kommandot läser den lokala resolverns egen journal, vilket inte är samma sak som loggen hos servern uppströms. Om dina frågor går ut via DNS over HTTPS till en leverantör kan den lokala stubben visa ingenting medan leverantören har den fullständiga registreringen, och leverantören är en annan operatör med en annan policy.

Vad varje post kan och inte kan visa

Att koppla ihop dem är det egentliga arbetet, och att koppla ihop dem är inte alltid möjligt. En resolver som loggar klientadresser kan jämföras med en VPN som tilldelar adresser från en känd pool, och den jämförelsen ger en rimlig koppling mellan ett efterfrågat namn och en tunnel, som förblir en koppling mellan två poster och inte en post om en person.

Krypterad DNS ändrar transporten, inte synligheten vid ändpunkten. Resolvern tar fortfarande emot frågan den besvarar, som RFC 8484 gör klart, och bevarandet hos den resolvern är ett policybeslut och inte en egenskap hos protokollet.

Där delad DNS och cachar rör till historien

Flera resolvrar är normalt. En design med delad DNS skickar interna namn till en intern server och allt annat till en offentlig, så en enda utredning kan omfatta två loggar som aldrig var avsedda att kombineras och två bevarandeinställningar som aldrig var avsedda att jämföras. Att se frågor i båda är bevis för att designen fungerar, inte bevis för en läcka.

Cachar skär åt andra hållet. Ett populärt namn kan besvaras från cachen i timmar, så resolverns post visar den första frågan och sedan ingenting, medan användarens applikation fortsätter att lösa samma namn glatt. Avsaknaden av poster efter en viss tid betyder inte att ingen använde namnet efter den tiden.

Bakgrundstrafik är den tredje förvrängningen. En telefon som löser ett telemetrinamn vid start, en webbläsare som löser en domän för sökförslag och en uppdaterare som checkar in varje timme dyker alla upp i en resolverlogg bredvid namnet du faktiskt bryr dig om. Volymen i den loggen är inte uppmärksamhet, och att räkna frågor är inte att räkna besök. En resolverlogg är en registrering av frågor, och frågor är billiga att skapa.

Ställ bevarandefrågorna separat

För varje system, ställ tre frågor: vem samlar in, vad samlas in och hur länge det bevaras. Fråga sedan vem som får läsa det och enligt vilken process. RFC 8484-diskussionen om DNS over HTTPS är en bra påminnelse om att krypterad transport inte tar bort ändpunkten, och operatörens egen dokumentation är det enda tillförlitliga uttalandet om vad den ändpunkten bevarar.

När ett påstående om integritet görs om ”VPN:en”, dela upp det i komponenter innan du accepterar det: tunneloperatören, resolvern som tunneln delar ut, varje uppströms resolver som dessa frågor når, och applikationerna på enheten. Var och en har sitt eget svar, och ett påstående som är korrekt för en upprepas rutinmässigt som om det täckte alla fyra.

Använd samma uppdelning för felsökning. Fråga vilken applikation som gjorde frågan och vilken resolver som besvarade den, och titta sedan i loggen som faktiskt äger den händelsen. Att gissa från den andra loggen sparar en minut och kostar en eftermiddag.