Fel VPN-DNS? En auktoritativ server kan vara inaktuell

Anslut VPN och ett värdnamn löses upp till gårdagens adress, eller till ingenting. Koppla från och det fungerar igen. Reflexen är att skylla på resolvern som tunneln tvingade fram, men den vanligare orsaken är en publicerad namnserver som slutade ta emot zonuppdateringar. Den nya vägen nådde helt enkelt en annan auktoritet än den som ditt cachade svar kom från.

Symtomen ändras med resolvern

En rekursiv resolver returnerar det en auktoritet sade till den och behåller sedan svaret under TTL:n. Om tunneln tvingar fram en annan resolver, eller ändrar vägen så att den gamla inte längre går att nå, frågar klienten en annan auktoritet och får ett annat svar. Domänen ändrades inte i det ögonblicket; din bild av den gjorde det.

Därför kan samma namn fungera på ett kontor och misslyckas från ett hotell, och därför hjälper det bara ibland att tömma en lokal cache. Tömning av cachen skickar frågan till samma auktoritet igen.

Det avgörande testet är en direkt fråga till varje publicerad server.

Fråga varje auktoritet direkt

Börja med delegeringen och inte med en lista du kommer ihåg. Fråga föräldern om NS-uppsättningen och fråga sedan varje namn i den uppsättningen om posten du behöver. Två frågor om samma namn hos olika auktoriteter berättar omedelbart om zonen är konsekvent.

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

Gör samma sak för NS-posterna vid zonens topp, eftersom förälderns delegering och zonens egen NS-uppsättning kan gå isär efter en migrering. Serienummer på SOA är nästa sak att jämföra, och en sekundär som ligger långt efter är ett överföringsproblem, inte ett svarsproblem.

Kör dessa frågor från nätverket som misslyckas, inte bara från ditt skrivbord.

Skilj avsedda vyer från trasiga

Vissa domäner svarar medvetet olika beroende på region eller resolvrgrupp, och split-horizon-konfigurationer är normala i företagsnätverk.

Frågan är om skillnaden är dokumenterad och stabil. En oavsiktlig vy ser annorlunda ut: en auktoritet har en post som de andra aldrig fick, eller saknar en som alla delar. RFC 2182 vägledning för val och utrullning behandlar auktoritativ tillgänglighet som ett delat ansvar, och det är rätt ram här. Redundans finns bara om varje publicerad server kan svara med de avsedda uppgifterna, inte bara acceptera en anslutning på port 53.

En server som svarar SERVFAIL är lättare att diagnostisera än en som svarar självsäkert och fel.

En migrering avslöjar vad en cache dolde

Vid ett leverantörsbyte ändras två auktoritativa platser: förälderns delegering och zonens egna NS-poster. Båda måste uppdateras, och båda cachas under sina TTL:er. Om en gammal server blir kvar och fortsätter betjäna den föregående zonen, kommer klienter vars resolvrar frågar den att fortsätta få det gamla svaret långt efter att övergången såg ut att vara klar.

Det är precis det tillstånd som en långlivad cache döljer. Arbetsstationen som fungerade hela veckan talade med en resolver som höll ett färskt svar från den nya auktoriteten, medan den gamla fortsatte dela ut inaktuella data till alla andra.

Att byta resolver på en bärbar dator fixar den bärbara och ingenting annat.

Fixa zonen, inte resolvern

Fastställ vilka servrar som ska vara auktoritativa för zonen, rätta den hanterade zonen eller delegeringen så att var och en av dem levererar de avsedda uppgifterna, och behåll den redundans du planerade. Att radera en namnserver för att en VPN-utgång fick ett märkligt svar minskar tillgängligheten och lämnar inkonsekvensen kvar.

Kör sedan de direkta frågorna igen från båda nätverken och vänta ut TTL:en för posten du ändrade.

Bekräfta att svaret är stabilt från varje auktoritet, och skriv den avsedda vyn i zondokumentationen så att nästa skillnad är lätt att klassificera.