Nepareizs VPN DNS? Viens autoritatīvais serveris var būt novecojis

Pieslēdzieties VPN, un viens resursdatora vārds tiek atrisināts uz vakardienas adresi vai pavisam nekur. Atvienojieties, un tas atkal strādā. Reflekss ir vainot atrisinātāju, ko tunelis uzspieda, bet biežākais cēlonis ir publicēts nosaukumu serveris, kas pārstāja saņemt zonas atjauninājumus. Jaunais ceļš vienkārši sasniedza citu autoritatīvo avotu nekā to, no kura nāca jūsu kešatmiņā saglabātā atbilde.

Simptoms mainās līdz ar atrisinātāju

Rekursīvais atrisinātājs atgriež to, ko tam teica autoritatīvais avots, un pēc tam tur šo atbildi TTL laiku. Ja tunelis uzspiež citu atrisinātāju vai maina ceļu tā, ka vecais vairs nav sasniedzams, klients jautā citam autoritatīvajam avotam un saņem citu atbildi. Domēns tajā brīdī nemainījās; mainījās jūsu skatījums uz to.

Tāpēc viens un tas pats vārds var strādāt vienā birojā un neizdoties no viesnīcas, un tāpēc lokālās kešatmiņas notīrīšana palīdz tikai dažreiz. Kešatmiņas notīrīšana nosūta jautājumu atkal tam pašam autoritatīvajam avotam.

Atšķirošais tests ir tiešs vaicājums katram publicētajam serverim.

Jautājiet katram autoritatīvajam avotam tieši

Sāciet ar deleģējumu, nevis ar sarakstu, ko atceraties. Jautājiet vecāk-serverim par NS kopu un pēc tam jautājiet katram šīs kopas vārdam par ierakstu, kas jums svarīgs. Divi vaicājumi par to pašu vārdu dažādos autoritatīvajos avotos uzreiz parāda, vai zona ir konsekventa.

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

Dariet to pašu ar zonas virsotnes NS ierakstiem, jo pēc migrācijas vecāk-servera deleģējums un pašas zonas NS kopa var atšķirties. SOA sērijas numuri ir nākamais, ko salīdzināt, un tālu atpalicis sekundārais serveris ir pārsūtīšanas problēma, nevis atbildes problēma.

Izpildiet šos vaicājumus no tīkla, kas neizdodas, ne tikai no sava galda.

Atdaliet paredzētos skatus no bojātajiem

Daži domēni apzināti atbild citādi atkarībā no reģiona vai atrisinātāju grupas, un sadalītā horizonta konfigurācijas uzņēmumu tīklos ir normālas.

Jautājums ir, vai atšķirība ir dokumentēta un stabila. Neparedzēts skats izskatās citādi: vienam autoritatīvajam avotam ir ieraksts, ko pārējie nekad nav saņēmuši, vai tam trūkst tā, ko visi dala. RFC 2182 atlases un ieviešanas vadlīnijas autoritatīvo pieejamību uzskata par kopīgu atbildību, un šeit tas ir pareizais ietvars. Dublēšana pastāv tikai tad, ja katrs publicētais serveris var atbildēt ar paredzētajiem datiem, nevis tikai pieņemt savienojumu portā 53.

Serveri, kas atbild SERVFAIL, ir vieglāk diagnosticēt nekā to, kas atbild pārliecināti un nepareizi.

Migrācija atklāj to, ko slēpa kešatmiņa

Nomainot pakalpojumu sniedzēju, mainās divas autoritatīvās vietas: vecāk-servera deleģējums un pašas zonas NS ieraksti. Abi ir jāatjaunina, un abi tiek kešoti savu TTL laiku. Ja vecs serveris paliek ieslēgts un turpina apkalpot iepriekšējo zonu, klienti, kuru atrisinātāji to jautā, turpinās saņemt veco atbildi vēl ilgi pēc tam, kad pāreja izskatījās pabeigta.

Tieši šo stāvokli slēpj ilgstoša kešatmiņa. Darbstacija, kas strādāja visu nedēļu, runāja ar atrisinātāju, kuram bija svaiga atbilde no jaunā autoritatīvā avota, kamēr vecais turpināja izplatīt novecojušus datus visiem pārējiem.

Atrisinātāja maiņa klēpjdatorā salabo to klēpjdatoru un neko citu.

Labojiet zonu, nevis atrisinātāju

Nosakiet, kuri serveri ir paredzēti kā autoritatīvie šai zonai, izlabojiet pārvaldīto zonu vai deleģējumu tā, lai katrs no tiem sniegtu paredzētos datus, un saglabājiet plānoto dublēšanu. Nosaukumu servera dzēšana tāpēc, ka viena VPN izeja saņēma dīvainu atbildi, samazina pieejamību un atstāj nekonsekvenci vietā.

Pēc tam atkal izpildiet tiešos vaicājumus no abiem tīkliem un nogaidiet, līdz beidzas mainītā ieraksta TTL.

Pārliecinieties, ka atbilde ir stabila no katra autoritatīvā avota, un ierakstiet paredzēto skatu zonas dokumentācijā, lai nākamo atšķirību būtu viegli klasificēt.