DNS-resolverlogboeken versus VPN-verbindingslogboeken: wat elk bevat

Een DNS-resolverlogboek en een VPN-verbindingslogboek zijn beide netwerkregistraties, beide nuttig en niet uitwisselbaar. De resolver ontvangt namen die hem gevraagd werd te beantwoorden. Het VPN-eindpunt verwerkt tunnelverbindingen en registreert wat zijn implementatie ervan besloot vast te leggen. Ze kunnen in hetzelfde gebouw staan, door hetzelfde team worden beheerd en onder dezelfde privacyverklaring vallen, en toch beschrijven ze verschillende gebeurtenissen met verschillende identificatoren en verschillende bewaring. Het ene lezen alsof het het andere is, is hoe onderzoeken de verkeerde kant op gaan.

Twee logboeken, twee gebeurtenissen

Een resolververmelding beantwoordt een vraag over naamgeving: deze client vroeg op dit moment naar deze naam, en het antwoord was dit. Een VPN-vermelding beantwoordt een vraag over connectiviteit: deze peer zette een tunnel op of verloor er een, kreeg dit adres toegewezen en droeg ongeveer zoveel gegevens over voordat hij verdween. Geen van beide is een registratie van wat de gebruiker binnen een HTTPS-sessie deed, en geen van beide vervangt de andere.

Het onderscheid heeft een praktische consequentie voor beloften. De uitspraak dat een VPN-aanbieder geen tunnelactiviteit logt, zegt niets over de resolver die hij uitdeelt, en het bewaarbeleid van een resolver zegt niets over wie verbinding maakte met de tunnel. Elke bewering hoort bij zijn eigen operator en zijn eigen systeem.

Volg de query voordat u een van beide logboeken leest

Een query bereikt een resolver alleen als het pad hem werkelijk vraagt. Een toepassing kan de resolver van het besturingssysteem gebruiken, zijn eigen versleutelde DNS-client draaien of een antwoord uit de cache lezen en nooit iets sturen. Een resolverlogboek dat niets toont is dus geen bewijs dat een naam nooit is gebruikt; het is bewijs dat deze resolver niet is gevraagd.

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

Dat laatste commando leest het eigen journaal van de lokale resolver, wat niet hetzelfde is als het logboek van de bovenliggende server. Als uw query's via DNS over HTTPS naar een aanbieder vertrekken, kan de lokale stub niets tonen terwijl de aanbieder de volledige registratie heeft, en de aanbieder is een andere operator met een ander beleid.

Wat elke registratie wel en niet kan tonen

Ze aan elkaar koppelen is het echte werk, en ze aan elkaar koppelen is niet altijd mogelijk. Een resolver die clientadressen logt, kan worden vergeleken met een VPN die adressen toekent uit een bekende pool, en die vergelijking levert een aannemelijke koppeling op tussen een opgevraagde naam en een tunnel, die een koppeling tussen twee registraties blijft en geen registratie van een persoon.

Versleuteld DNS verandert het transport, niet de zichtbaarheid bij het eindpunt. De resolver ontvangt nog steeds de vraag die hij beantwoordt, zoals RFC 8484 duidelijk maakt, en bewaring bij die resolver is een beleidsbeslissing en geen eigenschap van het protocol.

Waar gesplitst DNS en caches het verhaal verwarren

Meerdere resolvers zijn normaal. Een ontwerp met gesplitst DNS stuurt interne namen naar een interne server en al het overige naar een openbare, zodat één onderzoek twee logboeken kan omvatten die nooit bedoeld waren om te combineren en twee bewaarinstellingen die nooit bedoeld waren om te vergelijken. Query's bij beide zien is bewijs dat het ontwerp werkt, geen bewijs van een lek.

Caches snijden de andere kant op. Een populaire naam kan urenlang uit de cache worden beantwoord, zodat de registratie van de resolver de eerste query toont en daarna niets, terwijl de toepassing van de gebruiker dezelfde naam vrolijk blijft oplossen. Het ontbreken van vermeldingen na een bepaald moment betekent niet dat niemand de naam na dat moment gebruikte.

Achtergrondverkeer is de derde vertekening. Een telefoon die bij het opstarten een telemetrienaam oplost, een browser die een domein voor zoeksuggesties oplost en een updater die elk uur incheckt, verschijnen allemaal in een resolverlogboek naast de naam die u werkelijk belangrijk vindt. Volume in dat logboek is geen aandacht, en query's tellen is geen bezoeken tellen. Een resolverlogboek is een registratie van vragen, en vragen zijn goedkoop te genereren.

Stel de bewaarvragen apart

Stel voor elk systeem drie vragen: wie verzamelt, wat wordt verzameld en hoe lang het wordt bewaard. Vraag daarna wie het mag lezen en volgens welke procedure. De RFC 8484-discussie over DNS over HTTPS is een goede herinnering dat versleuteld transport het eindpunt niet wegneemt, en de eigen documentatie van een operator is de enige betrouwbare uitspraak over wat dat eindpunt bewaart.

Wanneer een bewering over privacy over „de VPN” wordt gedaan, splits die dan in componenten voordat u hem accepteert: de tunneloperator, de resolver die de tunnel uitdeelt, elke bovenliggende resolver die deze query's bereiken, en de toepassingen op het apparaat. Elk heeft zijn eigen antwoord, en een bewering die voor één klopt, wordt routinematig herhaald alsof ze alle vier dekt.

Gebruik voor probleemoplossing dezelfde splitsing. Vraag welke toepassing de query deed en welke resolver hem beantwoordde, en kijk dan in het logboek dat die gebeurtenis werkelijk bezit. Raden uit het andere logboek bespaart een minuut en kost een middag.