VPN-DNS verkeerd? Eén gezaghebbende server kan verouderd zijn

Verbind de VPN en één hostnaam lost op naar het adres van gisteren, of naar niets. Verbreek de verbinding en het werkt weer. De reflex is de resolver de schuld geven die de tunnel heeft doorgeduwd, maar de vaker voorkomende oorzaak is een gepubliceerde naamserver die stopte met het ontvangen van zone-updates. Het nieuwe pad bereikte simpelweg een andere autoriteit dan die waar je gecachte antwoord vandaan kwam.

Het symptoom verandert met de resolver

Een recursieve resolver geeft terug wat een autoriteit hem vertelde, en bewaart dat antwoord vervolgens voor de TTL. Als de tunnel een andere resolver doordrukt, of het pad verandert zodat de oude niet meer bereikbaar is, vraagt de client een andere autoriteit en krijgt een ander antwoord. Het domein veranderde op dat moment niet; jouw beeld ervan wel.

Daarom kan dezelfde naam op het ene kantoor werken en vanaf een hotel falen, en daarom helpt het leegmaken van een lokale cache maar soms. Het leegmaken van de cache stuurt de vraag weer naar dezelfde autoriteit.

De onderscheidende test is een rechtstreekse query naar elke gepubliceerde server.

Vraag elke autoriteit rechtstreeks

Begin bij de delegatie en niet bij een lijst die je onthoudt. Vraag de ouder om de NS-set en vraag vervolgens elke naam in die set om het record dat je nodig hebt. Twee queries naar dezelfde naam bij verschillende autoriteiten vertellen je meteen of de zone consistent is.

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

Doe hetzelfde voor de NS-records aan de top van de zone, want de delegatie van de ouder en de eigen NS-set van de zone kunnen na een migratie van elkaar afwijken. Serienummers op de SOA zijn het volgende dat je moet vergelijken, en een secundaire die ver achterloopt is een overdrachtsprobleem, geen antwoordprobleem.

Voer die queries uit vanaf het netwerk dat faalt, niet alleen vanaf je bureau.

Scheid bedoelde weergaven van kapotte

Sommige domeinen antwoorden bewust anders per regio of resolvern-groep, en split-horizon-configuraties zijn normaal in bedrijfsnetwerken.

De vraag is of het verschil gedocumenteerd en stabiel is. Een onbedoelde weergave ziet er anders uit: één autoriteit heeft een record dat de andere nooit hebben ontvangen, of mist er een die ze allemaal delen. De RFC 2182-richtlijn voor selectie en uitrol behandelt gezaghebbende beschikbaarheid als een gedeelde verantwoordelijkheid, en dat is hier het juiste kader. Redundantie bestaat alleen als elke gepubliceerde server de bedoelde gegevens kan beantwoorden, niet slechts een verbinding op poort 53 kan aannemen.

Een server die SERVFAIL antwoordt, is gemakkelijker te diagnosticeren dan een die zelfverzekerd en fout antwoordt.

Een migratie onthult wat een cache verborg

Bij een providerwissel veranderen twee gezaghebbende locaties: de delegatie van de ouder en de eigen NS-records van de zone. Beide moeten worden bijgewerkt, en beide worden voor hun TTL's gecachet. Als een oude server blijft draaien en de vorige zone blijft bedienen, krijgen clients wier resolvers hem vragen nog lang het oude antwoord nadat de overstap voltooid leek.

Dat is precies de toestand die een langlevende cache verbergt. De werkstation dat de hele week werkte, sprak met een resolver die een vers antwoord van de nieuwe autoriteit had, terwijl de oude verouderde gegevens aan alle anderen bleef uitdelen.

De resolver op een laptop veranderen repareert die laptop en niets anders.

Repareer de zone, niet de resolver

Stel vast welke servers gezaghebbend voor de zone moeten zijn, corrigeer de beheerde zone of de delegatie zodat elk ervan de bedoelde gegevens levert, en behoud de redundantie die je had gepland. Een naamserver verwijderen omdat één VPN-uitgang een vreemd antwoord kreeg, vermindert de beschikbaarheid en laat de inconsistentie staan.

Voer daarna de rechtstreekse queries opnieuw uit vanaf beide netwerken en wacht tot de TTL van het record dat je hebt gewijzigd, verloopt.

Bevestig dat het antwoord vanaf elke autoriteit stabiel is, en schrijf de bedoelde weergave in de zonedocumentatie zodat het volgende verschil gemakkelijk te classificeren is.