DNS-resolverlogger kontra VPN-tilkoblingslogger: hva hver av dem inneholder

En DNS-resolverlogg og en VPN-tilkoblingslogg er begge nettverksregistreringer, begge nyttige og ikke utbyttbare. Resolveren mottar navn den ble bedt om å svare på. VPN-endepunktet håndterer tunneltilkoblinger og registrerer det implementasjonen valgte å registrere om dem. De kan ligge i samme bygning, driftes av samme team og omfattes av samme personvernerklæring, og likevel beskriver de forskjellige hendelser med forskjellige identifikatorer og forskjellig oppbevaring. Å lese den ene som om den var den andre er hvordan undersøkelser går galt.

To logger, to hendelser

En resolveroppføring besvarer et spørsmål om navngiving: denne klienten ba om dette navnet på dette tidspunktet, og svaret var dette. En VPN-oppføring besvarer et spørsmål om tilkobling: denne peeren etablerte eller mistet en tunnel, fikk tildelt denne adressen, og overførte omtrent så mye data før den forsvant. Ingen av dem er en registrering av hva brukeren gjorde inne i en HTTPS-økt, og ingen av dem erstatter den andre.

Forskjellen har en praktisk konsekvens for løfter. Utsagnet om at en VPN-leverandør ikke logger tunnelaktivitet sier ingenting om resolveren den deler ut, og en resolvers oppbevaringspolicy sier ingenting om hvem som koblet seg til tunnelen. Hvert utsagn tilhører sin egen operatør og sitt eget system.

Følg spørringen før du leser noen av loggene

En spørring når bare en resolver hvis banen faktisk spør den. En applikasjon kan bruke operativsystemets resolver, kjøre sin egen krypterte DNS-klient eller lese et bufret svar og aldri sende noe. Så en resolverlogg som ikke viser noe er ikke bevis for at et navn aldri ble brukt; det er bevis for at denne resolveren ikke ble spurt.

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

Den siste kommandoen leser den lokale resolverens egen journal, noe som ikke er det samme som loggen til serveren oppstrøms. Hvis spørringene dine går ut via DNS over HTTPS til en leverandør, kan den lokale stubben vise ingenting mens leverandøren har den fullstendige registreringen, og leverandøren er en annen operatør med en annen policy.

Hva hver registrering kan og ikke kan vise

Å koble dem sammen er det egentlige arbeidet, og å koble dem sammen er ikke alltid mulig. En resolver som logger klientadresser kan sammenlignes med en VPN som tildeler adresser fra en kjent pool, og den sammenligningen gir en plausibel kobling mellom et spurt navn og en tunnel, som forblir en kobling mellom to registreringer og ikke en registrering av en person.

Kryptert DNS endrer transporten, ikke synligheten ved endepunktet. Resolveren mottar fortsatt spørsmålet den besvarer, slik RFC 8484 gjør klart, og oppbevaring hos den resolveren er en policybeslutning og ikke en egenskap ved protokollen.

Der delt DNS og buffere gjør historien forvirrende

Flere resolvere er normalt. Et design med delt DNS sender interne navn til en intern server og alt annet til en offentlig, så en enkelt undersøkelse kan omfatte to logger som aldri var ment å kombineres og to oppbevaringsinnstillinger som aldri var ment å sammenlignes. Å se spørringer i begge er bevis for at designet virker, ikke bevis for en lekkasje.

Buffere kutter den andre veien. Et populært navn kan besvares fra bufferen i timer, så resolverens registrering viser den første spørringen og deretter ingenting, mens brukerens applikasjon fortsetter å løse det samme navnet med glede. Fravær av oppføringer etter et visst tidspunkt betyr ikke at ingen brukte navnet etter det tidspunktet.

Bakgrunnstrafikk er den tredje forvrengningen. En telefon som løser et telemetrinavn ved oppstart, en nettleser som løser et domene for søkeforslag, og en oppdatering som sjekker inn hver time, vises alle i en resolverlogg ved siden av navnet du faktisk bryr deg om. Volumet i den loggen er ikke oppmerksomhet, og å telle spørringer er ikke å telle besøk. En resolverlogg er en registrering av spørsmål, og spørsmål er billige å lage.

Still oppbevaringsspørsmålene hver for seg

For hvert system, still tre spørsmål: hvem samler inn, hva samles inn, og hvor lenge det oppbevares. Spør deretter hvem som kan lese det og etter hvilken prosess. RFC 8484-diskusjonen om DNS over HTTPS er en god påminnelse om at kryptert transport ikke fjerner endepunktet, og operatørens egen dokumentasjon er det eneste pålitelige utsagnet om hva det endepunktet oppbevarer.

Når et utsagn om personvern fremsettes om «VPN-en», del det opp i komponenter før du godtar det: tunneloperatøren, resolveren tunnelen deler ut, enhver oppstrøms resolver som disse spørringene når, og applikasjonene på enheten. Hver har sitt eget svar, og et utsagn som er riktig for én, gjentas rutinemessig som om det dekket alle fire.

For feilsøking, bruk samme oppdeling. Spør hvilken applikasjon som laget spørringen og hvilken resolver som besvarte den, og se deretter i loggen som faktisk eier den hendelsen. Å gjette fra den andre loggen sparer ett minutt og koster en ettermiddag.