Je wijziging staat binnen seconden live op je nameserver. Wat tijd kost, zijn alle partijen die het oude antwoord al hebben, en die houden het zo lang vast als de oude TTL zegt. De gebruikelijke wachttijd is dus minuten tot een uur, tot een dag als het record een lange TTL had, en tot twee dagen als je van nameservers wisselt.
"Propagatie" is daar het verkeerde woord voor. Er reist niets over het internet. Kopieën van een antwoord staan in caches en elke kopie verloopt op zijn eigen klok.
De korte versie
Het recordtype maakt niet uit. Een MX-record wacht op zijn eigen TTL, net als een A-record. Het verhaal dat MX 48 uur duurt bestaat omdat MX-records vaak met een lange TTL worden geleverd.
Wat er gebeurt als je een record opslaat
- Je provider werkt zijn nameservers bij. Meestal binnen seconden. Route 53 meldt een wijziging bijvoorbeeld als in sync, normaal binnen een minuut. Wordt de zone ook door secundaire nameservers bediend, dan halen die het in via een zone-overdracht. Dat gaat direct als de primaire een NOTIFY stuurt en anders pas na het SOA-refreshinterval.
- Elke resolver die vanaf nu vraagt krijgt het nieuwe antwoord. Hij bewaart het voor de nieuwe TTL.
- Elke resolver die eerder vroeg houdt het oude antwoord tot zijn kopie verloopt. De kopie is bewaard met de TTL van dat moment en telt vanaf dan af.
Er zit meer dan een cache in de keten en elke cache kan zijn eigen kopie hebben.
Je browser heeft een korte cache van zichzelf. Het besturingssysteem cachet op TTL. Routers thuis en ISP-resolvers cachen op TTL en sommige begrenzen erg lange TTL's. Publieke resolvers zoals 8.8.8.8 en 1.1.1.1 doen hetzelfde. Alleen het laatste blok, je nameserver, kent de waarheid.
De regel: de oude TTL beslist
Een TTL geldt voor antwoorden die na het instellen worden opgehaald. De TTL verlagen op het moment dat je het record wijzigt helpt niemand die het oude antwoord al in de cache heeft.
Neem een record met een TTL van een uur dat je om 12:00 wijzigt. Een resolver die het om 11:10 cachete, verloopt om 12:10. Eentje die het om 11:40 cachete, om 12:40. Eentje die het om 11:59 cachete, houdt het oude antwoord tot 12:59.
Het slechtste geval is dus altijd de volledige oude TTL en het gemiddelde de helft daarvan. Plan met het slechtste geval.
Plan een wijziging
- Zoek de huidige TTL op.
dig +noall +answer www.example.com toont hem in de tweede kolom. - Verlaag de TTL minstens een volledige oude TTL voor de wijziging. Is het een dag, doe het dan een dag eerder. Is het een uur, dan is een uur genoeg. Reken een marge. Zet hem op 300 seconden.
- Wacht tot de oude TTL voorbij is. Vanaf dan heeft elke cache ter wereld een kopie die binnen 5 minuten verloopt.
- Voer de wijziging door. Laat de oude server draaien.
- Controleer het bij je nameserver en twee publieke resolvers (hieronder).
- Houd de oude server nog een paar minuten en zet hem daarna uit. Verhoog de TTL weer naar een uur of meer.
In DNSense stel je de TTL inline in: open de opties van een record, klik op het potlood, kies een waarde van 1 minuut tot 1 dag en bevestig.
Providers verschillen in wat ze accepteren. Porkbun en GoDaddy gaan niet onder 600 seconden, Namecheap gaat tot 60 en Openprovider bewaart alleen een vaste lijst waarden en slaat al het andere op als 86400. Cloudflare-records die via de proxy lopen gebruiken een automatische TTL, dus er valt niets te verlagen.
De overstap zelf kan wachten op een rustig moment. Switcher voert een voorbereide wijziging uit op een tijdstip dat jij kiest, dus "nu de TTL verlagen, zaterdag om 06:00 omzetten" vraagt niet dat jij wakker bent.
Waarom een nieuw record kan ontbreken
Vraagt een resolver naar www.example.com voordat je het aanmaakt, dan krijgt hij "bestaat niet" en cachet ook dat antwoord. Dat heet negatieve caching. Het duurt zo lang als de laagste van de SOA-TTL van de zone en het SOA-minimumveld, vaak tussen 5 minuten en een uur.
Het gaat op de klassieke manier mis: je maakt het record aan, een certificaattool of monitor zoekt het een minuut te vroeg op en de resolver waarmee je test zegt daarna een tijdje NXDOMAIN. Zoek een naam dus niet op voordat hij bestaat.
Nameservers en DNSSEC: de trage
Verhuis je een domein naar andere nameservers, dan wijzig je de delegatie bij de registrar. Het register publiceert die snel. Maar resolvers cachen de oude delegatie en de TTL daarvan is van het register, niet van jou. Voor .com is dat twee dagen en die kun je niet verlagen. Andere extensies verschillen.
Daar volgen twee dingen uit:
- Bedien de zone twee dagen op beide providers. Kopieer de zone eerst naar de nieuwe provider en vergelijk hem record voor record. Wijzig pas daarna de nameservers.
- Haal eerst DNSSEC weg. Laat je het DS-record bij het register staan terwijl de nieuwe provider de zone niet ondertekent, dan behandelen validerende resolvers het domein als kapot. Verwijder het DS-record, wacht de TTL ervan af, wijzig de nameservers en onderteken daarna opnieuw bij de nieuwe provider.
Controleer wat de wereld ziet
Vraag je autoritatieve nameserver en twee publieke resolvers:
dig NS example.com +short
dig +noall +answer www.example.com @ns1.example-dns.net
dig +noall +answer www.example.com @8.8.8.8
dig +noall +answer www.example.com @1.1.1.1
Toont de nameserver nog het oude antwoord, dan is het geen caching. De wijziging bereikte de provider niet, of je bewerkte een andere zone.
De tweede kolom van het antwoord van een resolver is zijn resterende TTL. Voer het commando twee keer uit: hij telt af. Een getal dat terugspringt naar de volledige TTL betekent dat de resolver net een verse kopie haalde, dus hij heeft het nieuwe antwoord. Een getal dat op de oude waarde blijft aftellen vertelt je hoe lang je nog moet wachten.
Een publieke resolver kun je zelf legen. Google en Cloudflare hebben allebei een pagina om een naam uit hun cache te verwijderen (dns.google/cache en one.one.one.one/purge-cache). Ook je eigen machine heeft een cache:
resolvectl flush-caches # Linux met systemd-resolved
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder # macOS
ipconfig /flushdns # Windows
De ISP's van je bezoekers kun je niet legen. Daarom is het TTL-plan belangrijk.
Online "propagatiecheckers" vragen een lijst resolvers wereldwijd. Ze zijn een goede check, maar een groene kaart betekent niet dat elke resolver bij is.
Fouten die een avond kosten
- De TTL en het record in dezelfde stap wijzigen. Niets heeft de korte TTL al.
- Het AAAA-record vergeten. Het A-record wijst naar de nieuwe server, het AAAA-record nog naar de oude en bezoekers met IPv6 komen op de oude host. Zie AAAA-records uitgelegd.
- Testen vanaf een machine met cache. Een VPN, DNS over HTTPS in de browser of een lokale resolver hebben allemaal een eigen cache. Test met
dig tegen een benoemde server. - De oude server te vroeg uitzetten. De langzaamste cache beslist, niet de snelste.
- De TTL op 60 laten staan. Zodra de wijziging klaar is kost het extra opzoekingen zonder reden.
Terugdraaien is weer een wijziging
Een revert werkt bij de provider binnen seconden, zoals elke wijziging. Resolvers die de foute waarde oppakten houden hem tot zijn TTL verloopt. DNSense bewaart elke wijziging in Time machine, dus terugdraaien is een klik.
Maar die klik leegt niemands cache. Dat is het beste argument voor een lage TTL voor elke riskante wijziging: dan zijn de fout en het herstel even kort.
