Mali ba ang DNS ng VPN? Maaaring luma na ang isang awtoritatibong server

Kumonekta sa VPN at nagreresolba ang isang hostname sa address ng kahapon, o sa wala. Humiwalay at gumagana itong muli. Ang pinakaunang reaksyon ay sisihin ang resolver na itinulak ng tunnel, ngunit ang mas karaniwang dahilan ay isang nailathalang nameserver na tumigil sa pagtanggap ng mga update ng zone. Ang bagong landas ay nakarating lamang sa ibang awtoridad kaysa sa pinagmulan ng iyong naka-cache na sagot.

Nagbabago ang sintomas kasama ng resolver

Ang isang recursive resolver ay nagbabalik ng sinabi ng isang awtoridad, pagkatapos ay pinapanatili ang sagot na iyon sa loob ng TTL. Kung ang tunnel ay nagtutulak ng ibang resolver, o binabago ang landas upang hindi na maabot ang luma, magtatanong ang kliyente sa ibang awtoridad at makakakuha ng ibang sagot. Hindi nagbago ang domain sa sandaling iyon; ang pananaw mo rito ang nagbago.

Ito ang dahilan kung bakit ang parehong pangalan ay maaaring gumana sa isang opisina at mabigo mula sa isang hotel, at kung bakit ang paglilinis ng lokal na cache ay nakakatulong lamang kung minsan. Ang paglilinis ng cache ay muling nagpapadala ng tanong sa parehong awtoridad.

Ang natatanging pagsubok ay isang direktang query sa bawat nailathalang server.

Tanungin ang bawat awtoridad nang direkta

Magsimula sa delegasyon at hindi sa isang listahang natatandaan mo. Tanungin ang magulang tungkol sa set ng NS, pagkatapos ay i-query ang bawat pangalan sa set na iyon para sa record na kailangan mo. Ang dalawang query sa parehong pangalan sa magkaibang awtoridad ay agad na nagsasabi kung pare-pareho ang zone.

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

Gawin din ito para sa mga NS record sa tuktok ng zone, dahil ang delegasyon ng magulang at ang sariling set ng NS ng zone ay maaaring magkaiba pagkatapos ng migrasyon. Ang mga serial number sa SOA ang susunod na ihahambing, at ang isang sekondaryang naiwan nang malayo ay problema sa transfer, hindi sa sagot.

Patakbuhin ang mga query na iyon mula sa network na nabigo, hindi lamang mula sa iyong mesa.

Ihiwalay ang mga sinadyang pananaw sa mga sira

Ang ilang domain ay sadyang sumasagot nang iba ayon sa rehiyon o grupo ng resolver, at ang mga split-horizon na setup ay normal sa mga corporate network.

Ang tanong ay kung ang pagkakaiba ay nakadokumento at matatag. Ang hindi sinasadyang pananaw ay mukhang iba: may record ang isang awtoridad na hindi kailanman natanggap ng iba, o kulang ito ng isang pinagsasaluhan ng lahat. Itinuturing ng gabay ng RFC 2182 sa pagpili at pag-deploy ang awtoritatibong pagkakaroon bilang pinagsamang responsibilidad, at iyon ang tamang balangkas dito. Umiiral lamang ang redundancy kung ang bawat nailathalang server ay makasasagot gamit ang sinadyang datos, hindi lamang tumatanggap ng koneksyon sa port 53.

Ang isang server na sumasagot ng SERVFAIL ay mas madaling i-diagnose kaysa sa isang tumutugon nang may kumpiyansa at mali.

Inilalantad ng migrasyon ang itinago ng cache

Sa panahon ng paglipat ng provider, dalawang awtoritatibong lokasyon ang nagbabago: ang delegasyon ng magulang at ang sariling mga NS record ng zone. Kailangang i-update ang dalawa, at ang dalawa ay naka-cache para sa kanilang TTL. Kung ang isang lumang server ay mananatiling buhay at patuloy na naghahatid ng dating zone, ang mga kliyenteng tinatanong ito ng kanilang resolver ay patuloy na makakatanggap ng lumang sagot matagal pagkatapos na ang paglipat ay tila kumpleto.

Iyan ang eksaktong kalagayang itinatago ng isang pangmatagalang cache. Ang workstation na gumana sa buong linggo ay nakikipag-usap sa isang resolver na may dalang sariwang sagot mula sa bagong awtoridad, habang ang luma ay patuloy na namimigay ng lumang datos sa lahat ng iba.

Ang pagpapalit ng resolver sa isang laptop ay nag-aayos sa laptop na iyon at wala nang iba.

Ayusin ang zone, hindi ang resolver

Tukuyin kung aling mga server ang dapat maging awtoritatibo para sa zone, itama ang pinamamahalaang zone o ang delegasyon upang ang bawat isa sa kanila ay maghatid ng sinadyang datos, at panatilihin ang redundancy na pinlano mo. Ang pagbura ng isang nameserver dahil isang labasan ng VPN ang nakakuha ng kakaibang sagot ay nagpapababa ng pagkakaroon at iniiwan ang hindi pagkakapare-pareho sa lugar nito.

Pagkatapos ay patakbuhin muli ang mga direktang query mula sa dalawang network at hintayin ang TTL ng record na binago mo na mag-expire.

Kumpirmahin na ang sagot ay matatag mula sa bawat awtoridad, at isulat ang sinadyang pananaw sa dokumentasyon ng zone upang ang susunod na pagkakaiba ay madaling maiuri.