Werkt een nieuw dns record direct overal?

[pim]

Als ik een dns record aanmaak.
Bijvoorbeeld een A record voor een subdomein dat naar een ipadres verwijst.
Werkt dat domain dan direct(binnen enkele seconden) overal ter wereld?

Ik dacht altijd dat er last kon zijn van caching.. Maar dat is wellicht niet het geval bij nieuwe records.. Alleen bij bestaande records.. En dan wordt het TTL(time to live) gebruikt voor hoelang het record geached moet worden.

Ik ben het nu aan het testen, en het lijkt direct te werken.
Maar tegelijkertijd wil ik het live testen op veel gebruikers. En dan niet voor verrassingen komen te staan dat het wellicht bij iemand niet werkt.

Ben benieuwd of iemand het met zekerheid weet.

[Croga]

Als er voor een domein nog geen wildcard record bestaat dan zou een nieuw A-record meteen moeten kunnen werken. Ik weet niet of er wel eens queueing optreedt bij DNS servers of performance issues; de DNS server van de gebruiker moet tenslotte wel de gegevens op gaan halen bij jouw DNS server. Maar in principe zou het gewoon nagenoeg immediate moeten zijn

[pim]

Hmm..
Ik heb wel een wildcardrecord(*.domain.com) voor mijn hoofddomein..
Vervolgens wordt er een subdomein(aaaaa.domain.com) aangemaakt, wat die wildcard als het ware moet overrulen.
Ben benieuwd of bij sommige gebruikers het wildcarddomein gecached kan worden, waardoor het nieuwe subdomein niet direct werkt.

[ Voor 3% gewijzigd door pim op 27-10-2026 10:46 ]

[Croga]

pim schreef op dinsdag 27 oktober 2026 @ 10:45:
Hmm..
Ik heb wel een wildcardrecord(*.domain.com) voor mijn hoofddomein..
Vervolgens wordt er een subdomein(aaaaa.domain.com) aangemaakt, wat die wildcard als het ware moet overrulen.
Ben benieuwd of bij sommige gebruikers het wildcarddomein gecached kan worden, waardoor het nieuwe subdomein niet direct werkt.

Als iemand al ooit op je website geweest is met een trigger op de wildcard dan zal die wildcard gecached zijn en de DNS server dus niet op zoek gaan naar een specifiek record totdat die cache invalidated is. Dan kan het dus zijn dat er vertraging in zit.

[FredvZ]

pim schreef op dinsdag 27 oktober 2026 @ 10:32:
Ben benieuwd of iemand het met zekerheid weet.

Dat weet niemand.

Simpelweg omdat iedereen zijn eigen DNS-server kan opzetten en beheren en dus ook de caching in kan stellen.

[Loolladin]

Volgens mij gaat er sowieso vertraging opzitten.

[dehardstyler]

pim schreef op dinsdag 27 oktober 2026 @ 10:32:
Als ik een dns record aanmaak.
Bijvoorbeeld een A record voor een subdomein dat naar een ipadres verwijst.
Werkt dat domain dan direct(binnen enkele seconden) overal ter wereld?

Ik dacht altijd dat er last kon zijn van caching.. Maar dat is wellicht niet het geval bij nieuwe records.. Alleen bij bestaande records.. En dan wordt het TTL(time to live) gebruikt voor hoelang het record geached moet worden.

Ik ben het nu aan het testen, en het lijkt direct te werken.
Maar tegelijkertijd wil ik het live testen op veel gebruikers. En dan niet voor verrassingen komen te staan dat het wellicht bij iemand niet werkt.

Ben benieuwd of iemand het met zekerheid weet.

Uit eigen ervaring weet ik dat het ook echt aan de DNS provider / server kan liggen. Cloudflare is mega snel met het propageren van global changes, kan echt met een minuut geregeld zijn. Maar op GoDaddy heb ik al eens 12 uur kunnen wachten. Het blijft heel lastig te zeggen. Als je het echt heel zeker wil weten, zou ik nu je DNS changes uitsturen en 24 uur later tegen iedereen zeggen dat het nu allemaal zou moeten werken.

[pim]

Croga schreef op dinsdag 27 oktober 2026 @ 10:48:
[...]

