InfraNestInfraNest
Domeinen & DNS

Cloudflare DNS wordt niet bijgewerkt: oorzaken en oplossingen

Heb je een DNS-record in Cloudflare aangepast en lijkt er niets veranderd? Zo zie je het verschil tussen een vertraging door caching en een echt configuratieprobleem, en zo los je beide op.

IInfraNest· 29 juli 2026· 5 min read· Updated 30 september 2026
Cloudflare DNS wordt niet bijgewerkt: oorzaken en oplossingen

Als Cloudflare DNS niet wordt bijgewerkt, is het record aan de kant van Cloudflare vrijwel altijd al correct gewijzigd. De vertraging die je ziet, komt doordat een downstream resolver nog een gecachet antwoord geeft, of je kijkt naar een geproxied record en ziet het gedrag van Cloudflares edge aan voor een verouderde DNS-vermelding. Het autoritatieve netwerk van Cloudflare voert wijzigingen binnen enkele seconden wereldwijd door. Wat achterloopt, is alles tussen Cloudflare en je scherm: de cache van je besturingssysteem, je browser, de resolver van je provider en elke publieke resolver zoals 8.8.8.8 die de oude TTL (time to live) heeft gecachet.

In dit artikel bespreken we de echte oorzaken, gerangschikt van meest naar minst waarschijnlijk, en laten we je snel vaststellen met welke je te maken hebt.

Waarom DNS-wijzigingen vertraagd lijken, ook als ze dat niet zijn

Elk DNS-record heeft een TTL: het aantal seconden dat een resolver het antwoord mag cachen voordat hij opnieuw navraag doet bij de autoritatieve server (RFC 1035). Had een record vóór je wijziging een TTL van 3600 seconden, dan mag elke resolver die de oude waarde al in de cache had, die tot een uur lang blijven teruggeven, ook al heeft de edge van Cloudflare het nieuwe antwoord al.

Dit is standaard DNS-gedrag en geen bug in Cloudflare. Het geldt voor elke DNS-provider; bij Cloudflare valt het de meeste mensen alleen op omdat wijzigingen via het dashboard direct lijken door te komen.

NoteNegatieve antwoorden (zoals NXDOMAIN, wanneer een record nog niet bestaat) worden gecachet op basis van de SOA MINIMUM-waarde van de zone, niet op basis van de TTL van het record zelf. Een nieuw aangemaakt record kan daardoor soms langer nodig hebben om zichtbaar te worden dan een bewerkt record.

Cloudflare TTL: wat "Auto" eigenlijk betekent

De DNS-recordeditor van Cloudflare biedt een TTL-keuzemenu met de optie Auto plus vaste waarden van 1 minuut tot een week. Met Auto laat je de keuze van de TTL aan Cloudflare over, dat doorgaans een korte TTL toepast die geschikt is voor snelle failover. Vanuit het oogpunt van de resolver blijft het echter een gecachete waarde.

Ga je een wijziging doorvoeren waarvan je weet dat die snel moet doorkomen (bijvoorbeeld het migreren van een A-record vlak voor een serveroverstap), verlaag de TTL dan een of twee dagen vooraf naar een korte waarde, zoals 300 seconden. Op het moment dat je het record daadwerkelijk omzet, hebben resolvers dan maar een cache van 5 minuten oud in plaats van een uur.

De proxyvalkuil: oranje wolk vs grijze wolk

Dit is veruit de meest voorkomende bron van verwarring rond "Cloudflare DNS wordt niet bijgewerkt". Wanneer een record geproxied is (oranje wolk), geeft Cloudflare je origin-IP helemaal niet terug in DNS-antwoorden, maar zijn eigen Anycast-IP's. Wijzig je dus het IP-adres van je origin op een geproxied record en controleer je daarna de DNS, dan zie je het nieuwe IP nooit, omdat Cloudflare het ook eerder al niet liet zien.

Wat je in dat geval eigenlijk aan het troubleshooten bent, is vaak geen DNS, maar:

  • Cloudflare dat nog niet naar de nieuwe origin routeert (controleer het origin-IP van het record in het dashboard, niet via een DNS-lookup)
  • De CDN-/cachelaag van Cloudflare die een oude gecachete pagina serveert (vereist een cache purge, geen wachten op DNS)
  • Een firewall- of beveiligingsregel die de nieuwe origin blokkeert

Omschakelen tussen Proxied en DNS-only (grijze wolk) verandert ook wat een DNS-query daadwerkelijk teruggeeft, en die omschakeling is downstream net zo onderhevig aan normale TTL-caching als elke andere recordwijziging.

