Kiu funkciigas 1.1.1.1? Kontroli DNS-adreson antaŭ ol fidi ĝin

Vi algluis 1.1.1.1 en la DNS-kampon de la VPN, la paĝo ŝargiĝis, kaj la lernilo nun ŝajnas konfirmita. Tiu observo estas pli mallarĝa ol ĝi sentiĝas: la aplikaĵo kondutis alie, kaj la ŝanĝo ankoraŭ diras nenion pri tio, kiu respondis la demandon aŭ kial la malnova aranĝo malsukcesis. Kopiita lernilo ofte nomas konatan publikan adreson «la DNS de la VPN», kaj tio estas aserto pri posedo, ne pri atingeblo. Kontroli, kion reprezentas la adreso, daŭras kvin minutojn kaj malhelpas permanentan ŝanĝon faritan pro la malĝusta kialo.

Funkcianta agordo ne estas identeco

La adreso en agorda kampo estas finpunkto, kaj finpunkto havas funkciiganton. Tiuj du faktoj estas apartaj, kaj la dua estas tiu, kiun homoj preterlasas. Por la paro plej ofte kopiata, la respondo estas publika: Cloudflare publikigas 1.1.1.1 kaj 1.0.0.1 kiel la adresojn de sia solvilo kaj listigas ilin en sia oficiala adresreferenco. Tial la nomo de la funkciiganto apartenas apud la adreso, ne en aparta lernilo.

Entajpi tiun paron dum tunelo estas aktiva ne faras la VPN-firmaon ĝia funkciiganto kaj ne faras la trafikon anonima. La demando forlasas vian maŝinon al firmao, kiu publikigas la adresan aron, kaj tiu firmao povas esti respektata kaj tamen ne esti la partio, kiun la lernilo sugestis. La etikedo en la instrukcioj kaj la funkciiganto en la realo estas du malsamaj asertoj. Neniu el ili diras, kiu funkciigas la interan retvojon.

Uzu la propran publikigitan referencon de la solvilo por konfirmi adresparon aŭ ĉifritan finpunkton. Rekomendo de alia vendisto povas esti laŭleĝa, kaj «rekomendita de», «atingita tra» kaj «funkciigata de» ankoraŭ priskribas tri malsamajn rilatojn.

Komparu la tri aferojn, kiujn rikordo bezonas

Rikordo preta por revizio apartigas tri demandojn: kiu devus ricevi la demandon, ĉu la interŝanĝo estas simpla aŭ ĉifrita, kaj kiu vojo devus porti ĝin. Provizanta nomo ne povas plenigi la duan aŭ la trian, kaj landa etikedo ne povas plenigi iun ajn el ili. Skribu la tri enskribojn antaŭ la ŝanĝo kaj komparu ilin poste. Tiuj enskriboj ne estas interŝanĝeblaj, kaj trakti ilin kiel unu estas la maniero, kiel konjekto fariĝas dokumentado.

Ĝuste la komparo transformas funkciantan agordon en dokumentitan decidon. Sen ĝi, la sekva persono heredas adreson sen iu ajn ligita kialo. Legu unue la trian kolumnon de la suba tabelo, ĉar tie la plej multaj memcertaj klarigoj efektive haltas.

La tabelo estas intence mallonga. Ĝia punkto estas, ke ĉiu enskribo respondas al malsama demando kaj neniu unuopa kampo plenigas ĉiujn tri.

Loka plusendilo kaŝas la veran fonton

Aparato agordita uzi sian enkursigilon kiel DNS montras al plusendilo. Tiu adreso identigas la sekvan ricevanton de la demando, ne la solvilon, kiu finfine respondas ĝin. Loka stub-solvilo aldonas la saman plian paŝon, kaj facile estas konfuzi ĝin kun la vera afero, ĉar ĝi aperas en ĉiu statussignalo.

La stub-plusendilo plusendas al fontoj, kiujn la sama signalo ankaŭ listigas, kutime pli malsupre. Legu la tutan ĉenon antaŭ ol fari iun ajn konkludon pri la funkciiganto, ĉar la unua linio ne estas la tuta respondo. Alie vi nomas la akceptejon la firmao.

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

La dua komando uzas eĥan nomon de solvilo, kie la funkciiganto publikigas unu, por raporti la fontan adreson, kiun ĝi vidas. La tria nomas la servilon, kiu respondis, kaj tio ofte ne estas la adreso, kiun vi agordis. Komparu ĉiujn tri eligojn antaŭ ol noti funkciiganton.

Ĉifrita DNS ŝanĝas, kio estas videbla, ne kiu vidas ĝin

DNS over HTTPS kaj DNS over TLS protektas la interŝanĝon inter kliento kaj solvilo. La solvilo ankoraŭ legas ĉiun nomon pri kiu ĝi estas demandata, ĉar respondi estas ĝia laboro. Kio ŝanĝiĝas estas, kiu povas observi la interŝanĝon: la loka reto vidas konekton al unu finpunkto anstataŭ fluon de demandoj en klara teksto.

Kio ne ŝanĝiĝas estas la fida rilato, kiu ankoraŭ montras al la organizo, kiu funkciigas tiun finpunkton. Retumilo kun propra agordo por sekura DNS povas tute preterpasi la solvilon de la operaciumo. Traktu ilin kiel du agordojn, kiuj povas malkonsenti, ne kiel unu agordon aplikitan dufoje.

Privataj nomoj denove bezonas sian propran decidon. Labortunelo povas enkursigi elektitajn domajnojn al organizaj solviloj, kaj anstataŭigi tion per publika servo povas rompi internajn serĉojn aŭ malkaŝi internajn nomojn al la malĝusta partio. Kontrolu la domajnan politikon antaŭ ol anstataŭigi la agordojn de tuta adaptilo.

Tenu la observon mallarĝa

Kiam vi komparas, konservu la malnovan agordon kaj ŝanĝu unu agordon samtempe. Notu la aplikaĵon, la operacion, la solvilan politikon, kaj ĉu publikaj kaj permesitaj privataj nomoj ankoraŭ solviĝas post rekonekto. Komparo kun du ŝanĝoj pruvas neniun el ili. Skribu la rezulton tie, kie la sekva persono trovos ĝin, apud la agordo mem.

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

Se la aplikaĵo ekfunkcias, tenu la aserton tiel malgranda, kiel la pruvoj permesas. Tiu ŝanĝo helpis unu teston, kaj ĝi diras nenion pri tio, ĉu la antaŭa solvilo agis malbonintence, ĉu la tunelo estis rompita, aŭ ĉu alia aparato bezonas la saman anstataŭigon. La daŭra rezulto estas agordo, kies funkciiganton kaj celon vi povas klarigi.