in een ideale wereld, zou de DNS zijn als een van die Zoals-Gezien-Op – TV rotisserie ovens-set it and forget it. Echter, het Internet is een dynamisch veranderende plaats en wat relevant kan zijn in het ene moment misschien niet het volgende.
om hiermee om te gaan, werd de DNS ontworpen met een mechanisme om records te vernieuwen en ervoor te zorgen dat gebruikers altijd het meest relevante antwoord kregen toen ze erom vroegen.
de basis
tijd om te leven, of kortweg TTL, is het soort vervaldatum dat op een DNS-record wordt gezet., De TTL dient om de recursieve server of lokale resolver te vertellen hoe lang het deze record in zijn cache moet bewaren. Hoe langer de TTL, hoe langer de resolver die informatie in zijn cache houdt. Hoe korter de TTL, hoe korter de tijd dat de resolver die informatie in zijn cache houdt.
bijvoorbeeld, we hebben example.com. Example.com heeft een A-record aan de top van de zone om ons naar een server te leiden. Met een ttl van 3600 seconden, of 1 uur, dat betekent dat als een recursieve server leert over example.com, het zal die informatie over de A-record op te slaan op example.com een uur lang., Iedereen die dezelfde resolver gebruikt zal hetzelfde antwoord krijgen, en aan de gezaghebbende kant, zal er geen query naar de server zijn tenzij de TTL opraakt.
Best Practices
TTL ‘ s zijn niets om lichtvaardig op te nemen – ze kunnen direct invloed hebben op de hoeveelheid query volume die is toe te schrijven aan uw gezaghebbende service, en in het geval dat het nodig is om snel de record te veranderen, kan resulteren in een langere dan verwachte verandering verspreiding voor alle gebruikers.,
voor records die gebruikmaken van een soort geavanceerd verkeersmanagementscenario, zoals de filterketen van NS1, is het het beste om de TTL zo kort mogelijk te houden. Op deze manier, wanneer een wijziging wordt uitgevoerd door het systeem, gebruikers aan de andere kant die de naam vragen krijgen de meest recente informatie. Het is vermeldenswaard dat de meeste recursieve servers een TTL die korter is dan 30 seconden eigenlijk niet begrijpen – hoewel we u niet zullen stoppen om lager te gaan dan dat, zijn de resultaten op de lange termijn misschien niet gunstig.,
voor records die zelden veranderen, zoals TXT-of MX-records, is het het beste om die ergens tussen een uur (3600s) en een dag (86400s) te bewaren. Wanneer het tijd is om wijzigingen aan te brengen met betrekking tot dit soort records, kan het betaamt u om de TTL naar een korter interval te wijzigen voordat u wijzigingen aanbrengt om ervoor te zorgen dat de wijzigingen snel worden doorgegeven.
de SOA TTLs
aan de bovenkant van elke DNS-zone, in het begin van autoriteit (SOA), zijn er vijf TTL-waarden die een hoger doel dienen in de DNS.
SOA TTL-het interval waarop de SOA-record zelf wordt ververst.,
verversen TTL – het interval waarmee secundaire servers (secundaire DNS) worden ingesteld om het primaire zonebestand van de primaire server te verversen.
probeer TTL opnieuw – de snelheid waarmee een secundaire server het primaire zonebestand opnieuw probeert te verversen als het initiële verversen mislukt is.
expiration TTL-als het vernieuwen en opnieuw proberen herhaaldelijk mislukt, is dit de periode waarna de primaire als verdwenen moet worden beschouwd en niet langer als gezaghebbend voor de gegeven zone.,
NX TTL – in het geval dat het aanvragen van het domein resulteert in een niet-bestaande query (NXDOMAIN), is dit de hoeveelheid tijd die door de recursor wordt gerespecteerd om het nxdomain-antwoord te retourneren.
Het wordt aanbevolen om deze TTL ‘ s niet te wijzigen tenzij u een zeer specifieke behoefte heeft om dit te doen, wat vaak een zeer zeldzaam geval is.