Ĉu VPN-DNS malĝustas? Unu aŭtoritata servilo povas esti malnova

Konektu la VPN kaj unu gastigantnomo solviĝas al la hieraŭa adreso, aŭ al nenio. Malkonektu kaj ĝi denove funkcias. La reflekso estas kulpigi la solvilon, kiun la tunelo enmetis, sed la pli ofta kaŭzo estas publikigita noma servilo, kiu ĉesis ricevi ĝisdatigojn de la zono. La nova vojo simple atingis alian aŭtoritatan fonton ol tiu, el kiu venis via kaŝmemorigita respondo.

La simptomo ŝanĝiĝas kun la solvilo

Ripeta solvilo redonas tion, kion diris al ĝi aŭtoritata fonto, kaj poste konservas tiun respondon dum la TTL. Se la tunelo enmetas alian solvilon, aŭ ŝanĝas la vojon tiel ke la malnova ne plu atingeblas, la kliento demandas alian aŭtoritatan fonton kaj ricevas alian respondon. La domajno ne ŝanĝiĝis en tiu momento; via vido al ĝi ŝanĝiĝis.

Tial la sama nomo povas funkcii en unu oficejo kaj malsukcesi el hotelo, kaj tial viŝado de loka kaŝmemoro nur foje helpas. Viŝi la kaŝmemoron resendas la demandon al la sama aŭtoritata fonto.

La distinga testo estas rekta demando al ĉiu publikigita servilo.

Demandu ĉiun aŭtoritatan fonton rekte

Komencu per la delegado, ne per listo, kiun vi memoras. Demandu la gepatro pri la NS-aro, poste demandu ĉiun nomon en tiu aro pri la rikordo, kiu gravas al vi. Du demandoj pri la sama nomo ĉe malsamaj aŭtoritataj fontoj tuj diras, ĉu la zono estas konsekvenca.

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

Faru la samon por la NS-rikordoj ĉe la pinto de la zono, ĉar la delegado de la gepatro kaj la propra NS-aro de la zono povas malkonsenti post migrado. Serialaj numeroj en la SOA estas la sekva afero komparinda, kaj sekundara servilo multe malantaŭe estas transiga problemo, ne responda problemo.

Rulu tiujn demandojn el la reto, kiu malsukcesas, ne nur de via labortablo.

Apartigu celitajn vidojn de rompitaj

Kelkaj domajnoj intence respondas malsame laŭ regiono aŭ solvila grupo, kaj agordoj de dividita horizonto estas normalaj en entreprenaj retoj.

La demando estas, ĉu la diferenco estas dokumentita kaj stabila. Neintenca vido aspektas malsame: unu aŭtoritata fonto havas rikordon, kiun la aliaj neniam ricevis, aŭ mankas al ĝi unu, kiun ĉiuj dividas. La gvidilo RFC 2182 pri elekto kaj deplojo traktas aŭtoritatan haveblecon kiel komunan respondecon, kaj tio estas la ĝusta kadro ĉi tie. Redundo ekzistas nur se ĉiu publikigita servilo povas respondi la celitajn datumojn, ne simple akcepti konekton sur pordo 53.

Servilo, kiu respondas SERVFAIL, estas pli facile diagnozebla ol tiu, kiu respondas memfide kaj malĝuste.

Migrado malkaŝas tion, kion kaŝmemoro kaŝis

Dum provizantoŝanĝo ŝanĝiĝas du aŭtoritataj lokoj: la delegado de la gepatro kaj la propraj NS-rikordoj de la zono. Ambaŭ devas esti ĝisdatigitaj, kaj ambaŭ estas kaŝmemorigitaj por siaj TTL-oj. Se malnova servilo restas funkcianta kaj daŭre servas la antaŭan zonon, klientoj, kies solviloj demandas ĝin, daŭre ricevos la malnovan respondon longe post kiam la transiro ŝajnis kompleta.

Ĝuste tiun staton kaŝas longdaŭra kaŝmemoro. La laborstacio, kiu funkciis la tutan semajnon, parolis kun solvilo tenanta freŝan respondon de la nova aŭtoritata fonto, dum la malnova daŭre disdonis malnovajn datumojn al ĉiuj aliaj.

Ŝanĝi la solvilon sur tekkomputilo riparas tiun tekkomputilon kaj nenion alian.

Riparu la zonon, ne la solvilon

Identigu, kiuj serviloj estu aŭtoritataj por la zono, korektu la administritan zonon aŭ la delegadon tiel ke ĉiu el ili servu la celitajn datumojn, kaj konservu la redundon, kiun vi planis. Forigi noman servilon ĉar unu VPN-eliro ricevis strangan respondon malpliigas haveblecon kaj lasas la malkonsekvencon surloke.

Poste rulu la rektajn demandojn denove el ambaŭ retoj kaj atendu la finiĝon de la TTL de la rikordo, kiun vi ŝanĝis.

Konfirmu, ke la respondo estas stabila el ĉiu aŭtoritata fonto, kaj skribu la celitan vidon en la zona dokumentaro, por ke la sekva diferenco estu facile klasifikebla.