Feil VPN-DNS? Ein autoritativ server kan vere utdatert

Kopla til VPN og eitt vertsnamn blir slått opp til gårsdagens adresse, eller til ingenting. Kopla frå og det verkar igjen. Refleksen er å skylde på resolvaren tunnelen dytta inn, men den vanlegare årsaka er ein publisert namneserver som slutta å ta imot soneoppdateringar. Den nye vegen nådde rett og slett ein annan autoritet enn den svaret i hurtigbufferen kom frå.

Symptomet endrar seg med resolvaren

Ein rekursiv resolver returnerer det ein autoritet fortalde han, og held deretter svaret i TTL-en. Viss tunnelen dyttar inn ein annan resolver, eller endrar vegen slik at den gamle ikkje lenger er tilgjengeleg, spør klienten ein annan autoritet og får eit anna svar. Domenet endra seg ikkje i det augneblinken; synet ditt på det gjorde det.

Derfor kan same namn verke på eitt kontor og feile frå eit hotell, og derfor hjelper det berre stundom å tømme ein lokal hurtigbuffer. Tømming av bufferen sender spørsmålet til den same autoriteten igjen.

Den avgjerande testen er eit direkte spørsmål til kvar publisert server.

Spør kvar autoritet direkte

Byrja med delegasjonen, ikkje med ei liste du hugsar. Spør forelderen om NS-settet, og spør deretter kvart namn i settet om posten du treng. To spørjingar mot same namn hos ulike autoritetar fortel deg med ein gong om sona er konsistent.

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

Gjer det same for NS-postane ved toppen av sona, fordi foreldredelegasjonen og sona sitt eige NS-sett kan vere usamde etter ein migrasjon. Serienummer på SOA er det neste som skal samanliknast, og ein sekundær som ligg langt bak er eit overføringsproblem, ikkje eit svarproblem.

Køyr desse spørjingane frå nettverket som feilar, ikkje berre frå skrivebordet ditt.

Skil tiltenkte visingar frå øydelagde

Nokre domene svarar med vilje ulikt etter region eller resolvargruppe, og split-horizon-oppsett er normale i bedriftsnettverk.

Spørsmålet er om skilnaden er dokumentert og stabil. Ei utilsikta vising ser annleis ut: éin autoritet har ein post som dei andre aldri fekk, eller manglar ein som alle deler. RFC 2182 rettleiing for val og utrulling handsamar autoritativ tilgjenge som eit felles ansvar, og det er den rette ramma her. Redundans finst berre viss kvar publisert server kan svare med dei tiltenkte dataa, ikkje berre godta ei tilkopling på port 53.

Ein server som svarar SERVFAIL, er lettare å diagnostisere enn ein som svarar sjølvsikkert og feil.

Ein migrasjon avdekkjer kva ein hurtigbuffer skjulte

Under eit leverandørbyte endrar to autoritative stader seg: foreldredelegasjonen og sona sine eigne NS-postar. Begge må oppdaterast, og begge blir hurtigbufra for sine TTL-ar. Viss ein gammal server blir ståande og held fram med å tene den førre sona, vil klientar med resolvarar som spør han, framleis få det gamle svaret lenge etter at overgangen såg ut til å vere ferdig.

Det er nettopp tilstanden ein langvarig hurtigbuffer skjuler. Arbeidsstasjonen som verka heile veka, snakka med ein resolver som heldt eit ferskt svar frå den nye autoriteten, medan den gamle heldt fram med å dele ut utdaterte data til alle andre.

Å byte resolver på ein berbar PC fiksar den berbare og ingenting anna.

Fiks sona, ikkje resolvaren

Finn ut kva serverar som skal vere autoritative for sona, rett opp den administrerte sona eller delegasjonen slik at kvar av dei leverer dei tiltenkte dataa, og hald på redundansen du planla. Å slette ein namneserver fordi éin VPN-utgang fekk eit merkeleg svar, reduserer tilgjenge og lèt inkonsistensen bli ståande.

Køyr deretter dei direkte spørjingane på nytt frå begge nettverk og vent til TTL-en for posten du endra, renn ut.

Stadfest at svaret er stabilt frå kvar autoritet, og skriv den tiltenkte visinga i sonedokumentasjonen slik at den neste skilnaden er lett å klassifisere.