Hoe u DNS-propagatie controleert

Waar het wachten vandaan komt

Stel u de keten voor die een opzoeking aflegt. Uw apparaat vraagt het aan een recursieve resolver, beheerd door uw provider of een openbare aanbieder. Heeft die resolver een recent antwoord gecachet, dan geeft hij het gecachete antwoord terug zonder iemand anders te vragen. Pas wanneer de cache verlopen is, loopt hij door naar de rootservers, het register voor het topleveldomein, en uiteindelijk uw autoritatieve nameservers, die het record bevatten dat u heeft bewerkt.

Wanneer u dus een A-record wijzigt, bestaat de nieuwe waarde vanaf het moment dat uw DNS-provider hem opslaat. Elke resolver die nog het oude antwoord vasthoudt, blijft dat serveren totdat zijn eigen kopie verloopt. De TTL, time to live, is een getal in seconden dat aan het record hangt en resolvers vertelt hoe lang ze het mogen cachen. Een record met een TTL van 3600 kan een uur lang uit de cache worden geserveerd nadat het is opgehaald, dus een uur is het slechtste geval voor een resolver die het net voor uw wijziging ophaalde.

Dit is waarom twee mensen op hetzelfde kantoor verschillende resultaten kunnen zien, en waarom het wissen van uw eigen cache niemand anders helpt. Er is geen wereldwijde verspreiding om op te wachten, alleen een hoop onafhankelijke timers die op verschillende momenten aflopen.

Hoe u het bij meerdere resolvers controleert

De handmatige manier is om verschillende resolvers dezelfde vraag te stellen en hun antwoorden te vergelijken:

dig +short example.com @8.8.8.8      # Google Public DNS
dig +short example.com @1.1.1.1      # Cloudflare
dig +short example.com @9.9.9.9      # Quad9
dig +short example.com               # your own resolver
dig +short example.com @ns1.yourdns.example  # authoritative: the source of truth

De autoritatieve query is de belangrijke. Geeft die de nieuwe waarde terug, dan is uw wijziging correct en volledig, en is al het andere een kwestie van caching. Geeft hij de oude waarde terug, dan is de wijziging niet opgeslagen, heeft u de verkeerde zone bewerkt, of zijn de nameservers van het domein niet degene die u denkt.

Om de resterende cachetijd te zien in plaats van alleen de waarde, laat u +short weg en leest u de TTL-kolom:

dig example.com @8.8.8.8 | grep -A1 "ANSWER SECTION"

Het getal voor het recordtype telt af naarmate de gecachete kopie ouder wordt, wat u precies vertelt hoe lang die resolver het oude antwoord nog zal serveren. Op Windows doet nslookup example.com 8.8.8.8 de vergelijking zonder extra hulpmiddelen. Een webgebaseerde DNS-opzoeking die vanaf veel locaties tegelijk bevraagt, doet hetzelfde werk sneller, en dekt ook resolvers die u vanaf uw eigen machine niet kunt bereiken.

Waarom het uren kan duren

• De oude TTL is bepalend, niet de nieuwe. Had het record een TTL van 86400 en verlaagt u die tijdens de wijziging, dan hebben resolvers die het oude record cachten nog steeds recht op een volle dag. Het verlagen van de TTL helpt alleen de volgende wijziging.
• Sommige resolvers negeren korte TTL's. Een aantal providers hanteert een eigen minimum, doorgaans een uur of meer, ongeacht wat uw record zegt.
• Nameserverwijzigingen gaan trager. NS-records op registerniveau dragen vaak een TTL van dagen, dus het wisselen van DNS-provider kan werkelijk een dag of twee duren voordat het overal is bezonken.
• Negatieve caching telt ook mee. Bestond een naam niet toen iemand hem opzocht, dan wordt het antwoord "bestaat niet" ook gecachet, voor de periode ingesteld door het SOA-minimumveld van de zone.
• Geketende caches. Een browser cachet DNS, het besturingssysteem cachet DNS, en een bedrijfsresolver kan vóór de openbare resolver staan. Elke laag voegt zijn eigen vertraging toe.
• Langlopende verbindingen. Applicaties die een hostnaam eenmalig bij het opstarten hebben opgelost, blijven dat adres gebruiken tot ze herstarten, ongeacht wat DNS nu zegt.

Hoe u de volgende wijziging snel maakt

1. Verlaag eerst de TTL, en wacht dan. Zet de TTL van het record naar 300 seconden en laat dat staan gedurende ten minste de lengte van de oude TTL voordat u de echte wijziging doorvoert. Tegen die tijd draagt elke gecachete kopie de korte waarde.
2. Voer de wijziging door. Met een TTL van 300 seconden pikken de meeste resolvers dit binnen vijf minuten op.
3. Houd de oude server tijdens de overlap actief. Zet hem niet uit op het moment dat DNS is bijgewerkt. Laat hem doorserveren tot het verkeer ernaartoe stopt, en de migratie verloopt zonder dat iemand het merkt.
4. Verifieer tegen de autoritatieve nameservers en verschillende openbare resolvers voordat u het als voltooid beschouwt.
5. Verhoog de TTL weer zodra de wijziging is bezonken, zodat normaal verkeer opnieuw van caching profiteert.

Voor een nameserverwijziging bestaat geen kortere weg, omdat de TTL van het register niet de uwe is om in te stellen. Reken op een dag of twee, en laat beide DNS-providers de hele tijd identieke records serveren, zodat het niet uitmaakt welke een resolver bevraagt.

Nadat de wijziging is bezonken

Een paar resolvers handmatig controleren vertelt u hoe ver een wijziging zich op dat moment heeft verspreid, wat nuttig is tijdens een migratie en verder nutteloos. De fouten die het waard zijn om te betrappen, zijn de latere: een record dat verandert zonder dat iemand het merkt, een nameserver die stopt met antwoorden, een zone die verloopt. Continue DNS-monitoring bevraagt vanaf veel locaties volgens een schema en waarschuwt wanneer het antwoord niet meer klopt met wat het zou moeten zijn, wat ook het geval "werkt hiervandaan, kapot vandaar" betrapt dat één opzoeking niet kan zien. Voer nu een opzoeking uit met de DNS-querytool. Is de site voor u onbereikbaar maar elders in orde, dan neemt is de site voor iedereen down of alleen voor mij het vanaf daar over.