Rangt VPN-DNS? Einn heimildarþjónn gæti verið úreltur

Tengdu VPN og eitt hýsilnafn leysist í gærdagsheimilið, eða í ekkert. Aftengdu og það virkar aftur. Viðbragðið er að kenna leysinum sem göngin ýttu inn, en algengari orsökin er birtur nafnaþjónn sem hætti að fá svæðisuppfærslur. Nýja leiðin náði einfaldlega til annars heimildaraðila en þess sem svarið í skyndiminninu kom frá.

Einkennin breytast með leysinum

Endurkvæmur leysir skilar því sem heimildaraðili sagði honum, og heldur svo því svari í TTL. Ef göngin ýta inn öðrum leysi, eða breyta leiðinni þannig að hinn gamli er ekki lengur aðgengilegur, spyr biðlarinn annan heimildaraðila og fær annað svar. Léninu breyttist ekki á þeirri stundu; þín sýn á það breyttist.

Þess vegna getur sama nafn virkað á einni skrifstofu og mistekist af hóteli, og þess vegna hjálpar að tæma staðbundið skyndiminni bara stundum. Að tæma skyndiminnið sendir spurninguna aftur til sama heimildaraðila.

Aðgreiningarprófið er bein fyrirspurn til hvers birts þjóns.

Spyrðu hvern heimildaraðila beint

Byrjaðu á framsendingunni, ekki á lista sem þú manst eftir. Spurðu foreldrið um NS-settið og spurðu svo hvert nafn í því setti um færsluna sem þig varðar. Tvær fyrirspurnir um sama nafn hjá mismunandi heimildaraðilum segja þér strax hvort svæðið er samkvæmt.

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

Gerðu það sama fyrir NS-færslurnar á toppi svæðisins, því framsending foreldrisins og eigið NS-sett svæðisins geta stangast á eftir flutning. Raðnúmer á SOA eru næst til að bera saman, og aukaaðili sem er langt á eftir er flutningsvandamál en ekki svarvandamál.

Keyrðu þessar fyrirspurnir frá netinu sem mistekst, ekki bara frá skrifborðinu þínu.

Aðskildu ætluð sjónarhorn frá brotnum

Sum lén svara viljandi öðruvísi eftir svæði eða leysihópi, og stillingar með skiptum sjóndeildarhring eru eðlilegar í fyrirtækjanetum.

Spurningin er hvort munurinn sé skjalfestur og stöðugur. Óætlað sjónarhorn lítur öðruvísi út: einn heimildaraðili hefur færslu sem hinir fengu aldrei, eða vantar þá sem allir deila. Leiðbeiningar RFC 2182 um val og uppsetningu líta á heimildarframboð sem sameiginlega ábyrgð, og það er rétti ramminn hér. Ofgnótt er aðeins til ef hver birtur þjónn getur svarað með ætluðum gögnum, ekki bara tekið við tengingu á gátt 53.

Þjónn sem svarar SERVFAIL er auðveldari að greina en sá sem svarar af öryggi og rangt.

Flutningur afhjúpar það sem skyndiminni huldi

Við skipti á veitanda breytast tveir heimildarstaðir: framsending foreldrisins og eigin NS-færslur svæðisins. Báða þarf að uppfæra, og báðir eru í skyndiminni í sinn TTL. Ef gamall þjónn heldur áfram að keyra og þjóna fyrra svæðinu munu biðlarar þeirra leysa sem spyrja hann halda áfram að fá gamla svarið löngu eftir að skiptin virtust lokið.

Þetta er einmitt ástandið sem langlíft skyndiminni hylur. Vinnustöðin sem virkaði alla vikuna var að tala við leysi sem hélt fersku svari frá nýja heimildaraðilanum, á meðan sá gamli hélt áfram að dreifa úreltum gögnum til allra annarra.

Að skipta um leysi á fartölvu laga þá fartölvu og ekkert annað.

Lagaðu svæðið, ekki leysinn

Greindu hvaða þjónar eiga að vera heimildarþjónar fyrir svæðið, leiðréttu stýrða svæðið eða framsendinguna þannig að hver þeirra þjóni ætluðum gögnum, og haltu í ofgnóttina sem þú skipulagðir. Að eyða nafnaþjóni vegna þess að ein VPN-útgangur fékk skrýtið svar dregur úr framboði og skilur ósamræmið eftir.

Keyrðu svo beinu fyrirspurnirnar aftur frá báðum netum og biddu þess að TTL færslunnar sem þú breyttir renni út.

Staðfestu að svarið sé stöðugt frá hverjum heimildaraðila, og skrifaðu ætlaða sjónarhornið í skjöl svæðisins svo auðvelt sé að flokka næsta mun.