Sino ang nagpapatakbo ng 1.1.1.1? Pagsuri sa isang DNS address bago ito pagkatiwalaan

Idinikit mo ang 1.1.1.1 sa field ng DNS ng VPN, nag-load ang pahina, at mukhang kumpirmado na ang tutorial. Ang obserbasyong iyon ay mas makitid kaysa sa pakiramdam: kumilos nang iba ang application, at wala pang sinasabi ang pagbabago tungkol sa kung sino ang sumagot sa query o bakit nabigo ang lumang kaayusan. Ang kinopyang tutorial ay madalas tawagin ang isang pamilyar na pampublikong address na “DNS ng VPN”, at iyon ay isang pag-aangkin tungkol sa pagmamay-ari, hindi tungkol sa maabot. Ang pagsuri kung ano ang kinakatawan ng address ay tumatagal ng limang minuto at pumipigil sa permanenteng pagbabagong ginawa sa maling dahilan.

Ang gumaganang setting ay hindi pagkakakilanlan

Ang address sa field ng setting ay isang endpoint, at ang endpoint ay may operator. Ang dalawang katotohanang iyon ay hiwalay, at ang pangalawa ang nilalaktawan ng mga tao. Para sa pares na pinakamadalas kopyahin, ang sagot ay pampubliko: ipinapahayag ng Cloudflare ang 1.1.1.1 at 1.0.0.1 bilang mga address ng resolver nito at inililista ang mga ito sa opisyal na sanggunian ng mga address nito. Kaya nga ang pangalan ng operator ay nasa tabi ng address, hindi sa hiwalay na tutorial.

Ang paglalagay ng pares na iyon habang naka-on ang tunnel ay hindi ginagawang operator nito ang kumpanya ng VPN at hindi ginagawang anonymous ang trapiko. Ang query ay lumalabas sa iyong makina patungo sa isang kumpanyang naglalathala ng saklaw ng address, at ang kumpanyang iyon ay maaaring kagalang-galang at gayon pa man ay hindi ang partidong ipinahiwatig ng tutorial. Ang label sa mga tagubilin at ang operator sa katotohanan ay dalawang magkaibang pag-aangkin. Wala sa kanila ang nagsasabi kung sino ang nagpapatakbo ng network path sa pagitan.

Gamitin ang sariling inilathalang sanggunian ng resolver upang kumpirmahin ang isang pares ng address o isang naka-encrypt na endpoint. Ang rekomendasyon mula sa ibang vendor ay maaaring lehitimo, at ang “inirerekomenda ng”, “naabot sa pamamagitan ng” at “pinapatakbo ng” ay naglalarawan pa rin ng tatlong magkaibang ugnayan.

Ihambing ang tatlong bagay na kailangan ng isang talaan

Ang talaang handa para sa pagsusuri ay naghihiwalay ng tatlong tanong: sino ang dapat makatanggap ng query, kung ang palitan ay payak o naka-encrypt, at aling ruta ang dapat magdala nito. Ang pangalan ng provider ay hindi makakapuno sa pangalawa o pangatlo, at ang label ng bansa ay hindi makakapuno sa alinman. Isulat ang tatlong entry bago ang pagbabago at ihambing ang mga ito pagkatapos. Ang mga entry na iyon ay hindi mapagpapalit, at ang pagtrato sa mga ito bilang isa ay kung paano nagiging dokumentasyon ang isang haka-haka.

Ang paghahambing ang nagbabago ng gumaganang setting tungo sa dokumentadong desisyon. Kung wala ito, mamanahin ng susunod na tao ang isang address na walang nakalakip na dahilan. Basahin muna ang ikatlong hanay ng talahanayan sa ibaba, dahil doon talaga tumitigil ang karamihan ng kumpiyansang paliwanag.

Ang talahanayan ay sadyang maikli. Ang punto nito ay bawat entry ay sumasagot sa ibang tanong, at walang isang field na pumupuno sa lahat ng tatlo.

Ang lokal na forwarder ay nagtatago ng tunay na pinagmulan

Ang device na naka-configure na gamitin ang router nito bilang DNS ay nakaturo sa isang forwarder. Ang address na iyon ay tumutukoy sa susunod na tatanggap ng query, hindi sa resolver na sa huli ay sumasagot dito. Ang lokal na stub resolver ay nagdaragdag ng parehong karagdagang hakbang, at madaling malito ito sa tunay na bagay dahil lumilitaw ito sa bawat output ng status.

Ang stub ay nagpapasa sa mga pinagmulan na inililista rin ng parehong output, karaniwang mas mababa. Basahin ang buong chain bago maghinuha ng anuman tungkol sa operator, dahil ang unang linya ay hindi ang buong sagot. Kung hindi, tinatawag mo ang reception na kumpanya.

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

Ang ikalawang command ay gumagamit ng echo name ng resolver, kung saan naglalathala ang operator ng isa, upang iulat ang source address na nakikita nito. Ang ikatlo ay pinangalanan ang server na sumagot, na kadalasan ay hindi ang address na na-configure mo. Ihambing ang lahat ng tatlong output bago isulat ang isang operator.

Binabago ng naka-encrypt na DNS kung ano ang nakikita, hindi kung sino ang nakakakita

Ang DNS over HTTPS at DNS over TLS ay nagpoprotekta sa palitan sa pagitan ng client at resolver. Binabasa pa rin ng resolver ang bawat pangalang itinatanong dito, dahil ang pagsagot ang trabaho nito. Ang nagbabago ay kung sino ang makakapanood ng palitan: ang lokal na network ay nakakakita ng koneksyon sa isang endpoint sa halip na daloy ng mga payak na tekstong query.

Ang hindi nagbabago ay ang ugnayan ng pagtitiwala, na nakaturo pa rin sa organisasyong nagpapatakbo ng endpoint na iyon. Ang browser na may sariling setting para sa secure na DNS ay maaaring lubusang laktawan ang resolver ng operating system. Ituring ang mga ito bilang dalawang configuration na maaaring hindi magkasundo, hindi bilang isang setting na inilapat nang dalawang beses.

Ang mga pribadong pangalan ay muli na nangangailangan ng sarili nilang desisyon. Ang work tunnel ay maaaring mag-ruta ng mga piling domain sa mga organizational resolver, at ang pagpapalit nito ng pampublikong serbisyo ay maaaring makasira ng panloob na paghahanap o magbunyag ng panloob na pangalan sa maling partido. Suriin ang patakaran sa domain bago palitan ang mga setting ng isang buong adapter.

Panatilihing makitid ang obserbasyon

Kapag naghahambing, panatilihin ang lumang configuration at baguhin ang isang setting sa isang pagkakataon. Itala ang application, operasyon, patakaran ng resolver, at kung ang pampubliko at pinahihintulutang pribadong pangalan ay nare-resolve pa pagkatapos ng muling pagkonekta. Ang paghahambing na may dalawang pagbabago ay hindi nagpapatunay sa alinman. Isulat ang resulta kung saan ito makikita ng susunod na tao, sa tabi ng setting mismo.

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

Kung magsisimulang gumana ang application, panatilihing kasing liit ng pinapayagan ng ebidensya ang pag-aangkin. Ang pagbabagong iyon ay nakatulong sa isang pagsubok, at wala itong sinasabi tungkol sa kung ang dating resolver ay kumilos nang may masamang hangarin, kung sira ang tunnel, o kung kailangan ng ibang device ang parehong kapalit. Ang matibay na resulta ay isang configuration na maaari mong ipaliwanag ang operator at layunin.