Als iemand al ooit op je website geweest is met een trigger op de wildcard dan zal die wildcard gecached zijn en de DNS server dus niet op zoek gaan naar een specifiek record totdat die cache invalidated is. Dan kan het dus zijn dat er vertraging in zit.

Toch werkt het nieuwe A record bij mij direct.
Ik maak een droplet aan bij digital ocean. Vervolgens voeg ik een A record toe via een API call.
En het werkt direct. Terwijl de wildcard(*.domain.com) gecached zou moeten zijn.

Maar als ik een bestaand subdomein wijzig, bijvoorbeeld:
- cccc.domain.com (verander het ip in een A record)
dan heb ik wél "last" van caching.. Ik krijg zelfs mijn cache niet geflushed en moet soms een uur wachten.

[pim]

dehardstyler schreef op dinsdag 27 oktober 2026 @ 11:00:
[...]
Als je het echt heel zeker wil weten, zou ik nu je DNS changes uitsturen en 24 uur later tegen iedereen zeggen dat het nu allemaal zou moeten werken.

Mijn systeem werkt automatisch.. Ik heb een multiplayer game gemaakt, waarbij automatisch droplets worden aangemaakt, als er meer gebruikers bij komen.

Ik heb reverse proxy servers opgezet om die gebruikers die achterlopen met de dns automatisch door te sturen.
En vraag me nu dus af of die reverse proxy servers overbodig zijn.

Ik ga het testen!

[pim]

Weet niet hoe anti-ai jullie zijn, maar vind het antwoord van claude wel interessant:

Resolvers cachen per exacte naam, niet per wildcard, dus een nieuw subdomein dat nog niemand heeft opgevraagd werkt direct. Alleen als iemand die exacte naam opvroeg voordat jouw A-record bestond, of als je een bestaand record wijzigt, krijg je vertraging. Je reverse proxies zijn dus waarschijnlijk overbodig.

Al zegt ie nog steeds: "waarschijnlijk overbodig".. Ik wil zekerheid.

[ Voor 10% gewijzigd door pim op 27-10-2026 11:09 ]

[RBakkum]

Het werkt in principe altijd met TTL van je records en als het record niet bestaat is er een TTL in je SOA defined. Dat betekend dat als je ditiseennieuwrecord.domain.nl gemaakt wordt dit direct overal werkt.

Echter stel iemand gebruikt de DNS servers van cloudflare en die heeft voor dat je dit record aangemaakt had deze naam al een keer gequeried, de cache van cloudflare zal dan de wildcard record in zijn cache opslaan. En als je TTL 86400s is, dan moet je een dag wachten voor dit refreshed wordt.
Gebruik je echter geen wildcard, dan is de SOA ttl van toepassing met dat het record niet bestaat. En als dat ook op dezelfde waarde staat, dan moet je dezelfde tijd wachten.

Dus er is geen zekerheid te geven. Maar de kans dat dit 'fout' gaat met een nieuwe naam is super klein. Nu komen er wel eens van die dictonary scans langs, maar grote kans is dat deze geen resolver van een provider / cloudflare / google gebruiken, dus dat die gebruiker dan misschien niet werkt is geen groot verlies lijkt mij.

[Groentjuh]

pim schreef op dinsdag 27 oktober 2026 @ 11:08:
Weet niet hoe anti-ai jullie zijn, maar vind het antwoord van claude wel interessant:

Croga zit ernaast. Resolvers cachen per exacte naam, niet per wildcard, dus een nieuw subdomein dat nog niemand heeft opgevraagd werkt direct. Alleen als iemand die exacte naam opvroeg voordat jouw A-record bestond, of als je een bestaand record wijzigt, krijg je vertraging. Je reverse proxies zijn dus waarschijnlijk overbodig.

Ja, maar als de exacte naam niet bestaat, dan zal daarna dus naar de wildcard opgezocht worden. Die bestaat wel, en heeft een TTL. Op die wijze zal deze exacte naam met de waarden van de wildcard gecached kunnen worden. En DNS Resolvers kunnen ook NXDOMAIN natuurlijk voor een duur opnemen in hun cache.

Het hele geheim zit natuurlijk in het stuk: "een nieuw subdomein dat nog niemand heeft opgevraagd".

