DNS ya VPN si sahihi? Seva moja yenye mamlaka inaweza kuwa ya zamani

Unganisha VPN na jina moja la mwenyeji linatatuliwa kwa anwani ya jana, au kwa chochote. Tenganisha na inafanya kazi tena. Mwitikio wa kawaida ni kulaumu kitatuzi ambacho handaki kiliweka, lakini sababu ya kawaida zaidi ni seva ya majina iliyochapishwa iliyoacha kupokea masasisho ya eneo. Njia mpya ilifika tu mamlaka tofauti na ile ambayo jibu lako lililohifadhiwa lilitoka.

Dalili hubadilika na kitatuzi

Kitatuzi cha kurudia hurudisha kile mamlaka ilimwambia, kisha huhifadhi jibu hilo kwa TTL. Ikiwa handaki linaweka kitatuzi kingine, au linabadilisha njia kiasi kwamba kile cha zamani hakiwezi kufikiwa tena, mteja huuliza mamlaka nyingine na hupata jibu lingine. Kikoa hakikubadilika wakati huo; mtazamo wako juu yake ulibadilika.

Ndiyo sababu jina moja linaweza kufanya kazi katika ofisi moja na kushindwa kutoka hoteli, na ndiyo sababu kufuta akiba ya ndani husaidia mara chache tu. Kufuta akiba hutuma swali kwa mamlaka hiyo hiyo tena.

Jaribio la kutofautisha ni swali la moja kwa moja kwa kila seva iliyochapishwa.

Uliza kila mamlaka moja kwa moja

Anza na uhamishaji na si kwa orodha unayokumbuka. Uliza mzazi kuhusu seti ya NS, kisha uliza kila jina katika seti hiyo kwa rekodi unayohitaji. Maswali mawili kuhusu jina moja katika mamlaka tofauti hukuambia mara moja ikiwa eneo ni thabiti.

dig +short NS example.com
dig @ns1.dns.example app.example.com A
dig @ns2.dns.example app.example.com A

Fanya vivyo hivyo kwa rekodi za NS juu ya eneo, kwa sababu uhamishaji wa mzazi na seti ya NS ya eneo lenyewe vinaweza kutofautiana baada ya uhamaji. Nambari za mfululizo kwenye SOA ni jambo linalofuata la kulinganisha, na seva ya pili iliyobaki nyuma sana ni tatizo la uhamishaji, si tatizo la jibu.

Endesha maswali hayo kutoka mtandao unaoshindwa, si kutoka dawati lako tu.

Tenganisha mitazamo iliyokusudiwa na iliyovunjika

Baadhi ya vikoa hujibu kwa makusudi tofauti kulingana na eneo au kundi la vitatuzi, na mipangilio ya upeo wa macho iliyogawanywa ni ya kawaida katika mitandao ya biashara.

Swali ni kama tofauti imeandikwa na ni thabiti. Mtazamo usiokusudiwa unaonekana tofauti: mamlaka moja ina rekodi ambayo wengine hawakupata kamwe, au inakosa moja ambayo wote wanashiriki. Mwongozo wa RFC 2182 wa uteuzi na usambazaji unachukulia upatikanaji wa mamlaka kama jukumu la pamoja, na hii ndiyo mfumo sahihi hapa. Upungufu wa nakala upo tu ikiwa kila seva iliyochapishwa inaweza kujibu kwa data iliyokusudiwa, si kukubali tu muunganisho kwenye lango 53.

Seva inayojibu SERVFAIL ni rahisi kugundua kuliko inayojibu kwa kujiamini na kwa makosa.

Uhamaji hufichua kile akiba ilichoficha

Wakati wa kubadilisha mtoa huduma, maeneo mawili ya mamlaka hubadilika: uhamishaji wa mzazi na rekodi za NS za eneo lenyewe. Yote mawili lazima yasasishwe, na yote mawili huhifadhiwa kwa TTL zao. Ikiwa seva ya zamani inabaki hai na inaendelea kutoa eneo la awali, wateja ambao vitatuzi vyao vinauliza itaendelea kupata jibu la zamani muda mrefu baada ya mabadiliko kuonekana kukamilika.

Hiyo ndiyo hali ambayo akiba ya muda mrefu huficha. Kituo cha kazi kilichofanya kazi wiki nzima kilikuwa kikizungumza na kitatuzi kilichokuwa na jibu jipya kutoka mamlaka mpya, wakati cha zamani kiliendelea kugawanya data za zamani kwa kila mtu mwingine.

Kubadilisha kitatuzi kwenye kompyuta ya mkononi hurekebisha kompyuta hiyo na hakuna kingine.

Rekebisha eneo, si kitatuzi

Tambua ni seva zipi zinazopaswa kuwa na mamlaka kwa eneo, rekebisha eneo linalosimamiwa au uhamishaji ili kila moja yao itoe data iliyokusudiwa, na weka upungufu wa nakala uliouipanga. Kufuta seva ya majina kwa sababu mlango mmoja wa VPN ulipata jibu la ajabu hupunguza upatikanaji na huacha kutokwenda sambamba mahali pake.

Kisha endesha tena maswali ya moja kwa moja kutoka mitandao yote mawili na subiri TTL ya rekodi uliyobadilisha iishe.

Thibitisha kwamba jibu ni thabiti kutoka kila mamlaka, na andika mtazamo uliokusudiwa katika nyaraka za eneo ili tofauti inayofuata iwe rahisi kuainisha.