Vale VPN-i DNS? Üks autoriteetne server võib olla vananenud

Ühenda VPN ja üks hostinimi lahendatakse eilsele aadressile või üldse mitte millekski. Ühenda lahti ja see töötab jälle. Refleks on süüdistada resolverit, mille tunnel peale surus, kuid sagedasem põhjus on avaldatud nimeserver, mis lõpetas tsooniuuenduste vastuvõtmise. Uus tee jõudis lihtsalt teise autoriteedini kui see, kust sinu vahemällu salvestatud vastus pärines.

Sümptom muutub koos resolveriga

Rekursiivne resolver tagastab selle, mida autoriteet talle ütles, ja hoiab seejärel seda vastust TTL-i jooksul. Kui tunnel surub peale teise resolveri või muudab tee nii, et vana ei ole enam kättesaadav, küsib klient teist autoriteeti ja saab teise vastuse. Domeen ei muutunud sel hetkel; muutus sinu vaade sellele.

Seepärast võib sama nimi ühes kontoris töötada ja hotellist ebaõnnestuda, ning seepärast aitab kohaliku vahemälu tühjendamine ainult mõnikord. Vahemälu tühjendamine saadab küsimuse uuesti samale autoriteedile.

Eristav test on otsene päring igale avaldatud serverile.

Küsi igalt autoriteedilt otse

Alusta delegeerimisest, mitte loendist, mida mäletad. Küsi vanemalt NS-i komplekti ja seejärel küsi selle komplekti igalt nimelt kirjet, mis sind huvitab. Kaks päringut sama nime kohta erinevatel autoriteetidel näitavad kohe, kas tsoon on ühtlane.

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

Tee sama tsooni tipu NS-kirjetega, sest vanema delegeerimine ja tsooni enda NS-komplekt võivad pärast migratsiooni erineda. SOA seerianumbrid on järgmine asi, mida võrrelda, ja kaugele maha jäänud sekundaarne server on ülekandeprobleem, mitte vastuseprobleem.

Käivita need päringud võrgust, mis ebaõnnestub, mitte ainult oma töölaualt.

Eralda kavandatud vaated katkistest

Mõned domeenid vastavad meelega erinevalt piirkonna või resolverirühma järgi ning split-horizon seadistused on ettevõttevõrkudes tavalised.

Küsimus on, kas erinevus on dokumenteeritud ja püsiv. Kavandamata vaade näeb teistsugune välja: ühel autoriteedil on kirje, mida teised kunagi ei saanud, või puudub tal see, mida kõik jagavad. RFC 2182 valiku- ja juurutamisjuhised käsitlevad autoriteetset kättesaadavust jagatud vastutusena ja see on siin õige raamistik. Koondamine on olemas ainult siis, kui iga avaldatud server suudab vastata kavandatud andmetega, mitte lihtsalt vastu võtta ühendust pordil 53.

Serverit, mis vastab SERVFAIL, on lihtsam diagnoosida kui seda, mis vastab enesekindlalt ja valesti.

Migratsioon paljastab, mida vahemälu varjas

Pakkujavahetuse ajal muutuvad kaks autoriteetset kohta: vanema delegeerimine ja tsooni enda NS-kirjed. Mõlemad tuleb uuendada ja mõlemad salvestatakse vahemällu nende TTL-ide ajaks. Kui vana server jääb tööle ja teenindab endiselt eelmist tsooni, saavad kliendid, kelle resolverid seda küsivad, vana vastuse veel kaua pärast seda, kui üleminek näis lõpetatud olevat.

Just seda olekut varjab pikaajaline vahemälu. Tööjaam, mis töötas terve nädala, rääkis resolveriga, kes hoidis värsket vastust uuelt autoriteedilt, samal ajal kui vana jagas kõigile teistele vananenud andmeid.

Resolveri vahetamine sülearvutis parandab selle sülearvuti ja mitte midagi muud.

Paranda tsoon, mitte resolver

Tee kindlaks, millised serverid peaksid tsooni jaoks autoriteetsed olema, paranda hallatav tsoon või delegeerimine nii, et igaüks neist edastaks kavandatud andmed, ja hoia planeeritud koondamine. Nimeserveri kustutamine sellepärast, et üks VPN-i väljund sai veidra vastuse, vähendab kättesaadavust ja jätab vastuolu paigale.

Seejärel käivita otsesed päringud uuesti mõlemast võrgust ja oota, kuni muudetud kirje TTL lõpeb.

Kinnita, et vastus on igalt autoriteedilt püsiv, ja kirjuta kavandatud vaade tsooni dokumentatsiooni, et järgmist erinevust oleks lihtne liigitada.