Zolang niemand een bepaald domein heeft opgevraagd, dan zal er nergens cache voor zijn en dan gaat het goed.

[dehardstyler]

pim schreef op dinsdag 27 oktober 2026 @ 11:04:
[...]


Mijn systeem werkt automatisch.. Ik heb een multiplayer game gemaakt, waarbij automatisch droplets worden aangemaakt, als er meer gebruikers bij komen.

Ik heb reverse proxy servers opgezet om die gebruikers die achterlopen met de dns automatisch door te sturen.
En vraag me nu dus af of die reverse proxy servers overbodig zijn.

Ik ga het testen!

Maar zitten die droplets niet achter een load balancer? Misschien mis ik even iets, maar je hebt toch gewoon de DNS van je load balancer, en daar komt alles op binnen. Of je nou 5 of 10 droplets hebt, dat moet dan toch voor je DNS propagatie niet uitmaken?

Ik noem het hier trouwens een load balancer, maar volgens mij zou je het ook een matchmaker kunnen noemen. En daarachter zitten 5 servers (ik noem maar wat), de matchmaker bepaald waar je heen gaat en die matchmaker weet het IP van de droplet. Of ik moet dit verkeerd zien?

.

[pim]

Het subdomain wat ik genereer is een roomcode van random letters(voorbeeld: QXPK.location.domain.com).
Dus het is altijd een geheel nieuw domein wat in geen enkele cache voor zal komen.

Bedankt voor de replies! Ik ga het testen op duizenden gebruikers. Dus interessant of het 100% overal werkt. Ik zal nog een update geven als ik genoeg data heb.

[ Voor 3% gewijzigd door pim op 27-10-2026 11:25 ]

[pim]

dehardstyler schreef op dinsdag 27 oktober 2026 @ 11:25:
[...]

Maar zitten die droplets niet achter een load balancer?

Nee, ik maak geen gebruik van een bestaande loadbalancer.
Ik doe de loadbalancing zelf:

- Zoek server om te joinen
- Alle servers vol? Maak een server aan(API call in php). Stuur gebruiker er heen.

[ Voor 6% gewijzigd door pim op 27-10-2026 11:28 ]

[AW_Bos]

Uit ervaring weet ik dat een update snel gebeurt. Ze zeggen vaak dat het kan variëren van 'vrijwel direct' tot maximaal 24 uur. Dat laatste heb ik nooit meegemaakt. Maar als je wijzigingen doet, dan is een lage TTL waarde wel handig. Denk bijvoorbeeld aan een ander IP-adres te hangen aan een domein.

[Jester-NL]

AW_Bos schreef op dinsdag 27 oktober 2026 @ 13:03:
Uit ervaring weet ik dat een update snel gebeurt. Ze zeggen vaak dat het kan variëren van 'vrijwel direct' tot maximaal 24 uur. Dat laatste heb ik nooit meegemaakt. Maar als je wijzigingen doet, dan is een lage TTL waarde wel handig. Denk bijvoorbeeld aan een ander IP-adres te hangen aan een domein.

Mijn ervaring is dat het meestal snel gebeurd. Op je eigen DNS is het inderdaad (vaak) een kwestie van seconden. Maar het kan alsnog zijn dat een andere DNS-server zich heel vriendelijk aan de TTL van je zone houdt... zeker als ie daar recent iets van heeft opgehaald.

En (@AW_Bos) die 24 uur... dat is in de meeste gevallen als de TTL voor je DNS op 86400seconden hebt staan. Persoonlijk vind ik 3600 lang genoeg (en als ik aan het stoeien ben met mijn DNS ga ik (VOORDAT ik ga wijzigen) voor 60 of 120... en nadat ik dat heb ingesteld ga ik eerst een uurtje andere dingen doen

Zie ook het hoofdstukje over TTL hier: https://dnshelper.eu/interface.php

[Dekaasboer]

Je kan de uitrol van nieuwe dns records ook checken:

https://www.whatsmydns.net/

[PloeteraarCoffe]

Ben benieuwd hoe je test met die duizenden gebruikers is uitgevallen. Werkte het overal direct, of kwamen er toch nog mensen via de reverse proxy binnen?