Wie beheert 1.1.1.1? Een DNS-adres controleren voordat je het vertrouwt

Je hebt 1.1.1.1 in het DNS-veld van de VPN geplakt, de pagina laadde en de tutorial lijkt nu bevestigd. Die waarneming is smaller dan ze aanvoelt: de toepassing gedroeg zich anders, en de wijziging zegt nog niets over wie de query heeft beantwoord of waarom de oude regeling faalde. Een overgeschreven tutorial noemt een bekend openbaar adres vaak ‘het DNS van de VPN’, en dat is een bewering over eigendom en niet over bereikbaarheid. Controleren waarvoor het adres staat, kost vijf minuten en voorkomt een blijvende wijziging om de verkeerde reden.

Een werkende instelling is geen identiteit

Het adres in een instellingenveld is een eindpunt, en een eindpunt heeft een beheerder. Die twee feiten staan los van elkaar, en het tweede is het punt dat mensen overslaan. Voor het paar dat het vaakst wordt gekopieerd, is het antwoord openbaar: Cloudflare publiceert 1.1.1.1 en 1.0.0.1 als zijn resolveradressen en vermeldt ze in zijn officiële adresreferentie. Daarom hoort de naam van de beheerder naast het adres, niet in een aparte tutorial.

Dat paar invoeren terwijl er een tunnel actief is, maakt het VPN-bedrijf niet tot de beheerder ervan en maakt het verkeer niet anoniem. De query verlaat je machine richting een bedrijf dat het adresbereik publiceert, en dat bedrijf kan gerenommeerd zijn en toch niet de partij die de tutorial suggereerde. Het label in de instructies en de beheerder in werkelijkheid zijn verschillende beweringen. Geen van beide zegt wie het netwerkpad daartussen beheert.

Gebruik de eigen gepubliceerde referentie van de resolver om een adrespaar of een versleuteld eindpunt te bevestigen. Een aanbeveling van een andere leverancier kan legitiem zijn, en ‘aanbevolen door’, ‘bereikt via’ en ‘beheerd door’ beschrijven nog steeds drie verschillende relaties.

Vergelijk de drie dingen die een record nodig heeft

Een record dat klaar is voor beoordeling scheidt drie vragen: wie de query moet ontvangen, of de uitwisseling onversleuteld of versleuteld is, en welk pad die moet dragen. Een providernaam kan de tweede of derde niet invullen, en een landlabel kan geen van alle invullen. Schrijf de drie vermeldingen op vóór de wijziging en vergelijk ze daarna. Die vermeldingen zijn niet uitwisselbaar, en ze als één behandelen is hoe een vermoeden documentatie wordt.

De vergelijking is wat een werkende instelling in een gedocumenteerde beslissing verandert. Zonder die vergelijking erft de volgende persoon een adres zonder enige reden eraan. Lees eerst de derde kolom van de tabel hieronder, want daar stoppen de meeste zelfverzekerde verklaringen in werkelijkheid.

De tabel is opzettelijk kort. Het punt is dat elke vermelding een andere vraag beantwoordt en dat geen enkel veld alle drie vult.

Een lokale doorstuurder verbergt de echte bron

Een apparaat dat is ingesteld om zijn router als DNS te gebruiken, wijst naar een doorstuurder. Dat adres duidt de volgende ontvanger van de query aan, niet de resolver die die uiteindelijk beantwoordt. Een lokale stub-resolver voegt dezelfde extra stap toe, en die is gemakkelijk met het echte ding te verwarren omdat hij in elke statusuitvoer verschijnt.

De stub stuurt door naar bronnen die dezelfde uitvoer ook vermeldt, meestal verder naar beneden. Lees de hele keten voordat je iets over de beheerder concludeert, want de eerste regel is niet het hele antwoord. Anders noem je de receptie het bedrijf.

resolvectl status | grep -A4 'Current DNS Server'
dig +short CH TXT whoami.cloudflare @1.1.1.1
dig example.com | grep -E '^;; SERVER'

De tweede opdracht gebruikt de echonaam van een resolver, waar de beheerder er een publiceert, om het bronadres te melden dat hij ziet. De derde noemt de server die antwoordde, en dat is vaak niet het adres dat je hebt geconfigureerd. Vergelijk alle drie de uitvoer voordat je een beheerder noteert.

Versleuteld DNS verandert wat zichtbaar is, niet wie het ziet

DNS over HTTPS en DNS over TLS beschermen de uitwisseling tussen client en resolver. De resolver leest nog steeds elke naam waarnaar wordt gevraagd, want antwoorden is het werk. Wat verandert, is wie de uitwisseling kan observeren: het lokale netwerk ziet een verbinding naar één eindpunt in plaats van een stroom van leesbare queries.

Wat niet verandert, is de vertrouwensrelatie, die nog steeds wijst naar de organisatie die dat eindpunt beheert. Een browser met zijn eigen instelling voor veilig DNS kan de resolver van het besturingssysteem volledig omzeilen. Behandel ze als twee configuraties die het oneens kunnen zijn, en niet als één instelling die twee keer is toegepast.

Privénamen hebben weer hun eigen beslissing nodig. Een werktunnel kan geselecteerde domeinen naar organisatieresolvers routeren, en dat vervangen door een openbare dienst kan interne opzoekingen breken of interne namen aan de verkeerde partij onthullen. Controleer het domeinbeleid voordat je de instellingen van een hele adapter vervangt.

Houd de waarneming smal

Wanneer je vergelijkt, bewaar dan de oude configuratie en wijzig één instelling per keer. Noteer de toepassing, de bewerking, het resolverbeleid en of openbare en toegestane privénamen na een herverbinding nog steeds worden omgezet. Een vergelijking met twee wijzigingen erin bewijst geen van beide. Schrijf het resultaat waar de volgende persoon het vindt, naast de instelling zelf.

resolvectl query intranet.corp.example
resolvectl domain
dig +short @1.1.1.1 example.com

Als de toepassing begint te werken, houd de bewering dan zo klein als het bewijs toestaat. Die wijziging hielp één test, en ze zegt niets over of de vorige resolver te kwader trouw handelde, of de tunnel stuk was, of een ander apparaat dezelfde vervanging nodig heeft. Het blijvende resultaat is een configuratie waarvan je de beheerder en het doel kunt uitleggen.