KvdnBerg schreef op zondag 10 augustus 2025 @ 17:40:
[...]
Stond op 3600 maar dat was nog vanuit de vorige keer dat ik het bij QDC heb aangepast waar dat de standaard waarde was, maar toch werden die wijzigingen direct opgepakt door de DNS, nu dus niet meer. Ook een nieuw dns record is niet direct beschikbaar (in dat geval kon ik het oplossen door de txt records voor LetsEncrypt na het genereren van het nieuwe certificaat te verwijderen en ze de volgende keer nieuw aan te maken).
Mijn voornaamste punt is dus dat de DNS wijzigingen/nieuwe DNS regels direct werken zoals ik dat bij QDC gewend was. Vandaar ook mijn vraag, ik snap dat er zat topics zijn over domein/hosting partijen in het algemeen maar het gaat me specifiek om deze vraag.
Als je niet snapt hoe TTL werkt kan je behoorlijk bedrogen uit gaan komen bij je nieuwe hoster. Je hebt verschillende TTL-waarden. Die van je record zelf, waarmee wordt aangegeven hoe lang andere DNS-servers die in cache moeten houden, en die van je zone (SOA) waarbij je in dit geval naar het MINIMUM-veld (de laatste) moet kijken. Die geeft aan hoe lang een record wat niet bestaat "onthouden" moet worden, zodat je niet de DNS-server van je host lastig blijft vallen bij een typo bijvoorbeeld.
Neem als voorbeeld een zone example.com met MINIMUM 1800 en een CNAME-record
www.example.com -> a.example.com met een TTL van 3600. Normaliter als je een record opvraagt doe je dat bij je eigen caching nameserver, die dat vervolgens verder upstream bij andere caching nameservers of zelfs bij de root-servers opvraagt. Dat record wordt in alle tussenliggende caching nameservers gecached voor "TTL seconden".
Als je nou
www.example.com aanpast zodat 'ie naar b.example.com wijst en direct daarna dat opvraagt kunnen er verschillende dingen gebeuren:
1. jij of een andere gebruiker van jouw DNS-server of een van de andere tussenliggende caching DNS-servers heeft in de afgelopen 3600 seconden (specifiek X seconden geleden), maar voorafgaand aan jouw wijziging, dat record opgevraagd. Die staat dan nog in de cache en wordt vanuit de cache geserveerd, dus
niet opgevraagd bij de nameservers van je domein (hostingpartij). Ook al heb je de TTL aangepast naar 5 seconden toen je de wijziging deed, dat weten de tussenliggende servers nog niet, dus die gaan ook niet kijken totdat de originele TTL verlopen is. Resultaat: a.example.com (TTL 3600-X).
2. in de afgelopen 3600 seconden is dat record
niet opgevraagd bij een van die genoemde caching servers. Het hele riedeltje wordt doorlopen en het record wordt bij de nameservers van je domein opgevraagd. Resultaat: b.example.com (TTL 3600).
3. er zit een caching server tussen die niet netjes meespeelt en of de boel altijd opvraagt (resultaat 2), of lekker een eigen TTL hanteert van 86400 ofzo (resultaat 1). Maar dat komt tegenwoordig niet heel veel meer voor.
Analoog hieraan bestaan deze scenario's ook voor het aanmaken van een nieuw CNAME test.example.com ->
www.example.com. Bij het opvragen van test.example.com kan dan het volgende gebeuren:
1. iemand heeft in de afgelopen 1800 seconden (specifiek X seconden geleden) maar vóór het aanmaken van dat record test.example.com opgevraagd en als antwoord gekregen dat het niet bestaat. Omdat het record zelf niet bestaat is er geen TTL voor maar wordt de MINIMUM in je SOA gehanteerd. Resultaat: NXDOMAIN test.example.com (TTL 1800-X)
2. het is niet eerder opgevraagd in de afgelopen 1800 seconden, dus de nameservers van je domein worden weer geraadpleegd. Resultaat:
www.example.com (TTL 3600).
Waarschijnlijk ben je bij je wijzigingen relatief vaak tegen scenario 2 aangelopen en recent vaker tegen scenario 1. Dat is verder onafhankelijk van je DNS-hostingpartij dus diezelfde problemen kunnen bij elke partij optreden. Wat wel kan is dat je nieuwe hostingpartij standaard lagere TTLs hanteert, wat je zelf gewoon in had kunnen stellen, en dat je daarom denkt dat ze "beter" zijn. Dat kost die hostingpartij vooral meer data omdat records vaker bij hun servers worden opgevraagd omdat ze minder lang gecached worden.
Bij het aanmaken of wijzigen van records ga je bovendien het beste ervanuit dat het minimaal een minuut duurt voordat ze bij alle nameservers van je hoster zijn doorgevoerd. Dat kan ook nog het verschil tussen scenario's 1 en 2 betekenen. Daarom query ik bij wijzigingen eerst altijd direct de nameserver van mijn domein voordat ik het in een browser intyp (wat de normale caching nameservers gebruikt). Maar omdat het uiteindelijke resultaat niet alleen maar van jezelf afhangt maar ook van wat alle andere gebruikers van die tussenliggende servers doen, is het beste gewoon jezelf neer te leggen bij het feit dat je worst-case gewoon de hele TTL moet wachten voordat je wijzigingen zichtbaar zijn. Als het écht direct doorgevoerd moet worden dan doe je dat in twee stappen: eerst verlaag je de TTL tot 60 of zelfs 10 ofzo, dan wacht je de gehele originele TTL af (3600) en pas daarna doe je de daadwerkelijke wijziging. Dan is de crossover-periode waarin je beide antwoorden terug zou kunnen krijgen zo kort mogelijk.
/u/34186/crop62e07d174532d_cropped.png?f=community)
Heb je het al eens getest op de server achter het NS-record van je domein?/u/53159/Isabelleicon6060.JPG?f=community)
:strip_icc():strip_exif()/u/267901/crop65df6ef259fc8.jpg?f=community)
:strip_icc():strip_exif()/u/91018/dgtw.jpg?f=community)