Hvem driver 1.1.1.1? Tjek en DNS-adresse, før du stoler på den
En DNS-adresse, der bruges sammen med en VPN, drives ikke nødvendigvis af den VPN. Identificér resolveren, og tjek derefter stien og politikken for private navne hver for sig.
Du indsatte 1.1.1.1 i VPN’ens DNS-felt, siden indlæste, og guiden ser nu bekræftet ud. Den observation er snævrere, end den føles: applikationen opførte sig anderledes, og ændringen siger endnu intet om, hvem der besvarede forespørgslen, eller hvorfor den gamle opsætning fejlede. En kopieret guide kalder ofte en kendt offentlig adresse for “VPN’ens DNS”, og det er en påstand om ejerskab, ikke om rækkevidde. At tjekke, hvad adressen repræsenterer, tager fem minutter og forhindrer en permanent ændring af den forkerte grund.
En fungerende indstilling er ikke en identitet
Adressen i et indstillingsfelt er et endepunkt, og et endepunkt har en operatør. De to fakta er adskilte, og det andet er det, folk springer over. For det par, der kopieres oftest, er svaret offentligt: Cloudflare offentliggør 1.1.1.1 og 1.0.0.1 som sine resolveradresser og lister dem i sin officielle adressereference. Derfor hører operatørens navn ved siden af adressen og ikke i en separat guide.
At indtaste det par, mens en tunnel er oppe, gør ikke VPN-selskabet til dets operatør og gør ikke trafikken anonym. Forespørgslen forlader din maskine til et selskab, der offentliggør adresseområdet, og det selskab kan være velrenommeret og stadig ikke være den part, guiden antydede. Etiketten i instruktionerne og operatøren i virkeligheden er forskellige påstande. Ingen af dem fortæller, hvem der driver netværksstien imellem.
Brug resolverens egen offentliggjorte reference til at bekræfte et adressepar eller et krypteret endepunkt. En anbefaling fra en anden leverandør kan være legitim, og “anbefalet af”, “nået gennem” og “drevet af” beskriver stadig tre forskellige forhold.
Sammenlign de tre ting, en registrering kræver
En revisionsklar registrering adskiller tre spørgsmål: hvem der skal modtage forespørgslen, om udvekslingen er klar eller krypteret, og hvilken sti der skal bære den. Et udbydernavn kan ikke udfylde det andet eller tredje, og et landemærke kan ikke udfylde noget af dem. Skriv de tre poster ned før ændringen, og sammenlign dem bagefter. De poster kan ikke udskiftes, og at behandle dem som én er, hvordan en gætning bliver til dokumentation.
Sammenligningen er det, der gør en fungerende indstilling til en dokumenteret beslutning. Uden den arver den næste person en adresse uden nogen grund vedhæftet. Læs tredje kolonne i tabellen nedenfor først, for det er der, de fleste selvsikre forklaringer 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 bevidst kort. Pointen er, at hver post besvarer et andet spørgsmål, og at intet enkelt felt udfylder alle tre.
En lokal videresender skjuler den egentlige server
En enhed, der er sat til at bruge sin router som DNS, peger på en videresender. Den adresse identificerer den næste modtager af forespørgslen, ikke den resolver, der til sidst besvarer den. En lokal stub-resolver tilføjer det samme ekstra trin, og den er let at forveksle med det rigtige, fordi den optræder i hver statusudskrift.
Stubben videresender til opstrømme, som den samme udskrift også lister, normalt længere nede. Læs hele kæden, før du konkluderer noget om operatøren, for den første linje er ikke hele svaret. Ellers kalder du receptionen for selskabet.
resolvectl status | grep -A4 'Current DNS Server'
dig +short CH TXT whoami.cloudflare @1.1.1.1
dig example.com | grep -E '^;; SERVER'Den anden kommando bruger en resolvers ekonavn, hvor operatøren offentliggør et, til at rapportere kildeadressen, den ser. Den tredje navngiver den server, der svarede, hvilket ofte ikke er den adresse, du konfigurerede. Sammenlign alle tre udskrifter, før du skriver en operatør ned.
Krypteret DNS ændrer, hvad der er synligt, ikke hvem der ser det
DNS over HTTPS og DNS over TLS beskytter udvekslingen mellem klient og resolver. Resolveren læser stadig hvert navn, den bliver spurgt om, fordi det er jobbet at svare. Det, der ændrer sig, er, hvem der kan overvåge udvekslingen: det lokale netværk ser en forbindelse til ét endepunkt i stedet for en strøm af klartekstforespørgsler.
Det, der ikke ændrer sig, er tillidsforholdet, som stadig peger på den organisation, der driver det endepunkt. En browser med sin egen indstilling til sikker DNS kan helt omgå styresystemets resolver. Behandl dem som to konfigurationer, der kan være uenige, i stedet for som én indstilling anvendt to gange.
Private navne har igen brug for deres egen beslutning. En arbejdstunnel kan rute udvalgte domæner til organisationens resolvere, og at erstatte det med en offentlig tjeneste kan bryde interne opslag eller afsløre interne navne for den forkerte part. Tjek domænepolitikken, før du erstatter en hel adapters indstillinger.
Hold observationen snæver
Når du sammenligner, skal du bevare den gamle konfiguration og ændre én indstilling ad gangen. Notér applikationen, handlingen, resolverpolitikken og om offentlige og tilladte private navne stadig slår op efter en genopkobling. En sammenligning med to ændringer i sig beviser ingen af dem. Skriv resultatet, hvor den næste person finder det, ved siden af selve indstillingen.
resolvectl query intranet.corp.example
resolvectl domain
dig +short @1.1.1.1 example.comHvis applikationen begynder at virke, så hold påstanden så lille, som beviserne tillader. Den ændring hjalp én test, og den siger intet om, hvorvidt den tidligere resolver handlede i ond tro, om tunnelen var brudt, eller om en anden enhed har brug for samme udskiftning. Det holdbare resultat er en konfiguration, hvis operatør og formål du kan forklare.