Nani anaendesha 1.1.1.1? Kukagua anwani ya DNS kabla ya kuiamini
Anwani ya DNS inayotumika pamoja na VPN si lazima iendeshwe na VPN hiyo. Tambua resolver, kisha kagua njia na sera ya majina ya faragha kivyake.
Ulibandika 1.1.1.1 kwenye sehemu ya DNS ya VPN, ukurasa ulipakia, na mwongozo sasa unaonekana umethibitishwa. Uchunguzi huo ni mwembamba kuliko unavyohisi: programu ilijibu tofauti, na mabadiliko bado hayasemi chochote kuhusu nani alijibu swali au kwa nini mpangilio wa zamani ulishindwa. Mwongozo ulionakiliwa mara nyingi huita anwani maarufu ya umma “DNS ya VPN”, na hilo ni dai kuhusu umiliki, si kuhusu ufikivu. Kukagua anwani inawakilisha nini huchukua dakika tano na huzuia mabadiliko ya kudumu yaliyofanywa kwa sababu isiyofaa.
Mpangilio unaofanya kazi si utambulisho
Anwani iliyo kwenye sehemu ya mipangilio ni mwisho wa muunganisho, na mwisho wa muunganisho una mwendeshaji. Mambo hayo mawili ni tofauti, na la pili ni lile ambalo watu huliruka. Kwa jozi inayonakiliwa mara nyingi zaidi, jibu ni la umma: Cloudflare huchapisha 1.1.1.1 na 1.0.0.1 kama anwani zake za resolver, na huziorodhesha katika marejeleo rasmi ya anwani. Ndiyo sababu jina la mwendeshaji linakaa kando ya anwani, si katika mwongozo tofauti.
Kuingiza jozi hiyo wakati handaki iko juu hakufanyi kampuni ya VPN kuwa mwendeshaji wake, na hakufanyi trafiki kuwa isiyojulikana. Swali huondoka kwenye mashine yako kwenda kwa kampuni inayochapisha kiwango cha anwani, na kampuni hiyo inaweza kuwa na sifa nzuri na bado isiwe upande ambao mwongozo ulidokeza. Lebo iliyo kwenye maelekezo na mwendeshaji halisi ni madai tofauti. Hakuna hata moja inayosema nani anaendesha njia ya mtandao katikati.
Tumia marejeleo yaliyochapishwa ya resolver yenyewe kuthibitisha jozi ya anwani au mwisho uliosimbwa. Pendekezo kutoka kwa mtoa huduma mwingine linaweza kuwa halali, na “imependekezwa na”, “imefikiwa kupitia” na “inaendeshwa na” bado zinaelezea mahusiano matatu tofauti.
Linganisha mambo matatu ambayo rekodi inahitaji
Rekodi iliyo tayari kwa ukaguzi hutenganisha maswali matatu: nani anapaswa kupokea swali, kama mabadilishano ni ya wazi au yamesimbwa, na njia ipi inapaswa kuibeba. Jina la mtoa huduma haliwezi kujaza la pili au la tatu, na lebo ya nchi haiwezi kujaza lolote kati yao. Andika maingizo matatu kabla ya mabadiliko na uyalinganishe baadaye. Maingizo hayo hayabadilishani, na kuyachukua kama moja ndiyo njia ambayo dhana inakuwa nyaraka.
Ulinganisho ndiyo unaobadilisha mpangilio unaofanya kazi kuwa uamuzi uliokwisha kuandikwa. Bila huo, mtu anayefuata hurithi anwani isiyo na sababu yoyote iliyoambatishwa. Soma kwanza safu ya tatu ya jedwali lililo hapa chini, kwa sababu hapo ndipo maelezo mengi ya kujiamini huishia kwa kweli.
| 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 |
Jedwali ni fupi kwa makusudi. Hoja ni kwamba kila ingizo hujibu swali tofauti, na hakuna sehemu moja inayojaza yote matatu.
Kipitishaji cha ndani huficha chanzo halisi
Kifaa kilichowekwa kutumia router yake kama DNS kinaelekeza kwa kipitishaji. Anwani hiyo hutambua mpokeaji anayefuata wa swali, si resolver inayoijibu hatimaye. Resolver ya stub ya ndani huongeza hatua hiyo ya ziada, na ni rahisi kuichanganya na kitu halisi kwa sababu inaonekana katika kila matokeo ya hali.
Stub hupeleka kwa vyanzo ambavyo matokeo hayo hayo pia huorodhesha, kwa kawaida chini zaidi. Soma mnyororo wote kabla ya kuhitimisha chochote kuhusu mwendeshaji, kwa sababu mstari wa kwanza si jibu lote. Vinginevyo unaita mapokezi kampuni.
resolvectl status | grep -A4 'Current DNS Server'
dig +short CH TXT whoami.cloudflare @1.1.1.1
dig example.com | grep -E '^;; SERVER'
Amri ya pili hutumia jina la mwangwi la resolver, pale mwendeshaji anapochapisha moja, kuripoti anwani ya chanzo inayoiona. Ya tatu hutaja seva iliyojibu, ambayo mara nyingi si anwani uliyoisanidi. Linganisha matokeo yote matatu kabla ya kuandika mwendeshaji.
DNS iliyosimbwa hubadilisha kinachoonekana, si nani anaiona
DNS over HTTPS na DNS over TLS hulinda mabadilishano kati ya mteja na resolver. Resolver bado husoma kila jina linaloombwa, kwa sababu kujibu ni kazi. Kinachobadilika ni nani anayeweza kutazama mabadilishano: mtandao wa ndani unaona muunganisho kwa mwisho mmoja badala ya mtiririko wa maswali ya maandishi wazi.
Kinachobadilika si uhusiano wa uaminifu, ambao bado unaelekeza kwa shirika lolote linaloendesha mwisho huo. Kivinjari kilicho na mpangilio wake wa DNS salama kinaweza kukwepa resolver ya mfumo wa uendeshaji kabisa. Vichukue kama mipangilio miwili inayoweza kutofautiana, si kama mpangilio mmoja unaotumika mara mbili.
Majina ya faragha yanahitaji uamuzi wake tena. Handaki la kazi linaweza kuelekeza vikoa vilivyochaguliwa kwa resolver za shirika, na kuibadilisha na huduma ya umma kunaweza kuvunja utafutaji wa ndani au kufichua majina ya ndani kwa upande usiofaa. Kagua sera ya vikoa kabla ya kubadilisha mipangilio ya adapta nzima.
Weka uchunguzi mwembamba
Unapolinganisha, hifadhi mpangilio wa zamani na ubadilishe mpangilio mmoja kwa wakati. Andika programu, operesheni, sera ya resolver, na kama majina ya umma na ya faragha yanayoruhusiwa bado yanatatuliwa baada ya kuunganisha tena. Ulinganisho wenye mabadiliko mawili hauthibitishi hata moja. Andika matokeo mahali mtu anayefuata atapata, kando ya mpangilio wenyewe.
resolvectl query intranet.corp.example
resolvectl domain
dig +short @1.1.1.1 example.com
Ikiwa programu itaanza kufanya kazi, weka dai dogo kadri ushahidi unavyoruhusu. Mabadiliko hayo yalisaidia jaribio moja, na hayasemi chochote kuhusu kama resolver ya awali ilitenda kwa nia mbaya, kama handaki lilikuwa limevunjika, au kama kifaa kingine kinahitaji ubadilishaji huo. Matokeo ya kudumu ni mpangilio ambao mwendeshaji na madhumuni yake unaweza kuyaeleza.