Wie bestuur 1.1.1.1? Kontroleer ’n DNS-adres voordat jy dit vertrou

Jy het 1.1.1.1 in die VPN se DNS-veld geplak, die bladsy het gelaai, en die tutoriaal lyk nou bevestig. Daardie waarneming is smaller as wat dit voel: die toepassing het anders opgetree, en die verandering sê nog niks oor wie die navraag beantwoord het of waarom die ou reëling gefaal het nie. ’n Oorgeskrewe tutoriaal noem ’n bekende openbare adres dikwels “die VPN se DNS”, en dit is ’n bewering oor eienaarskap, nie oor bereikbaarheid nie. Om te kontroleer waarvoor die adres staan, neem vyf minute en verhoed ’n permanente verandering om die verkeerde rede.

’n Werkende instelling is nie ’n identiteit nie

Die adres in ’n instellingsveld is ’n eindpunt, en ’n eindpunt het ’n operateur. Daardie twee feite is apart, en die tweede een is die een wat mense oorslaan. Vir die paar wat die meeste gekopieer word, is die antwoord openbaar: Cloudflare publiseer 1.1.1.1 en 1.0.0.1 as sy resolver-adresse en noem dit in sy amptelike adresverwysing. Daarom hoort die operateur se naam by die adres en nie in ’n aparte tutoriaal nie.

Om daardie paar in te voer terwyl ’n tonnel aan is, maak nie die VPN-maatskappy die operateur daarvan nie, en dit maak die verkeer nie anoniem nie. Die navraag verlaat jou masjien na ’n maatskappy wat die adresreeks publiseer, en daardie maatskappy kan gerespekteerd wees en steeds nie die party wees wat die tutoriaal geïmpliseer het nie. Die etiket in die instruksies en die operateur in die werklikheid is verskillende bewerings. Nie een van hulle sê wie die netwerkpad tussenin bestuur nie.

Gebruik die resolver se eie gepubliseerde verwysing om ’n adrespaar of ’n geënkripteerde eindpunt te bevestig. ’n Aanbeveling van ’n ander verskaffer kan geldig wees, en “aanbeveel deur”, “bereik deur” en “bestuur deur” beskryf steeds drie verskillende verhoudings.

Vergelyk die drie dinge wat ’n rekord nodig het

’n Hersienbare rekord skei drie vrae: wie die navraag moet ontvang, of die uitruiling gewoon of geënkripteer is, en watter pad dit moet dra. ’n Verskaffernaam kan nie die tweede of derde invul nie, en ’n landetiket kan nie enige een van hulle invul nie. Skryf die drie inskrywings neer voor die verandering en vergelyk hulle daarna. Daardie inskrywings is nie uitruilbaar nie, en om hulle as een te behandel is hoe ’n vermoede dokumentasie word.

Die vergelyking is wat ’n werkende instelling in ’n gedokumenteerde besluit verander. Sonder dit erf die volgende persoon ’n adres met geen rede daaraan nie. Lees eers die derde kolom van die tabel hieronder, want dit is waar die meeste selfversekerde verduidelikings eintlik stop.

Die tabel is doelbewus kort. Die punt daarvan is dat elke inskrywing ’n ander vraag beantwoord, en geen enkele veld vul al drie in nie.

’n Plaaslike aanstuurder verberg die werklike opstroom

’n Toestel wat ingestel is om sy router as DNS te gebruik, wys na ’n aanstuurder. Daardie adres identifiseer die volgende ontvanger van die navraag, nie die resolver wat dit uiteindelik beantwoord nie. ’n Plaaslike stomp-resolver voeg dieselfde ekstra stap by, en dit is maklik om dit met die werklike ding te verwar omdat dit in elke statusuitset verskyn.

Die stomp stuur aan na opstrome wat dieselfde uitset ook lys, gewoonlik verder af. Lees die hele ketting voordat jy enigiets oor die operateur aflei, want die eerste reël is nie die hele antwoord nie. Anders noem jy die ontvangstoonbank die maatskappy.

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

Die tweede opdrag gebruik ’n resolver se eggonaam, waar die operateur een publiseer, om die bronadres te rapporteer wat dit sien. Die derde noem die bediener wat geantwoord het, wat dikwels nie die adres is wat jy opgestel het nie. Vergelyk al drie uitsette voordat jy ’n operateur neerskryf.

Geënkripteerde DNS verander wat sigbaar is, nie wie dit sien nie

DNS over HTTPS en DNS over TLS beskerm die uitruiling tussen kliënt en resolver. Die resolver lees steeds elke naam waarvoor gevra word, want antwoord is die werk. Wat verander, is wie die uitruiling kan dophou: die plaaslike netwerk sien ’n verbinding na een eindpunt eerder as ’n stroom gewone-teks-navrae.

Wat nie verander nie, is die vertrouensverhouding, wat steeds wys na watter organisasie ook al daardie eindpunt bestuur. ’n Blaaier met sy eie instelling vir veilige DNS kan die bedryfstelsel se resolver heeltemal omseil. Behandel dit as twee konfigurasies wat kan verskil, eerder as as een instelling wat twee keer toegepas word.

Private name het weer hulle eie besluit nodig. ’n Werktunnel kan geselekteerde domeine na organisasie-resolvers lei, en om dit met ’n openbare diens te vervang kan interne opsoektogte breek of interne name aan die verkeerde party openbaar. Kontroleer die domeinbeleid voordat jy ’n hele adapter se instellings vervang.

Hou die waarneming smal

Wanneer jy wel vergelyk, bewaar die ou konfigurasie en verander een instelling op ’n slag. Teken die toepassing, die bewerking, die resolver-beleid en of openbare en toegelate private name na ’n herverbinding nog oplos, aan. ’n Vergelyking met twee veranderinge daarin bewys nie een van die twee nie. Skryf die resultaat waar die volgende persoon dit sal vind, langs die instelling self.

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

As die toepassing begin werk, hou die bewering so klein as wat die bewyse toelaat. Daardie verandering het een toets gehelp, en dit sê niks oor of die vorige resolver te kwader trou opgetree het, of die tonnel stukkend was, of ’n ander toestel dieselfde vervanging nodig het nie. Die blywende resultaat is ’n konfigurasie waarvan jy die operateur en die doel kan verduidelik.