DNS-resolveloggar kontra VPN-tilkoplingsloggar: kva kvar av dei inneheld

Ein DNS-resolvelogg og ein VPN-tilkoplingslogg er begge nettverksregistreringar, begge nyttige og ikkje utbyttbare. Resolvaren tek imot namn han vart beden om å svare på. VPN-endepunktet handterer tunneltilkoplingar og registrerer det implementasjonen valde å registrere om dei. Dei kan ligge i same bygning, drivast av same team og omfattast av same personvernerklæring, og likevel skildrar dei ulike hendingar med ulike identifikatorar og ulik oppbevaring. Å lese den eine som om han var den andre er korleis undersøkingar går gale.

To loggar, to hendingar

Ei resolvaroppføring svarar på eit spørsmål om namngjeving: denne klienten bad om dette namnet på dette tidspunktet, og svaret var dette. Ei VPN-oppføring svarar på eit spørsmål om tilkopling: denne peeren oppretta eller mista ein tunnel, fekk tildelt denne adressa, og overførte om lag så mykje data før han forsvann. Ingen av dei er ei registrering av kva brukaren gjorde inne i ein HTTPS-økt, og ingen av dei erstattar den andre.

Forskjellen har ein praktisk konsekvens for løfte. Utsagnet om at ein VPN-leverandør ikkje loggar tunnelaktivitet seier ingenting om resolvaren han deler ut, og oppbevaringspolicyen til ein resolvar seier ingenting om kven som kopla seg til tunnelen. Kvart utsagn høyrer til sin eigen operatør og sitt eige system.

Følg spørjinga før du les nokon av loggane

Ei spørjing når berre ein resolvar dersom vegen faktisk spør han. Ein applikasjon kan bruke resolvaren til operativsystemet, køyre sin eigen krypterte DNS-klient eller lese eit bufra svar og aldri sende noko. Så ein resolvelogg som ikkje viser noko er ikkje bevis for at eit namn aldri vart brukt; det er bevis for at denne resolvaren ikkje vart spurd.

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

Den siste kommandoen les den lokale resolvaren sin eigen journal, noko som ikkje er det same som loggen til tenaren oppstraums. Viss spørjingane dine går ut via DNS over HTTPS til ein leverandør, kan den lokale stubben vise ingenting medan leverandøren har den fullstendige registreringa, og leverandøren er ein annan operatør med ein annan policy.

Kva kvar registrering kan og ikkje kan vise

Å kople dei saman er det eigentlege arbeidet, og å kople dei saman er ikkje alltid mogleg. Ein resolvar som loggar klientadresser kan samanliknast med ein VPN som tildeler adresser frå ein kjend pool, og den samanlikninga gir ei truverdig kopling mellom eit spurt namn og ein tunnel, som blir verande ei kopling mellom to registreringar og ikkje ei registrering av ein person.

Kryptert DNS endrar transporten, ikkje synlegheita ved endepunktet. Resolvaren tek framleis imot spørsmålet han svarar på, slik RFC 8484 gjer klart, og oppbevaring hos den resolvaren er ei policyavgjerd og ikkje ein eigenskap ved protokollen.

Der delt DNS og buffer gjer historia forvirrande

Fleire resolvarar er normalt. Eit design med delt DNS sender interne namn til ein intern tenar og alt anna til ein offentleg, så ei enkel undersøking kan omfatte to loggar som aldri var meint å kombinerast og to oppbevaringsinnstillingar som aldri var meint å samanliknast. Å sjå spørjingar i begge er bevis for at designet verkar, ikkje bevis for ein lekkasje.

Buffer kuttar den andre vegen. Eit populært namn kan svarast frå bufferen i timar, så registreringa til resolvaren viser den første spørjinga og deretter ingenting, medan applikasjonen til brukaren held fram med å løyse det same namnet med glede. Fråvær av oppføringar etter eit visst tidspunkt tyder ikkje at ingen brukte namnet etter det tidspunktet.

Bakgrunnstrafikk er den tredje forvrengninga. Ein telefon som løyser eit telemetrinamn ved oppstart, ein nettlesar som løyser eit domene for søkeforslag, og ein oppdaterar som sjekkar inn kvar time, viser seg alle i ein resolvelogg ved sida av namnet du faktisk bryr deg om. Volumet i den loggen er ikkje merksemd, og å telje spørjingar er ikkje å telje besøk. Ein resolvelogg er ei registrering av spørsmål, og spørsmål er billege å lage.

Still oppbevaringsspørsmåla kvar for seg

For kvart system, still tre spørsmål: kven samlar inn, kva blir samla inn, og kor lenge det blir oppbevart. Spør deretter kven som kan lese det og etter kva prosess. RFC 8484-diskusjonen om DNS over HTTPS er ei god påminning om at kryptert transport ikkje fjernar endepunktet, og dokumentasjonen til operatøren sjølv er det einaste pålitelege utsagnet om kva det endepunktet oppbevarer.

Når eit utsagn om personvern blir sett fram om «VPN-en», del det opp i komponentar før du godtek det: tunneloperatøren, resolvaren tunnelen deler ut, kvar ein oppstraums resolvar som desse spørjingane når, og applikasjonane på eininga. Kvar har sitt eige svar, og eit utsagn som er riktig for éin blir rutinemessig gjenteke som om det dekte alle fire.

For feilsøking, bruk same oppdeling. Spør kva applikasjon som laga spørjinga og kva resolvar som svara på henne, og sjå deretter i loggen som faktisk eig den hendinga. Å gjete frå den andre loggen sparer eitt minutt og kostar ein ettermiddag.