In einer idealen Welt wäre der DNS wie einer dieser TV-Rotisserie-Öfen-stellen Sie ihn ein und vergessen Sie ihn. Das Internet ist jedoch ein sich dynamisch verändernder Ort, und was in einem Moment relevant sein kann, ist möglicherweise nicht der nächste.
Um dies zu bewältigen, wurde das DNS mit einem Mechanismus zum Aktualisieren von Datensätzen entwickelt, um sicherzustellen, dass Benutzer bei ihrer Anfrage immer die relevantesten Antworten erhalten.
Die Grundlagen
Time To Live, oder kurz TTL, ist die Art von Ablaufdatum, das auf einem DNS-Eintrag gesetzt wird., Die TTL dient dazu, dem rekursiven Server oder lokalen Resolver mitzuteilen, wie lange er diesen Datensatz in seinem Cache behalten soll. Je länger die TTL, desto länger hält der Resolver diese Informationen in seinem Cache. Je kürzer die TTL ist, desto kürzer hält der Resolver diese Informationen in seinem Cache.
Zum Beispiel haben wir example.com. Example.com hat einen A-Record an der Spitze der Zone, um uns auf einen Server zu verweisen. Mit einer TTL von 3600 Sekunden oder 1 Stunde bedeutet dies, dass ein rekursiver Server davon erfährt example.com, es speichert diese Informationen über den A-Datensatz unter example.com für eine Stunde., Jeder andere, der denselben Resolver verwendet, erhält dieselbe Antwort, und auf der autoritativen Seite wird keine Abfrage an den Server gesendet, es sei denn, die TTL läuft aus.
Best Practices
TTLs sind nichts zu leichtfertig – sie können sich direkt auf die Menge des Abfragevolumens auswirken, die Ihrem autorisierenden Dienst zuzurechnen ist, und im Falle einer schnellen Änderung des Datensatzes kann dies zu einer längeren als erwarteten Änderungsausbreitung an alle Benutzer führen.,
Für Datensätze, die eine Art Advanced Traffic Management-Szenario nutzen, z. B. die Filterkette von NS1, ist es am besten, die TTL so kurz wie möglich zu halten. Auf diese Weise erhalten Benutzer am anderen Ende, die den Namen anfordern, die neuesten Informationen, wenn eine Änderung vom System vorgenommen wird. Es ist erwähnenswert, dass die meisten rekursiven Server eine TTL, die kürzer als 30 Sekunden ist, nicht wirklich verstehen – während wir Sie nicht davon abhalten werden, tiefer zu gehen, sind die Ergebnisse auf lange Sicht möglicherweise nicht günstig.,
Für Datensätze, die sich selten ändern, wie z. B. TXT-oder MX-Datensätze, ist es am besten, diese irgendwo zwischen einer Stunde (3600) und einem Tag (86400) aufzubewahren. Wenn es an der Zeit ist, Änderungen in Bezug auf diese Arten von Datensätzen vorzunehmen, können Sie die TTL möglicherweise auf ein kürzeres Intervall reduzieren, bevor Sie Änderungen vornehmen, um sicherzustellen, dass die Änderungen schnell weitergegeben werden.
Die SOA TTLs
An der Spitze jeder DNS-Zone, in der Start of Authority (SOA), gibt es fünf TTL-Werte, die einen höheren Zweck im DNS dienen.
SOA-TTL – Das Intervall, in dem der SOA-Datensatz aktualisiert wird.,
TTL aktualisieren-Das Intervall, in dem sekundäre Server (sekundärer DNS) so eingestellt sind, dass die primäre Zonendatei vom primären Server aktualisiert wird.
TTL erneut versuchen – Die Rate, mit der ein sekundärer Server erneut versucht, die primäre Zonendatei zu aktualisieren, wenn die anfängliche Aktualisierung fehlgeschlagen ist.
Ablauf TTL – Wenn Refresh und Retry wiederholt fehlschlagen, ist dies der Zeitraum, nach dem die primäre sollte als weg und nicht mehr maßgebend für die angegebene Zone.,
NX TTL-Für den Fall, dass das Anfordern der Domäne zu einer nicht vorhandenen Abfrage (NXDOMAIN) führt, ist dies die Zeit, die der Rekursor für die Rückgabe der NXDOMAIN-Antwort einhält.
Es wird empfohlen, diese TTLs nicht zu ändern, es sei denn, Sie haben eine sehr spezifische Notwendigkeit, dies zu tun, was oft ein sehr seltener Fall ist.