![]() It is recommended to not modify these TTLs unless you have a very specific need to do so, which is often a very rare case.If you would like to jump directly to the specifics, use the menu below: NX TTL - In the event that requesting the domain results in a non-existent query (NXDOMAIN), this is the amount of time that is respected by the recursor to return the NXDOMAIN response. Retry TTL - The rate at which a secondary server will retry to refresh the primary zone file if the initial refresh failed.Įxpiry TTL - If Refresh and Retry fail repeatedly, this is the time period after which the primary should be considered gone and no longer authoritative for the given zone. Refresh TTL - The interval at which secondary servers (secondary DNS) are set to refresh the primary zone file from the primary server. SOA TTL - The interval at which the SOA record itself is refreshed. The SOA TTLsĪt the top of every DNS zone, in the Start of Authority (SOA), there are five TTL values that serve a higher purpose in the DNS. When it does come time to enact changes with regard to these types of records, it may behoove you to change the TTL down to a shorter interval before enacting any changes to ensure that the changes are propagated quickly. It’s worth noting that most recursive servers do not actually understand a TTL shorter than 30 seconds - while we won’t stop you from going lower than that, the results may not be favorable in the long run.įor records that rarely change, such as TXT or MX records, it’s best to keep those somewhere between an hour (3600s) and a day (86400s). This way, when a change is enacted by the system, users on the other end requesting the name are given the most recent information. ![]() TTLs are nothing to take lightly - they can directly affect the amount of query volume that is attributable to your authoritative service, and in the event of needing to quickly change the record, can result in longer than expected change propagation to all users.įor records that leverage a sort of advanced traffic management scenario, such as NS1’s Filter Chain, it’s best to keep the TTL as short as possible. Anyone else who uses that same resolver will get the same answer, and on the authoritative side, there will be no query to the server unless the TTL runs out. With a TTL of 3600 seconds, or 1 hour, that means that as a recursive server learns about, it will store that information about the A-record at for one hour. has an A-record at the apex of the zone to point us to a server. The shorter the TTL, the shorter amount of time the resolver holds that information in its cache.įor example, we’ve got. The longer the TTL, the longer the resolver holds that information in its cache. ![]() The TTL serves to tell the recursive server or local resolver how long it should keep said record in its cache. Time To Live, or TTL for short, is the sort of expiration date that is put on a DNS record. To cope with this, the DNS was designed with a mechanism to refresh records and ensure that users were always given the most pertinent answer when they requested it. ![]() ![]() However, the Internet is a dynamically changing place and what may be relevant in one moment may not be the next. In an ideal world, the DNS would be like one of those As-Seen-On-TV rotisserie ovens - set it and forget it. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |