Pogrešan VPN DNS? Jedan autoritativni poslužitelj može biti zastario

Povežite VPN i jedno ime hosta razriješi se na jučerašnju adresu ili na ništa. Isključite ga i ponovno radi. Refleks je kriviti razrješivač koji je tunel nametnuo, ali češći je uzrok objavljeni poslužitelj imena koji je prestao primati ažuriranja zone. Novi put jednostavno je stigao do drugog autoritativnog poslužitelja od onoga iz kojeg je došao vaš predmemorirani odgovor.

Simptom se mijenja s razrješivačem

Rekurzivni razrješivač vraća ono što mu je autoritativni poslužitelj rekao, a zatim taj odgovor drži do isteka TTL-a. Ako tunel nametne drugi razrješivač ili promijeni put tako da stari više nije dostupan, klijent pita drugi autoritativni poslužitelj i dobije drugi odgovor. Domena se u tom trenutku nije promijenila; promijenio se vaš pogled na nju.

Zato isto ime može raditi u jednom uredu, a zakazati iz hotela, i zato brisanje lokalne predmemorije samo ponekad pomaže. Brisanje predmemorije šalje pitanje ponovno istom autoritativnom poslužitelju.

Razlikovni test je izravan upit svakom objavljenom poslužitelju.

Pitajte svaki autoritativni poslužitelj izravno

Pođite od delegacije, a ne od popisa kojeg se sjećate. Pitajte roditelja za NS skup, zatim upitajte svako ime iz tog skupa za zapis koji vas zanima. Dva upita za isto ime na različitim autoritativnim poslužiteljima odmah pokazuju je li zona dosljedna.

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

Učinite isto za NS zapise vrha zone, jer se roditeljska delegacija i vlastiti NS skup zone mogu razlikovati nakon migracije. Serijski brojevi na SOA-i sljedeće je što treba usporediti, a sekundarni poslužitelj koji jako zaostaje je problem prijenosa, a ne problem odgovora.

Izvršite te upite iz mreže koja zakaže, ne samo sa svog stola.

Odvojite namjeravane poglede od pokvarenih

Neke domene namjerno odgovaraju različito prema regiji ili skupini razrješivača, a split-horizon postavke normalne su u poslovnim mrežama.

Pitanje je je li razlika dokumentirana i stabilna. Nenamjeravani pogled izgleda drukčije: jedan autoritativni poslužitelj ima zapis koji ostali nikad nisu primili ili mu nedostaje onaj koji svi dijele. Smjernice RFC 2182 za odabir i primjenu tretiraju autoritativnu dostupnost kao zajedničku odgovornost i to je pravi okvir ovdje. Redundancija postoji samo ako svaki objavljeni poslužitelj može odgovoriti namjeravanim podacima, a ne tek prihvatiti vezu na portu 53.

Poslužitelj koji odgovori SERVFAIL lakše je dijagnosticirati od onoga koji odgovori samouvjereno i pogrešno.

Migracija otkriva što je predmemorija skrivala

Tijekom premještanja davatelja usluga mijenjaju se dvije autoritativne lokacije: roditeljska delegacija i vlastiti NS zapisi zone. Oba se moraju ažurirati i oba se predmemoriraju do svojih TTL-ova. Ako stari poslužitelj ostane uključen i nastavi posluživati prethodnu zonu, klijenti čiji ga razrješivači pitaju nastavit će dobivati stari odgovor dugo nakon što je prijelaz izgledao dovršen.

To je upravo stanje koje dugotrajna predmemorija prikriva. Radna stanica koja je radila cijeli tjedan razgovarala je s razrješivačem koji je držao svjež odgovor novog autoritativnog poslužitelja, dok je stari nastavio dijeliti zastarjele podatke svima ostalima.

Promjena razrješivača na prijenosniku popravlja taj prijenosnik i ništa drugo.

Popravite zonu, ne razrješivač

Utvrdite koji poslužitelji trebaju biti autoritativni za zonu, ispravite upravljanu zonu ili delegaciju tako da svaki od njih poslužuje namjeravane podatke i zadržite redundanciju koju ste planirali. Brisanje poslužitelja imena zato što je jedan VPN izlaz dobio čudan odgovor smanjuje dostupnost i ostavlja nedosljednost na mjestu.

Zatim ponovno izvršite izravne upite s obje mreže i pričekajte istek TTL-a zapisa koji ste promijenili.

Potvrdite da je odgovor stabilan sa svakog autoritativnog poslužitelja i upišite namjeravani pogled u dokumentaciju zone kako bi sljedeću razliku bilo lako klasificirati.