Kven driv 1.1.1.1? Sjekke ei DNS-adresse før du stolar på ho

Du lima 1.1.1.1 inn i DNS-feltet til VPN-en, sida lasta, og rettleiinga ser no stadfesta ut. Den observasjonen er smalare enn han kjennest: programmet oppførte seg annleis, og endringa seier enno ingenting om kven som svara på spørjinga eller kvifor den gamle ordninga svikta. Ei kopiert rettleiing kallar ofte ei kjend offentleg adresse «DNS-en til VPN-en», og det er ein påstand om eigarskap, ikkje om rekkevidd. Å sjekke kva adressa står for tek fem minutt og hindrar ei varig endring av feil grunn.

Eit fungerande oppsett er ikkje ein identitet

Adressa i eit innstillingsfelt er eit endepunkt, og eit endepunkt har ein operatør. Desse to fakta er skilde, og det andre er det folk hoppar over. For paret som oftast blir kopiert, er svaret offentleg: Cloudflare publiserer 1.1.1.1 og 1.0.0.1 som resolveradressene sine og listar dei i si offisielle adressereferanse. Derfor høyrer namnet til operatøren ved sida av adressa, ikkje i ei eiga rettleiing.

Å skrive inn det paret medan ein tunnel er oppe gjer ikkje VPN-selskapet til operatøren og gjer ikkje trafikken anonym. Spørjinga forlèt maskina di til eit selskap som publiserer adresseområdet, og det selskapet kan vere velrenommert og likevel ikkje vere parten rettleiinga antyda. Etiketten i instruksjonane og operatøren i røynda er to ulike påstandar. Ingen av dei seier kven som driv nettverksstien imellom.

Bruk resolveren sin eigen publiserte referanse for å stadfeste eit adressepar eller eit kryptert endepunkt. Ei tilråding frå ein annan leverandør kan vere legitim, og «tilrådd av», «nådd gjennom» og «driven av» skildrar framleis tre ulike tilhøve.

Samanlikn dei tre tinga ein registrering treng

Ei registrering som er klar for gjennomgang skil tre spørsmål: kven som skal ta imot spørjinga, om utvekslinga er rein eller kryptert, og kva sti som skal bere henne. Eit leverandørnamn kan ikkje fylle ut det andre eller tredje, og ei landsetikett kan ikkje fylle ut nokon av dei. Skriv ned dei tre oppføringane før endringa og samanlikn dei etterpå. Dei oppføringane kan ikkje bytast ut, og å handsame dei som éin er korleis ein gissing blir dokumentasjon.

Samanlikninga er det som gjer eit fungerande oppsett til eit dokumentert vedtak. Utan henne arvar neste person ei adresse utan nokon grunn knytt til seg. Les tredje kolonne i tabellen nedanfor først, for det er der dei fleste sjølvsikre forklaringane faktisk stoppar.

Tabellen er med vilje kort. Poenget er at kvar oppføring svarar på eit anna spørsmål, og at inkje einskilt felt fyller alle tre.

Ein lokal videresendar skjuler den eigenlege kjelda

Eit apparat som er sett opp til å bruke rutaren sin som DNS, peikar på ein videresendar. Den adressa identifiserer den neste mottakaren av spørjinga, ikkje resolveren som til slutt svarar på henne. Ein lokal stub-resolver legg til det same ekstrasteget, og han er lett å forveksle med det verkelege fordi han dukkar opp i kvar statusutskrift.

Stubben videresender til kjelder som den same utskrifta også listar, vanlegvis lenger nede. Les heile kjeda før du konkluderer noko om operatøren, for den første linja er ikkje heile svaret. Elles kallar du resepsjonen for selskapet.

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

Den andre kommandoen brukar ekkonamnet til ein resolver, der operatøren publiserer eitt, for å rapportere kjeldeadressa han ser. Den tredje namngir tenaren som svara, og det er ofte ikkje adressa du sette opp. Samanlikn alle tre utskriftene før du skriv ned ein operatør.

Kryptert DNS endrar kva som er synleg, ikkje kven som ser det

DNS over HTTPS og DNS over TLS verner utvekslinga mellom klient og resolver. Resolveren les framleis kvart namn han blir spurd om, fordi det å svare er jobben. Det som endrar seg, er kven som kan følgje med på utvekslinga: det lokale nettet ser ei tilkopling til eitt endepunkt i staden for ein straum av klartekstspørjingar.

Det som ikkje endrar seg, er tillitshøvet, som framleis peikar på organisasjonen som driv det endepunktet. Ein nettlesar med sitt eige oppsett for trygg DNS kan gå heilt utanom resolveren til operativsystemet. Handsame dei som to konfigurasjonar som kan vere usamde, ikkje som eitt oppsett brukt to gonger.

Private namn treng igjen sitt eige vedtak. Ein arbeidstunnel kan rute utvalde domene til organisasjonen sine resolverar, og å byte det ut med ein offentleg teneste kan bryte interne oppslag eller avsløre interne namn for feil part. Sjekk domenepolicyen før du byter ut oppsettet til ein heil adapter.

Hald observasjonen smal

Når du samanliknar, ta vare på den gamle konfigurasjonen og endre eitt oppsett om gongen. Noter programmet, handlinga, resolverpolicyen og om offentlege og tillatne private namn framleis blir løyste etter ei ny tilkopling. Ei samanlikning med to endringar i seg provar ingen av dei. Skriv resultatet der neste person finn det, ved sida av sjølve oppsettet.

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

Viss programmet byrjar å verke, hald påstanden så liten som prova tillèt. Den endringa hjelpte ein test, og ho seier ingenting om den førre resolveren handla i vond tru, om tunnelen var broten, eller om eit anna apparat treng same utskiftinga. Det varige resultatet er ein konfigurasjon der du kan forklare operatøren og føremålet.