Neteisingas VPN DNS? Vienas įgaliotasis serveris gali būti pasenęs

Prisijunkite prie VPN ir vienas pagrindinio kompiuterio vardas išsprendžiamas į vakarykštį adresą arba visai į nieką. Atsijunkite ir vėl veikia. Refleksas yra kaltinti rezolverį, kurį įkišo tunelis, tačiau dažnesnė priežastis yra paskelbtas vardų serveris, kuris nustojo gauti zonos atnaujinimus. Naujasis kelias tiesiog pasiekė kitą įgaliotąjį šaltinį nei tas, iš kurio atėjo jūsų podėlyje saugomas atsakymas.

Simptomas keičiasi kartu su rezolveriu

Rekursyvusis rezolveris grąžina tai, ką jam pasakė įgaliotasis šaltinis, o paskui laiko tą atsakymą TTL laiką. Jei tunelis įkiša kitą rezolverį arba pakeičia kelią taip, kad senasis nebepasiekiamas, klientas klausia kito įgaliotojo šaltinio ir gauna kitą atsakymą. Domenas tuo momentu nepasikeitė; pasikeitė jūsų požiūris į jį.

Štai kodėl tas pats vardas gali veikti viename biure ir neveikti iš viešbučio, ir štai kodėl vietinės podėlio išvalymas padeda tik kartais. Podėlio išvalymas vėl nusiunčia klausimą tam pačiam įgaliotajam šaltiniui.

Skiriamasis bandymas yra tiesioginė užklausa kiekvienam paskelbtam serveriui.

Klauskite kiekvieno įgaliotojo šaltinio tiesiogiai

Pradėkite nuo delegavimo, o ne nuo sąrašo, kurį prisimenate. Paklauskite tėvinio serverio apie NS rinkinį, tada paklauskite kiekvieno to rinkinio vardo apie jums reikalingą įrašą. Dvi užklausos dėl to paties vardo skirtinguose įgaliotuosiuose šaltiniuose iš karto pasako, ar zona nuosekli.

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

Tą patį padarykite zonos viršūnės NS įrašams, nes po migracijos tėvinio serverio delegavimas ir pačios zonos NS rinkinys gali nesutapti. SOA eilės numeriai yra kitas dalykas, kurį reikia palyginti, o labai atsilikęs antrinis serveris yra perdavimo problema, o ne atsakymo problema.

Vykdykite šias užklausas iš nepavykstančio tinklo, o ne tik nuo savo stalo.

Atskirkite numatytas peržiūras nuo sugedusių

Kai kurie domenai sąmoningai atsako kitaip pagal regioną ar rezolverių grupę, o padalintos horizonto konfigūracijos įmonių tinkluose yra įprastos.

Klausimas, ar skirtumas dokumentuotas ir stabilus. Nenumatyta peržiūra atrodo kitaip: vienas įgaliotasis šaltinis turi įrašą, kurio kiti niekada negavo, arba jam trūksta to, kurį visi dalijasi. RFC 2182 parinkimo ir diegimo gairės įgaliotąjį prieinamumą laiko bendra atsakomybe, ir tai čia yra tinkama sistema. Dubliavimas egzistuoja tik jei kiekvienas paskelbtas serveris gali atsakyti numatytais duomenimis, o ne tik priimti ryšį 53 prievade.

Serverį, kuris atsako SERVFAIL, lengviau diagnozuoti nei tą, kuris atsako užtikrintai ir neteisingai.

Migracija atskleidžia, ką slėpė podėlis

Keičiant tiekėją pasikeičia dvi įgaliotosios vietos: tėvinio serverio delegavimas ir pačios zonos NS įrašai. Abu reikia atnaujinti, ir abu saugomi podėlyje savo TTL laiką. Jei senas serveris lieka veikti ir toliau aptarnauja ankstesnę zoną, klientai, kurių rezolveriai jo klausia, ir toliau gaus seną atsakymą dar ilgai po to, kai perėjimas atrodė baigtas.

Būtent šią būseną slepia ilgalaikis podėlis. Darbo stotis, kuri veikė visą savaitę, kalbėjosi su rezolveriu, kuris turėjo šviežią naujojo įgaliotojo šaltinio atsakymą, o senasis toliau dalijo pasenusius duomenis visiems kitiems.

Rezolverio pakeitimas nešiojamajame kompiuteryje sutaiso tą nešiojamąjį ir nieko daugiau.

Taisykite zoną, o ne rezolverį

Nustatykite, kurie serveriai turi būti įgaliotieji zonai, pataisykite valdomą zoną arba delegavimą, kad kiekvienas jų teiktų numatytus duomenis, ir išlaikykite suplanuotą dubliavimą. Vardų serverio trynimas dėl to, kad viena VPN išvestis gavo keistą atsakymą, sumažina prieinamumą ir palieka nenuoseklumą vietoje.

Tada vėl vykdykite tiesiogines užklausas iš abiejų tinklų ir palaukite, kol baigsis pakeisto įrašo TTL.

Patvirtinkite, kad atsakymas stabilus iš kiekvieno įgaliotojo šaltinio, ir įrašykite numatytą peržiūrą į zonos dokumentaciją, kad kitą skirtumą būtų lengva klasifikuoti.