Ki üzemelteti az 1.1.1.1-et? DNS-cím ellenőrzése, mielőtt megbízunk benne

Beillesztette az 1.1.1.1-et a VPN DNS-mezőjébe, az oldal betöltődött, és az útmutató most megerősítettnek tűnik. Ez a megfigyelés szűkebb, mint amilyennek érződik: az alkalmazás másképp viselkedett, és a változás még semmit nem mond arról, ki válaszolt a lekérdezésre, vagy miért bukott meg a régi elrendezés. Egy lemásolt útmutató gyakran „a VPN DNS-ének” nevez egy ismert nyilvános címet, ami tulajdonra vonatkozó állítás, nem elérhetőségre. Annak ellenőrzése, mit jelent a cím, öt percet vesz igénybe, és megakadályoz egy rossz okból tett tartós változtatást.

A működő beállítás nem identitás

A beállítási mezőben lévő cím egy végpont, és a végpontnak van üzemeltetője. Ez a két tény különálló, és a másodikat szokták kihagyni. A leggyakrabban másolt pár esetében a válasz nyilvános: a Cloudflare 1.1.1.1 és 1.0.0.1 címet teszi közzé feloldójaként, és felsorolja őket a hivatalos címjegyzékében. Ezért az üzemeltető neve a cím mellé tartozik, nem egy külön útmutatóba.

A pár beírása aktív alagút mellett nem teszi a VPN-vállalatot annak üzemeltetőjévé, és nem teszi a forgalmat névtelenné. A lekérdezés elhagyja a gépét egy cég felé, amely a címtartományt közzéteszi, és az a cég lehet jó hírű, és mégsem az a fél, amelyre az útmutató utalt. Az utasításokban szereplő címke és a valós üzemeltető két különböző állítás. Egyik sem mondja meg, ki üzemelteti a köztes hálózati útvonalat.

Használja a feloldó saját közzétett jegyzékét egy cím- vagy egy titkosított végpont megerősítésére. Egy másik szállító ajánlása lehet jogszerű, és az „ajánlotta”, az „elérés ezen át” és az „üzemelteti” továbbra is három különböző viszonyt ír le.

Hasonlítsa össze a három dolgot, amelyre egy rekordnak szüksége van

A felülvizsgálatra kész rekord három kérdést választ szét: kinek kell megkapnia a lekérdezést, a csere nyílt-e vagy titkosított, és melyik útvonal vigye. Egy szolgáltató neve nem töltheti ki a másodikat vagy a harmadikat, és egy országcímke egyiket sem. Írja le a három bejegyzést a változtatás előtt, és hasonlítsa össze őket utána. Ezek a bejegyzések nem cserélhetők fel, és egyként kezelésük az, ahogy egy feltevés dokumentációvá válik.

Az összehasonlítás az, ami a működő beállítást dokumentált döntéssé teszi. Nélküle a következő ember indok nélküli címet örököl. Először az alábbi táblázat harmadik oszlopát olvassa el, mert valójában itt állnak meg a legtöbb magabiztos magyarázatok.

A táblázat szándékosan rövid. A lényege, hogy minden bejegyzés más kérdésre válaszol, és egyetlen mező sem tölti ki mindhármat.

Egy helyi továbbító elrejti a valódi forrást

Az az eszköz, amely úgy van beállítva, hogy az útválasztóját használja DNS-ként, egy továbbítóra mutat. Az a cím a lekérdezés következő címzettjét azonosítja, nem azt a feloldót, amely végül válaszol rá. Egy helyi stub feloldó ugyanezt a plusz lépést adja hozzá, és könnyű összetéveszteni a valódi dologgal, mert minden állapotkimenetben megjelenik.

A stub azokhoz a forrásokhoz továbbít, amelyeket ugyanez a kimenet szintén felsorol, általában lejjebb. Olvassa el a teljes láncot, mielőtt bármit megállapítana az üzemeltetőről, mert az első sor nem a teljes válasz. Különben a recepciót nevezi a cégnek.

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

A második parancs egy feloldó visszhangnevét használja, ahol az üzemeltető közzétesz egyet, hogy jelentse az általa látott forráscímet. A harmadik megnevezi a válaszoló kiszolgálót, ami gyakran nem az a cím, amit beállított. Hasonlítsa össze mindhárom kimenetet, mielőtt üzemeltetőt jegyez fel.

A titkosított DNS azt változtatja meg, mi látható, nem azt, ki látja

A DNS over HTTPS és a DNS over TLS védi az ügyfél és a feloldó közötti cserét. A feloldó továbbra is elolvas minden nevet, amit kérdeznek tőle, mert a válaszadás a dolga. Ami változik, az az, ki figyelheti a cserét: a helyi hálózat egy végponthoz való kapcsolatot lát a nyílt szövegű lekérdezések folyama helyett.

Ami nem változik, az a bizalmi viszony, amely továbbra is arra a szervezetre mutat, amely azt a végpontot üzemelteti. Egy saját biztonságos DNS-beállítással rendelkező böngésző teljesen megkerülheti az operációs rendszer feloldóját. Kezelje ezeket két konfigurációként, amelyek ellentmondhatnak egymásnak, és ne egy kétszer alkalmazott beállításként.

A privát neveknek ismét saját döntésre van szükségük. Egy munkaalagút kiválasztott domaineket szervezeti feloldókhoz irányíthat, és ennek nyilvános szolgáltatással való helyettesítése megtörheti a belső kereséseket, vagy rossz félnek fedhet fel belső neveket. Ellenőrizze a domain-szabályt, mielőtt egy egész adapter beállításait lecseréli.

Tartsa szűken a megfigyelést

Amikor összehasonlít, őrizze meg a régi konfigurációt, és egyszerre egy beállítást változtasson. Jegyezze fel az alkalmazást, a műveletet, a feloldó szabályát, és azt, hogy a nyilvános és az engedélyezett privát nevek feloldódnak-e még újracsatlakozás után. Egy két változtatást tartalmazó összehasonlítás egyiket sem bizonyítja. Az eredményt oda írja, ahol a következő ember megtalálja, maga a beállítás mellé.

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

Ha az alkalmazás működni kezd, tartsa az állítást olyan kicsinek, amilyet a bizonyítékok megengednek. Az a változtatás egy tesztnek segített, és semmit nem mond arról, hogy a korábbi feloldó rosszhiszeműen járt-e el, hogy az alagút el volt-e törve, vagy hogy egy másik eszköznek ugyanerre a cserére van-e szüksége. A tartós eredmény egy konfiguráció, amelynek üzemeltetőjét és célját meg tudja magyarázni.