Hvem driver 1.1.1.1? Sjekke en DNS-adresse før du stoler på den
En DNS-adresse som brukes sammen med en VPN, drives ikke nødvendigvis av den VPN-en. Identifiser resolveren, og sjekk deretter stien og policyen for private navn hver for seg.
Du limte 1.1.1.1 inn i VPN-ens DNS-felt, siden lastet, og veiledningen ser nå bekreftet ut. Den observasjonen er smalere enn den føles: applikasjonen oppførte seg annerledes, og endringen sier ennå ingenting om hvem som svarte på spørringen eller hvorfor den gamle ordningen feilet. En kopiert veiledning kaller ofte en kjent offentlig adresse for «VPN-ens DNS», og det er en påstand om eierskap, ikke om rekkevidde. Å sjekke hva adressen representerer tar fem minutter og forhindrer en permanent endring av feil grunn.
En fungerende innstilling er ikke en identitet
Adressen i et innstillingsfelt er et endepunkt, og et endepunkt har en operatør. De to faktaene er atskilt, og det andre er det folk hopper over. For paret som oftest kopieres, er svaret offentlig: Cloudflare publiserer 1.1.1.1 og 1.0.0.1 som resolveradressene sine og lister dem i sin offisielle adressereferanse. Derfor hører operatørens navn hjemme ved siden av adressen, ikke i en egen veiledning.
Å skrive inn det paret mens en tunnel er oppe gjør ikke VPN-selskapet til operatøren og gjør ikke trafikken anonym. Spørringen forlater maskinen din til et selskap som publiserer adresseområdet, og det selskapet kan være velrenommert og likevel ikke være parten veiledningen antydet. Etiketten i instruksjonene og operatøren i virkeligheten er forskjellige påstander. Ingen av dem forteller hvem som driver nettverksstien imellom.
Bruk resolverens egen publiserte referanse for å bekrefte et adressepar eller et kryptert endepunkt. En anbefaling fra en annen leverandør kan være legitim, og «anbefalt av», «nådd gjennom» og «drevet av» beskriver fortsatt tre forskjellige forhold.
Sammenlign de tre tingene en registrering trenger
En registrering som er klar for gjennomgang skiller tre spørsmål: hvem som skal motta spørringen, om utvekslingen er ren eller kryptert, og hvilken sti som skal bære den. Et leverandørnavn kan ikke fylle ut det andre eller tredje, og en landsetikett kan ikke fylle ut noen av dem. Skriv ned de tre oppføringene før endringen og sammenlign dem etterpå. De oppføringene er ikke utbyttbare, og å behandle dem som én er hvordan en gjetning blir dokumentasjon.
Sammenligningen er det som gjør en fungerende innstilling til en dokumentert beslutning. Uten den arver neste person en adresse uten noen grunn knyttet til seg. Les tredje kolonne i tabellen nedenfor først, for det er der de fleste selvsikre forklaringene faktisk stopper.
| Entry | What it records | What it cannot tell you |
|---|---|---|
| Recipient | Which resolver should answer | Who operates the path to it |
| Transport | Plain DNS or an encrypted variant | Whether names stay private |
| Path | Which interface carries the query | Which upstream answers last |
Tabellen er bevisst kort. Poenget er at hver oppføring svarer på et annet spørsmål, og at ingen enkelt felt fyller alle tre.
En lokal videresender skjuler den egentlige kilden
En enhet som er satt opp til å bruke ruteren som DNS, peker på en videresender. Den adressen identifiserer den neste mottakeren av spørringen, ikke resolveren som til slutt svarer på den. En lokal stub-resolver legger til samme ekstra trinn, og den er lett å forveksle med det virkelige, fordi den vises i hver statusutskrift.
Stubben videresender til kilder som den samme utskriften også lister, vanligvis lenger ned. Les hele kjeden før du konkluderer noe om operatøren, for den første linjen er ikke hele svaret. Ellers kaller 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 bruker en resolvers ekkonavn, der operatøren publiserer ett, for å rapportere kildeadressen den ser. Den tredje navngir serveren som svarte, og det er ofte ikke adressen du konfigurerte. Sammenlign alle tre utskriftene før du skriver ned en operatør.
Kryptert DNS endrer hva som er synlig, ikke hvem som ser det
DNS over HTTPS og DNS over TLS beskytter utvekslingen mellom klient og resolver. Resolveren leser fortsatt hvert navn den blir spurt om, fordi det å svare er jobben. Det som endrer seg, er hvem som kan se utvekslingen: det lokale nettverket ser en tilkobling til ett endepunkt i stedet for en strøm av klartekstspørringer.
Det som ikke endrer seg, er tillitsforholdet, som fortsatt peker på organisasjonen som driver det endepunktet. En nettleser med sin egen innstilling for sikker DNS kan omgå operativsystemets resolver helt. Behandle dem som to konfigurasjoner som kan være uenige, ikke som én innstilling brukt to ganger.
Private navn trenger igjen sin egen beslutning. En arbeidstunnel kan rute utvalgte domener til organisasjonens resolvere, og å erstatte det med en offentlig tjeneste kan bryte interne oppslag eller avsløre interne navn for feil part. Sjekk domenepolicyen før du erstatter innstillingene til en hel adapter.
Hold observasjonen smal
Når du sammenligner, ta vare på den gamle konfigurasjonen og endre én innstilling om gangen. Noter applikasjonen, operasjonen, resolverpolicyen og om offentlige og tillatte private navn fortsatt slår opp etter en gjentilkobling. En sammenligning med to endringer i seg beviser ingen av dem. Skriv resultatet der neste person finner det, ved siden av selve innstillingen.
resolvectl query intranet.corp.example
resolvectl domain
dig +short @1.1.1.1 example.comHvis applikasjonen begynner å virke, hold påstanden så liten som bevisene tillater. Den endringen hjalp én test, og den sier ingenting om hvorvidt den forrige resolveren handlet i ond tro, om tunnelen var brutt, eller om en annen enhet trenger samme erstatning. Det varige resultatet er en konfigurasjon hvis operatør og formål du kan forklare.