Vergelijking die laat zien dat een geproxied record een Cloudflare Anycast-IP (104.21.24.19) teruggeeft, terwijl DNS-only het origin-IP teruggeeft (203.

DNS controleren: zo zie je wat er echt gebeurt

Ga er niet meteen van uit dat er iets kapot is. Controleer het record rechtstreeks bij een autoritatieve of bekende publieke resolver in plaats van te vertrouwen op je eigen computer, die mogelijk een verouderde lokale cache heeft.

Gebruik onze gratis DNS lookup-tool voor het betreffende domein en recordtype. De tool voert een live query uit en laat precies zien wat er op dit moment wordt teruggegeven, zonder de cache van je eigen apparaat. Vergelijk dat met wat het Cloudflare-dashboard voor het record toont.

Wat je ziet Wat het betekent
Lookup-tool toont nieuwe waarde Cloudflare klopt; de cache van je lokale apparaat/browser is verouderd
Lookup-tool toont oude waarde, dashboard toont nieuwe waarde Een downstream resolver houdt zich nog aan de oude TTL
Lookup-tool toont geen van beide waarden De nameservers zijn niet echt gedelegeerd naar Cloudflare, of je bewerkt de verkeerde zone
Record is geproxied en toont een Cloudflare-IP Verwacht gedrag: controleer de origin-configuratie, niet de DNS

Komt de lookup-tool overeen met het dashboard, dan ligt de oplossing volledig lokaal: flush de DNS-cache van je besturingssysteem, wis de browsercache of wacht gewoon tot de TTL is verlopen. Het is geen Cloudflare-probleem.

Tabel die DNS-lookupresultaten vergelijkt met waarden in het Cloudflare-dashboard om verouderde cache, TTL-, delegatie- of proxyproble

Als het een delegatieprobleem is en geen cacheprobleem

Verschijnt een wijziging echt nergens, hoe lang je ook wacht, controleer dan of de nameservers van het domein bij de registrar daadwerkelijk naar Cloudflare verwijzen. Het komt vaak voor dat records worden bewerkt in een Cloudflare-zone die correct is ingesteld maar nooit volledig is geactiveerd: de NS-records op registrarniveau verwijzen nog naar een andere partij, waardoor de edge van Cloudflare helemaal nooit wordt geraadpleegd.

Controleer ook of je echt de zone bewerkt die je denkt te bewerken. Beheer je meerdere Cloudflare-accounts, of is het domein twee keer toegevoegd, dan werk je gemakkelijk per ongeluk een gepauzeerde of inactieve zone bij.

TipBeheer je DNS voor verschillende domeinen bij Cloudflare en andere providers, dan maak je veel minder snel fouten met verkeerde zones als je alles in één dashboard overziet. Met onze DNS-beheerfunctie en Cloudflare-integratie bekijk en bewerk je records bij meerdere providers zonder te zoeken tussen aparte logins.

Snelle checklist voordat je aanneemt dat Cloudflare kapot is

  • Controleer of het record correct is opgeslagen in het Cloudflare-dashboard
  • Controleer of de nameservers van het domein bij de registrar naar Cloudflare zijn gedelegeerd
  • Vraag een publieke resolver rechtstreeks op met een DNS lookup-tool, niet alleen via je browser
  • Onthoud dat geproxiede records je origin-IP nooit via DNS tonen
  • Gaat het om een CDN-/paginacacheprobleem, purge dan de cache van Cloudflare in plaats van op DNS te wachten
  • Verlaag de TTL ruim voor geplande overstappen, zodat toekomstige wijzigingen sneller doorkomen

Meer achtergrond over hoe records en resolvers in het algemeen samenwerken, vind je in onze gids over hoe DNS-resolutie werkt en het volledige overzicht van DNS-recordtypes.

Voer je DNS-wijzigingen door bij Cloudflare en diverse andere providers, dan biedt ons DNS-beheer-dashboard één plek om records te controleren, te bewerken en te verifiëren zonder van tool te wisselen.

Veelgestelde vragen

#Hoe lang duurt het voordat DNS-wijzigingen in Cloudflare doorkomen?

De autoritatieve servers van Cloudflare worden vrijwel direct bijgewerkt, meestal binnen enkele seconden. Wat langer duurt, is het verversen van de cache bij downstream resolvers. Dat kan zo lang duren als de vorige TTL van het record, doorgaans enkele minuten tot een uur.

#Waarom toont mijn DNS lookup-tool een ander resultaat dan het Cloudflare-dashboard?

Dit betekent vrijwel altijd dat een resolver ergens tussen jou en Cloudflare nog een gecachet antwoord van vóór je wijziging teruggeeft, op basis van de TTL die het record had op het moment dat het werd gecachet.

#Lost het purgen van de Cloudflare-cache een DNS-record op dat niet wordt bijgewerkt?

Nee. Een cache purge wist de CDN-/contentcache van Cloudflare, en die staat los van DNS. Als een DNS-record zelf een wijziging niet weergeeft, ligt de oplossing bij de TTL of bij een delegatieprobleem, niet bij een cache purge.

#Kan een geproxied record ooit het echte IP-adres van mijn server tonen?

Nee. Geproxiede records (oranje wolk) geven in DNS-antwoorden altijd de Anycast-IP's van Cloudflare terug, ongeacht de TTL. Wil je je origin-IP bekijken of wijzigen, controleer dan de configuratie van het record rechtstreeks in het Cloudflare-dashboard.

Probeer het met een gratis tool

Nieuwe artikelen, rechtstreeks in je inbox

Ik ontvang graag productupdates en nieuwe artikelen van InfraNest per e-mail. Ik kan me op elk moment afmelden.

Privacyverklaring

Gerelateerde artikelen

Begin in seconden

Breng je hele infrastructuur samen in één modern dashboard.

Gratis plan · Geen creditcard nodig · In enkele minuten ingesteld