# DNS-propagatie: hoe lang duurt het en wat doe je tussentijds?

## Hoe DNS-propagatie werkt

Als je een DNS-record wijzigt, verdwijnt de oude waarde niet meteen overal. Vrijwel elke DNS-resolver op het internet bewaart een kopie van je records in zijn cache, en die cache wordt pas ververst nadat de TTL (Time To Live) is verlopen.

TTL is een waarde in seconden die je instelt bij het DNS-record. Een TTL van 3600 betekent dat DNS-servers het record maximaal een uur mogen bewaren. Daarna vragen ze de authoritative nameserver van jouw domein opnieuw om de actuele waarde.

Dat betekent: wijzig je een record terwijl de TTL nog 3600 is, dan kan het tot een uur duren voordat de meeste servers de nieuwe waarde zien. Sommige servers hebben het record net opgehaald en wachten nog bijna een vol uur. De propagatie verloopt dus niet uniform.

:::tip title="Verlaag de TTL voor een geplande migratie"
Verlaag de TTL van kritieke records (MX, A, CNAME) minstens 24 uur voor een geplande migratie naar 300 seconden (5 minuten). Zo propageert de werkelijke wijziging veel sneller. Zet de TTL daarna weer terug naar 3600 of hoger.
:::

## Wat 'propagatie' eigenlijk betekent

'DNS-propagatie' is een term die veel mensen gebruiken, en het suggereert een actief proces. In werkelijkheid is het passief: DNS-servers halen nieuwe waarden pas op zodra hun cache verloopt. Er is geen centrale server die wijzigingen actief uitduwt.

Dit verklaart waarom twee mensen op hetzelfde moment een ander resultaat zien. Iemand in Amsterdam gebruikt een andere DNS-resolver dan iemand in Londen, en die twee hebben allebei een eigen cachingstatus.

## Propagatie monitoren

Je krijgt geen melding wanneer alles klaar is; je moet zelf controleren.

Via de terminal bevraag je een paar publieke resolvers rechtstreeks:

```bash
dig A jouwdomein.nl @8.8.8.8
dig A jouwdomein.nl @1.1.1.1
dig A jouwdomein.nl @9.9.9.9
```

Door drie verschillende publieke resolvers te bevragen zie je of de propagatie overal gevorderd is. Geven alle drie dezelfde waarde terug, dan is de propagatie grotendeels compleet. Voor MX-records vervang je `A` door `MX`.

Via online tools controleer je in een keer wereldwijd:

- **whatsmydns.net** toont de DNS-status vanuit tientallen locaties tegelijk.
- **dnschecker.org** doet hetzelfde en ondersteunt alle veelgebruikte recordtypes.
- **Google Admin Toolbox** (toolbox.googleapps.com/apps/dig/) geeft de waarde die Google zelf ziet, handig bij Workspace-verificatie.

:::howto title="TTL verlagen voor een geplande DNS-wijziging"
1. Open DNS-beheer bij je registrar minstens 24 uur voor de geplande wijziging.
2. Verlaag de TTL van het te wijzigen record naar `300` seconden.
3. Wacht minimaal zo lang als de huidige TTL. Was de TTL 3600, wacht dan een uur.
4. Voer daarna de eigenlijke DNS-wijziging uit. Die propageert nu binnen ongeveer 5 minuten.
5. Controleer via **whatsmydns.net** of de nieuwe waarde overal zichtbaar is.
6. Zet de TTL na succesvolle propagatie terug naar 3600 of je voorkeurwaarde.
:::

## Wat je tussentijds kunt doen

**Voor e-mailmigraties:** laat de oude mailserver actief totdat je zeker weet dat alle MX-records zijn gepropageerd. Nieuwe berichten gaan al naar Workspace, maar sommige servers blijven nog naar de oude server sturen zolang die in hun cache staat.

**Voor websitemigraties:** test de nieuwe server eerst lokaal via je hosts-bestand. Voeg een regel toe aan `/etc/hosts` (macOS en Linux) of `C:\Windows\System32\drivers\etc\hosts` (Windows) die het domein alvast naar het nieuwe IP wijst, alleen voor jouw machine. Zo test je de nieuwe omgeving zonder op propagatie te wachten. Verwijder die regel weer zodra de echte propagatie klaar is.

**Voor Google Workspace-activering:** de Google Admin-console heeft een eigen verificatiecyclus. Zelfs als DNS al gepropageerd is, kan het 15 tot 60 minuten duren voordat de console de status bijwerkt. Klik op 'Domein opnieuw controleren' om dat te versnellen.

:::warn title="Pas op met te lange TTL's"
Een hoge TTL (bijvoorbeeld 86400) is prima voor stabiele records, maar bij een fout ben je daar lang aan vast. Een verkeerd record met een TTL van een dag kan tot 48 uur blijven hangen in caches. Verlaag de TTL dus altijd ruim voor elke geplande wijziging.
:::

## Realistische tijdlijn

| Situatie | Verwachte wachttijd |
|---|---|
| TTL was 300, je hebt 5 minuten gewacht | 5 tot 15 minuten |
| TTL was 3600, geen voorbereiding | 30 minuten tot 2 uur |
| TTL was 86400 (1 dag) | Tot 48 uur |
| Negatieve caching (NXDOMAIN) | Variabel, soms tot 24 uur |

:::faq
### Waarom ziet mijn collega de nieuwe waarde al en ik niet?
Je collega gebruikt waarschijnlijk een andere DNS-resolver of heeft een lege cache. Leeg je lokale DNS-cache met `sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder` (macOS) of `ipconfig /flushdns` (Windows) en controleer opnieuw.

### Is propagatie hetzelfde als TTL?
Nee, maar ze hangen samen. TTL bepaalt hoe lang een DNS-server een record mag cachen. Propagatie is het moment waarop alle resolvers wereldwijd de nieuwe waarde hebben overgenomen. De TTL bepaalt dus de maximale wachttijd per server.

### Kan ik propagatie versnellen na een fout?
Niet direct. Je kunt de TTL verlagen voor toekomstige wijzigingen, maar bestaande caches lopen gewoon af op hun eigen timer. Het enige dat je kunt doen is wachten of het record opnieuw corrigeren met een lage TTL.

### Wat is negatieve caching?
Als een resolver een domein opvraagt dat (nog) niet bestaat, onthoudt hij die NXDOMAIN-uitkomst ook een tijd. Maak je een nieuw record aan, dan kan het daardoor extra lang duren voordat dat record zichtbaar wordt, soms tot 24 uur.

### Moet ik nameservers wijzigen of records aanpassen?
Voor de meeste Workspace-taken pas je losse records aan (MX, TXT, CNAME) bij je huidige DNS-provider. Verander je de nameservers zelf, dan verhuis je je hele DNS-zone, wat een aparte en tragere propagatie kent. Doe dat alleen als je echt van DNS-provider wisselt.
:::