Vem driver 1.1.1.1? Kontrollera en DNS-adress innan du litar på den

Du klistrade in 1.1.1.1 i VPN:ns DNS-fält, sidan laddades och guiden verkar nu bekräftad. Den observationen är smalare än den känns: programmet betedde sig annorlunda, och ändringen säger ännu inget om vem som svarade på frågan eller varför den gamla ordningen misslyckades. En kopierad guide kallar ofta en välkänd offentlig adress för ”VPN:ns DNS”, och det är ett påstående om ägande, inte om nåbarhet. Att kontrollera vad adressen står för tar fem minuter och förhindrar en permanent ändring av fel anledning.

En fungerande inställning är inte en identitet

Adressen i ett inställningsfält är en slutpunkt, och en slutpunkt har en operatör. De två fakta är åtskilda, och det andra är det som folk hoppar över. För paret som kopieras oftast är svaret offentligt: Cloudflare publicerar 1.1.1.1 och 1.0.0.1 som sina resolveradresser och listar dem i sin officiella adressreferens. Därför hör operatörens namn till bredvid adressen, inte i en separat guide.

Att ange det paret medan en tunnel är uppe gör inte VPN-företaget till dess operatör och gör inte trafiken anonym. Frågan lämnar din maskin mot ett företag som publicerar adressintervallet, och det företaget kan vara välrenommerat och ändå inte vara den part som guiden antydde. Etiketten i instruktionerna och operatören i verkligheten är olika påståenden. Ingen av dem säger vem som driver nätverksvägen däremellan.

Använd resolverarens egen publicerade referens för att bekräfta ett adresspar eller en krypterad slutpunkt. En rekommendation från en annan leverantör kan vara legitim, och ”rekommenderad av”, ”nådd via” och ”driven av” beskriver fortfarande tre olika relationer.

Jämför de tre saker en post behöver

En granskningsfärdig post skiljer på tre frågor: vem som ska ta emot frågan, om utbytet är klartext eller krypterat och vilken väg som ska bära det. Ett leverantörsnamn kan inte fylla i den andra eller tredje, och en landsbeteckning kan inte fylla i någon av dem. Skriv ner de tre posterna före ändringen och jämför dem efteråt. De posterna är inte utbytbara, och att behandla dem som en är hur en gissning blir dokumentation.

Jämförelsen är det som förvandlar en fungerande inställning till ett dokumenterat beslut. Utan den ärver nästa person en adress utan någon anledning kopplad till sig. Läs tredje kolumnen i tabellen nedan först, för det är där de flesta självsäkra förklaringar faktiskt slutar.

Tabellen är medvetet kort. Poängen är att varje post svarar på en annan fråga och att inget enskilt fält fyller alla tre.

En lokal vidarebefordrare döljer den egentliga källan

En enhet som är inställd på att använda sin router som DNS pekar på en vidarebefordrare. Den adressen identifierar nästa mottagare av frågan, inte den resolverare som till slut svarar på den. En lokal stub-resolver lägger till samma extra steg, och den är lätt att förväxla med det verkliga eftersom den förekommer i varje statusutskrift.

Stubben vidarebefordrar till källor som samma utskrift också listar, vanligtvis längre ner. Läs hela kedjan innan du drar någon slutsats om operatören, för den första raden är inte hela svaret. Annars kallar du receptionen för företaget.

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

Det andra kommandot använder en resolverares ekonamn, där operatören publicerar ett, för att rapportera källadressen den ser. Det tredje namnger servern som svarade, vilket ofta inte är den adress du konfigurerade. Jämför alla tre utskrifterna innan du skriver ner en operatör.

Krypterad DNS ändrar vad som är synligt, inte vem som ser det

DNS over HTTPS och DNS over TLS skyddar utbytet mellan klient och resolverare. Resolveraren läser fortfarande varje namn den tillfrågas om, eftersom det är jobbet att svara. Det som ändras är vem som kan se utbytet: det lokala nätverket ser en anslutning till en enda slutpunkt i stället för en ström av klartextfrågor.

Det som inte ändras är förtroendeförhållandet, som fortfarande pekar på den organisation som driver den slutpunkten. En webbläsare med egen inställning för säker DNS kan helt kringgå operativsystemets resolverare. Behandla dem som två konfigurationer som kan vara oense, inte som en inställning som tillämpas två gånger.

Privata namn behöver återigen sitt eget beslut. En arbetstunnel kan dirigera valda domäner till organisationens resolverare, och att ersätta det med en offentlig tjänst kan bryta interna uppslag eller avslöja interna namn för fel part. Kontrollera domänpolicyn innan du ersätter inställningarna för en hel adapter.

Håll observationen smal

När du jämför ska du bevara den gamla konfigurationen och ändra en inställning i taget. Anteckna programmet, åtgärden, resolverarpolicyn och om offentliga och tillåtna privata namn fortfarande löses upp efter en återanslutning. En jämförelse med två ändringar i sig bevisar ingen av dem. Skriv resultatet där nästa person hittar det, bredvid själva inställningen.

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

Om programmet börjar fungera ska du hålla påståendet så litet som bevisen tillåter. Den ändringen hjälpte ett test, och den säger inget om huruvida den tidigare resolveraren handlade i ond tro, om tunneln var trasig eller om en annan enhet behöver samma utbyte. Det varaktiga resultatet är en konfiguration vars operatör och syfte du kan förklara.