Kdo poganja 1.1.1.1? Preverjanje naslova DNS, preden mu zaupate
Naslova DNS, ki se uporablja z VPN, ne poganja nujno ta VPN. Prepoznajte razreševalnik in nato ločeno preverite pot in politiko zasebnih imen.
Prilepili ste 1.1.1.1 v polje DNS pri VPN, stran se je naložila in vadnica je zdaj videti potrjena. Ta ugotovitev je ožja, kot se zdi: aplikacija se je obnašala drugače in sprememba še ne pove ničesar o tem, kdo je odgovoril na poizvedbo ali zakaj je stara ureditev spodletela. Prepisana vadnica pogosto imenuje znan javni naslov »DNS VPN«, kar je trditev o lastništvu, ne o dosegljivosti. Preverjanje, kaj naslov predstavlja, traja pet minut in prepreči trajno spremembo iz napačnega razloga.
Delujoča nastavitev ni identiteta
Naslov v polju nastavitev je končna točka, končna točka pa ima upravljavca. Ti dve dejstvi sta ločeni in drugo je tisto, ki ga ljudje izpustijo. Za par, ki se najpogosteje kopira, je odgovor javen: Cloudflare objavlja 1.1.1.1 in 1.0.0.1 kot naslova svojega razreševalnika in ju navaja v svojem uradnem pregledu naslovov. Zato ime upravljavca sodi ob naslov, ne v ločeno vadnico.
Vnos tega para ob aktivnem tunelu ne naredi VPN podjetja njegovega upravljavca in prometa ne naredi anonimnega. Poizvedba zapusti vaš stroj proti podjetju, ki objavlja obseg naslovov, in to podjetje je lahko ugledno in vendar ni stran, ki jo je vadnica nakazala. Oznaka v navodilih in dejanski upravljavec sta dve različni trditvi. Nobena ne pove, kdo poganja vmesno omrežno pot.
Uporabite lasten objavljen pregled razreševalnika za potrditev para naslovov ali šifrirane končne točke. Priporočilo drugega ponudnika je lahko legitimno, in »priporočeno s strani«, »doseženo prek« ter »upravljano s strani« še vedno opisujejo tri različne odnose.
Primerjajte tri stvari, ki jih zapis potrebuje
Zapis, pripravljen na pregled, loči tri vprašanja: kdo naj prejme poizvedbo, ali je izmenjava odprta ali šifrirana, in katera pot naj jo nosi. Ime ponudnika ne more izpolniti drugega ali tretjega, oznaka države pa ne more izpolniti nobenega od njih. Zapišite tri vnose pred spremembo in jih primerjajte po njej. Ti vnosi niso zamenljivi, in obravnavanje kot enega je način, kako domneva postane dokumentacija.
Prav primerjava spremeni delujočo nastavitev v dokumentirano odločitev. Brez nje naslednja oseba podeduje naslov brez kakršnega koli priloženega razloga. Najprej preberite tretji stolpec spodnje tabele, ker se tam večina samozavestnih razlag v resnici ustavi.
| 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 |
Tabela je namerno kratka. Njen smisel je, da vsak vnos odgovarja na drugo vprašanje in nobeno posamezno polje ne izpolni vseh treh.
Lokalni posredovalnik skrije pravi vir
Naprava, nastavljena tako, da uporablja usmerjevalnik kot DNS, kaže na posredovalnik. Ta naslov določa naslednjega prejemnika poizvedbe, ne razreševalnika, ki nanjo na koncu odgovori. Lokalni stub razreševalnik doda isto dodatno stopnjo, in z njim ga je lahko zamenjati, ker se pojavi v vsakem izpisu stanja.
Stub posreduje naprej virom, ki jih isti izpis tudi navaja, običajno niže. Preberite celotno verigo, preden karkoli sklepate o upravljavcu, ker prva vrstica ni cel odgovor. Sicer imenujete recepcijo podjetje.
resolvectl status | grep -A4 'Current DNS Server'
dig +short CH TXT whoami.cloudflare @1.1.1.1
dig example.com | grep -E '^;; SERVER'
Drugi ukaz uporablja odmevno ime razreševalnika, kjer ga upravljavec objavi, da poroča o izvornem naslovu, ki ga vidi. Tretji poimenuje strežnik, ki je odgovoril, in to pogosto ni naslov, ki ste ga nastavili. Primerjajte vse tri izpise, preden zapišete upravljavca.
Šifrirani DNS spremeni, kaj je vidno, ne kdo to vidi
DNS over HTTPS in DNS over TLS zaščitita izmenjavo med odjemalcem in razreševalnikom. Razreševalnik še vedno prebere vsako ime, po katerem ga vprašajo, ker je odgovarjanje njegovo delo. Spremeni se, kdo lahko spremlja izmenjavo: lokalno omrežje vidi povezavo do ene končne točke namesto toka poizvedb v čistem besedilu.
Kar se ne spremeni, je razmerje zaupanja, ki še vedno kaže na organizacijo, ki poganja to končno točko. Brskalnik z lastno nastavitvijo varnega DNS lahko popolnoma obide razreševalnik operacijskega sistema. Obravnavajte ju kot dve konfiguraciji, ki si lahko nasprotujeta, ne kot eno nastavitev, uporabljeno dvakrat.
Zasebna imena znova potrebujejo svojo odločitev. Delovni tunel lahko usmeri izbrane domene na organizacijske razreševalnike, in zamenjava z javno storitvijo lahko zlomi notranja iskanja ali razkrije notranja imena napačni strani. Preverite politiko domen, preden zamenjate nastavitve celega adapterja.
Ohranite ugotovitev ozko
Ko primerjate, ohranite staro konfiguracijo in spreminjajte eno nastavitev naenkrat. Zabeležite aplikacijo, operacijo, politiko razreševalnika in ali se javna ter dovoljena zasebna imena po ponovni povezavi še razrešujejo. Primerjava z dvema spremembama ne dokaže nobene od njiju. Rezultat zapišite tja, kjer ga bo našla naslednja oseba, ob sami nastavitvi.
resolvectl query intranet.corp.example
resolvectl domain
dig +short @1.1.1.1 example.com
Če aplikacija začne delovati, držite trditev tako majhno, kot dopuščajo dokazi. Ta sprememba je pomagala enemu testu in ne pove ničesar o tem, ali je prejšnji razreševalnik ravnal slaboverno, ali je bil tunel pokvarjen, ali druga naprava potrebuje isto zamenjavo. Trajen rezultat je konfiguracija, katere upravljavca in namen lahko pojasnite.