DNS-resolverlogfiler kontra VPN-forbindelseslogfiler: hvad hver især indeholder

En DNS-resolverlog og en VPN-forbindelseslog er begge netværksregistreringer, begge nyttige og ikke udskiftelige. Resolveren modtager navne, den blev bedt om at svare på. VPN-endepunktet håndterer tunnelforbindelser og registrerer, hvad dets implementering valgte at registrere om dem. De kan ligge i samme bygning, drives af samme team og være omfattet af samme privatlivserklæring, og alligevel beskriver de forskellige hændelser med forskellige identifikatorer og forskellig opbevaring. At læse den ene, som om den var den anden, er hvordan undersøgelser går galt.

To logfiler, to hændelser

En post i resolveren besvarer et spørgsmål om navngivning: denne klient bad om dette navn på dette tidspunkt, og svaret var dette. En post i VPN'en besvarer et spørgsmål om forbindelse: denne peer oprettede eller mistede en tunnel, fik tildelt denne adresse og overførte omtrent så meget data, før den forsvandt. Ingen af dem er en registrering af, hvad brugeren gjorde inde i en HTTPS-session, og ingen af dem erstatter den anden.

Forskellen har en praktisk konsekvens for løfter. Udsagnet om, at en VPN-udbyder ikke logger tunnelaktivitet, siger intet om den resolver, den udleverer, og en resolvers opbevaringspolitik siger intet om, hvem der oprettede forbindelse til tunnelen. Hvert udsagn hører til sin egen operatør og sit eget system.

Følg forespørgslen, før du læser nogen af logfilerne

En forespørgsel når kun en resolver, hvis stien faktisk spørger den. En applikation kan bruge styresystemets resolver, køre sin egen krypterede DNS-klient eller læse et cachet svar og aldrig sende noget. Så en resolverlog, der ikke viser noget, er ikke bevis for, at et navn aldrig blev brugt; det er bevis for, at denne resolver ikke blev spurgt.

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

Den sidste kommando læser den lokale resolvers egen journal, hvilket ikke er det samme som den opstrøms servers log. Hvis dine forespørgsler forlader via DNS over HTTPS til en udbyder, kan den lokale stub vise intet, mens udbyderen har den fuldstændige registrering, og udbyderen er en anden operatør med en anden politik.

Hvad hver registrering kan og ikke kan vise

At sammenkæde dem er det egentlige arbejde, og at sammenkæde dem er ikke altid muligt. En resolver, der logger klientadresser, kan sammenlignes med en VPN, der tildeler adresser fra en kendt pulje, og den sammenligning giver en plausibel forbindelse mellem et forespurgt navn og en tunnel, som forbliver en forbindelse mellem to registreringer snarere end en registrering af en person.

Krypteret DNS ændrer transporten, ikke synligheden ved endepunktet. Resolveren modtager stadig det spørgsmål, den besvarer, som RFC 8484 gør klart, og opbevaring i den resolver er en politisk beslutning snarere end en egenskab ved protokollen.

Hvor opdelt DNS og cachelagre slører historien

Flere resolvere er normalt. Et design med opdelt DNS sender interne navne til en intern server og alt andet til en offentlig, så en enkelt undersøgelse kan omfatte to logfiler, der aldrig var ment at blive kombineret, og to opbevaringsindstillinger, der aldrig var ment at blive sammenlignet. At se forespørgsler i begge er bevis for, at designet virker, ikke bevis for en lækage.

Cachelagre skærer den anden vej. Et populært navn kan besvares fra cachen i timer, så resolverens registrering viser den første forespørgsel og derefter intet, mens brugerens applikation fortsat gladeligt opløser det samme navn. Fravær af poster efter et bestemt tidspunkt betyder ikke, at ingen brugte navnet efter det tidspunkt.

Baggrundstrafik er den tredje forvrængning. En telefon, der opløser et telemetrinavn ved opstart, en browser, der opløser et domæne til søgeforslag, og en opdateringsfunktion, der tjekker ind hver time, optræder alle i en resolverlog ved siden af det navn, du faktisk bekymrer dig om. Volumen i den log er ikke opmærksomhed, og at tælle forespørgsler er ikke at tælle besøg. En resolverlog er en registrering af spørgsmål, og spørgsmål er billige at generere.

Stil opbevaringsspørgsmålene hver for sig

For hvert system skal du stille tre spørgsmål: hvem indsamler, hvad indsamles, og hvor længe det opbevares. Spørg derefter, hvem der kan læse det, og under hvilken proces. RFC 8484-diskussionen om DNS over HTTPS er en god påmindelse om, at krypteret transport ikke fjerner endepunktet, og operatørens egen dokumentation er det eneste pålidelige udsagn om, hvad det endepunkt opbevarer.

Når der fremsættes et udsagn om privatliv om “VPN'en”, skal du dele det op i komponenter, før du accepterer det: tunneloperatøren, den resolver tunnelen udleverer, enhver opstrøms resolver, som disse forespørgsler når, og applikationerne på enheden. Hver har sit eget svar, og et udsagn, der er korrekt for én, gentages rutinemæssigt, som om det dækkede alle fire.

Til fejlfinding skal du bruge samme opdeling. Spørg, hvilken applikation der lavede forespørgslen, og hvilken resolver der svarede på den, og se derefter i den log, der faktisk ejer den hændelse. At gætte ud fra den anden log sparer et minut og koster en eftermiddag.