Napačen DNS prek VPN? En pooblastilni strežnik je morda zastarel

Povežite VPN in eno ime gostitelja se razreši na včerajšnji naslov ali na nič. Prekinite in spet deluje. Refleks je kriviti razreševalnik, ki ga je vsilil tunel, vendar je pogostejši vzrok objavljeni imenski strežnik, ki je prenehal prejemati posodobitve območja. Nova pot je preprosto dosegla drug pooblastitelj kot tisti, iz katerega je prišel vaš predpomnjeni odgovor.

Simptom se spreminja z razreševalnikom

Rekurzivni razreševalnik vrne, kar mu je povedal pooblastitelj, nato pa ta odgovor hrani do izteka TTL. Če tunel vsili drug razreševalnik ali spremeni pot tako, da stari ni več dosegljiv, odjemalec vpraša drugega pooblastitelja in dobi drug odgovor. Domena se v tistem trenutku ni spremenila; spremenil se je vaš pogled nanjo.

Zato lahko isto ime deluje v eni pisarni in odpove iz hotela, in zato brisanje lokalnega predpomnilnika pomaga le včasih. Brisanje predpomnilnika pošlje vprašanje spet istemu pooblastitelju.

Razlikovalni preizkus je neposredna poizvedba na vsak objavljeni strežnik.

Vprašajte vsakega pooblastitelja neposredno

Začnite pri delegaciji, ne pri seznamu, ki se ga spomnite. Vprašajte nadrejeni strežnik za nabor NS, nato povprašajte vsako ime iz tega nabora za zapis, ki ga potrebujete. Dve poizvedbi za isto ime pri različnih pooblastiteljih takoj povesta, ali je območje skladno.

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

Enako storite za zapise NS na vrhu območja, ker se delegacija nadrejenega strežnika in lastni nabor NS območja po selitvi lahko razlikujeta. Serijske številke v SOA so naslednja stvar za primerjavo, sekundarni strežnik, ki močno zaostaja, pa je problem prenosa, ne odgovora.

Te poizvedbe izvajajte iz omrežja, ki odpove, ne le s svoje pisalne mize.

Ločite predvidene poglede od pokvarjenih

Nekatere domene namerno odgovarjajo drugače glede na regijo ali skupino razreševalnikov, nastavitve z razdeljenim obzorjem pa so v podjetniških omrežjih običajne.

Vprašanje je, ali je razlika dokumentirana in stabilna. Nepredviden pogled je videti drugače: en pooblastitelj ima zapis, ki ga drugi niso nikoli prejeli, ali mu manjka tisti, ki ga vsi delijo. Smernice RFC 2182 za izbiro in uvajanje obravnavajo pooblastilno razpoložljivost kot skupno odgovornost in to je tu pravi okvir. Redundanca obstaja le, če lahko vsak objavljeni strežnik odgovori s predvidenimi podatki, ne le da sprejme povezavo na vratih 53.

Strežnik, ki odgovori SERVFAIL, je lažje diagnosticirati kot tistega, ki odgovori samozavestno in napačno.

Selitev razkrije, kaj je predpomnilnik skrival

Ob menjavi ponudnika se spremenita dve pooblastilni mesti: delegacija nadrejenega strežnika in lastni zapisi NS območja. Oba je treba posodobiti in oba se predpomnita za svoje TTL. Če stari strežnik ostane vklopljen in še naprej streže prejšnje območje, bodo odjemalci, katerih razreševalniki ga sprašujejo, še dolgo po tem, ko je prehod izgledal končan, prejemali stari odgovor.

Točno to stanje skriva dolgotrajen predpomnilnik. Delovna postaja, ki je delovala ves teden, je govorila z razreševalnikom, ki je imel svež odgovor novega pooblastitelja, medtem ko je stari še naprej delil zastarele podatke vsem ostalim.

Menjava razreševalnika na prenosniku popravi ta prenosnik in nič drugega.

Popravite območje, ne razreševalnika

Ugotovite, kateri strežniki naj bodo pooblastilni za območje, popravite upravljano območje ali delegacijo tako, da vsak od njih streže predvidene podatke, in ohranite načrtovano redundanco. Brisanje imenskega strežnika zato, ker je en izhod VPN prejel čuden odgovor, zmanjša razpoložljivost in pusti nedoslednost na mestu.

Nato znova izvedite neposredne poizvedbe iz obeh omrežij in počakajte, da poteče TTL zapisa, ki ste ga spremenili.

Potrdite, da je odgovor stabilen iz vsakega pooblastitelja, in zapišite predvideni pogled v dokumentacijo območja, da bo naslednjo razliko mogoče zlahka razvrstiti.