Staying alive: what is TTL and why is it important for your DNS setup?
Welcome to The Quirks of the DNS, a series of short blog posts where I highlight some of the odd corners of the Domain Name System (DNS)–the universal database for all things Internet. We will see some interesting issues that can occur with the DNS and I will give some recommendations for how to avoid problems.
In this post we will look at Time-to-Live (TTL), a field in every DNS record that tells DNS clients how long the information in that record is valid and, thus, how long it can be stored in the DNS client’s cache. You can think of TTL like the best before date on a milk carton. Once that date expires, the cache knows it has to throw away that milk carton and get a new one!
TTL and parent/child DNS records
In the DNS, the "handover" from a server serving a shorter name (se.) to one serving a longer name (netnod.se.) is expressed using records of the type NS (nameserver). A client asking the se. server for a name that ends in netnod.se. will only receive NS records telling the client to "go elsewhere" to look, namely to the servers that hold the information for netnod.se.
The records handed out by the se. server ("the parent") will look something like this:
netnod.se. 86400 IN NS nna.netnod.se.
netnod.se. 86400 IN NS nnb.netnod.se.
netnod.se. 86400 IN NS nnp.netnod.se.
netnod.se. 86400 IN NS nnu.netnod.se.The string netnod.se. to the left (termed the "owner name") tells us which subdomain ("child") is delegated; IN (the "class") tells us we're dealing with Internet-related information; NS (the "record type") tells us that we are looking at nameserver information for the child; and the names to the right (the "record data") tell us the names of the server machines that hold DNS information about netnod.se. and names "below" it.
The final field here, the number 86400, is referred to as the Time To Live (TTL). It informs the recipient of the data that it may rely on the data for (in this case) 86 400 seconds (= 24 hours) without having to come back to check again. The data may be stored locally ("cached") at the client for this amount of time.
QUIRK 1: All TTLs in a record set must be set to the same value
A "record set" (RRSET) is the complete set of all records with the same owner name, class, and type. In the example above, there is one record set for the [netnod.se., IN, NS] combination, and it consists of four records. The DNS treats record sets as "glued together" and they must always be transferred and interpreted as a group. If the record set is allowed to be split, different "players" in the DNS world will see different views of the DNS data, and the database will no longer be coherent and consistent.
The requirement for consistent views of the database leads to the requirement that the TTL value must be the same for all members of a record set. There are two reasons for this:
- Clients receive the RRSET and store it in their caches. All TTL values for all records in the cache are then continuously decreased and when the TTL for a record reaches 0, the record will be removed from the cache. If the members of an RRSET have different TTLs they will be thrown out at different times, which "forces" the cache system to split the record set into pieces, and the coherence requirement is no longer met. The cache will only contain some of the pieces. The picture of the database is no longer correct. It is therefore important that all of the records in an RRSET are removed from the cache at the same time. The absence of records in the cache will force the client to request a "fresh" RRSET from the source, and the cache will again contain consistent data.
- When secure DNS (DNSSEC) is involved, this becomes even more important. In DNSSEC, crypto signatures are used as a tool for the client to validate that the DNS data received hasn't been tampered with during its journey across the network. DNSSEC signs record sets, not single records. An important part of the signature is "the original TTL" (i.e., what the TTL was in the beginning, before the cache started to decrease it). That original TTL is a single value that covers the entire RRSET, and if the records in the set originally had different values, the signature wouldn't be correct, and validation of the data would be impossible.
RECOMMENDATION: Make sure all records in a record set have the same TTL.
QUIRK 2: NS records for parent and child must be in sync
The NS records need to be present both in the parent (who "gives out authority") and in the child ("who receives authority"). The records look exactly the same in both locations, but are not (unless using very recent additions to the DNS protocol) automagically kept in sync. This has to be done manually. As we all know, human beings are not very good at keeping things in sync, so this gives ample opportunity for the systems to diverge. Typically two things happen:
- The administrators of the child data change the set of nameservers and forget to inform the parent about their wish to do so. If the child admins change all of the servers, things will stop working. If they change only a few, things may continue to work in a degraded fashion.
- The records in the parent have a different TTL from the ones in the child. This is less problematic but may lead to unnecessary DNS traffic if the TTLs for the records in the child database have a lower TTL than those in the parent. Since the NS records in the child database are considered "authoritative" (i.e., having a higher "priority") than the ones in the parent, the child has the ability to "muck around" with the TTL without the parent's knowledge or consent. If the parent designs its DNS systems for a certain traffic pattern which is the expected result of setting the TTL values for its children to a specific value, they may be in for a surprise if the children set their TTL values for the NS records to something completely different.
RECOMMENDATION: as the administrator of child data, align your TTL values for the NS records with the ones that appear in the database of your parent.
I hope you have found this post useful. Stay tuned for further posts as we delve deeper into the quirks of the DNS! In the meantime, if you have any questions about your DNS setup and how Netnod’s DNS anycast service can help, you can contact us here.
