0

I'm currently reading about resource record in the Domain Name System (DNS), in particular about the Time to live (TTL) aspect of start of authority records (SOA) records. It seems to me that the TTL was firstly defined in RFC 1034 and later redefined in RFC 2308.

A DNS configuration scan using dnsinspect.com on the domain stackexchange.com states the following:

SOA Minimum TTL. OK. Minimum TTL value is 86400. Recommended values [3600 .. 86400] (1 hour ... 1 day). Minimum TTL was redefined in RFC 2308, now it defines the period of time used by slaves to cache negative responses.

This made me wonder if the TTL value has any influence on information security. The only thing related to information security that I could think of is disaster recovery (DR) in the sense of availability (CIA triad). From the Time to live (TTL) Wikipedia article:

Newer DNS methods that are part of a disaster recovery (DR) system may have some records deliberately set extremely low on TTL. For example, a 300-second TTL would help key records expire in 5 minutes to help ensure these records are flushed quickly worldwide. This gives administrators the ability to edit and update records in a timely manner. TTL values are "per record" and setting this value on specific records is sometimes honored automatically by all standard DNS systems worldwide. However, a problem persists in that some caching DNS nameservers set their own TTLs regardless of the authoritative records, thus it cannot be guaranteed that all downstream DNS servers have the new records after the TTL has expired.

In short: Does the Time-To-Live (TTL) value of DNS records (or SOA records in particular) have any security implications? What is safer having a value being too high or too low and what are the pros and cons of that security wise?

Related interesting article: Short DNS record TTL and centralization are serious risks for the internet

1
  • SOA record is mostly not used during normal DNS resolution, so its TTL is not very important. TTLs on some records can have implications specifically in amount of traffic hence resistance to disruptions, as explained in answers. Also remember that the TTL is an indication given by the remote, the client is expected to follow it but can override it, especially too small values are often discarded. And it is always a "maximum" a client is free to discard it earlier, for example if its cache is full for some reason Commented Apr 26, 2022 at 20:53

3 Answers 3

2

TL;DR

While Time-To-Live (TTL) has a small impact on the CIA triangle, it doesn't usually carry a lot of inherent risk, nor does it generate a great deal of residual risk when mitigated with common controls. Provided you have an appropriate threat model and a well-chosen set of controls for your DNS infrastructure, you can adjust TTL to suit the needs of the organization within reasonable parameters.

Analysis and Recommendations

Does the Time-To-Live (TTL) value of DNS records (or SOA records in particular) have any security implications? What is safer having a value being too high or too low and what are the pros and cons of that security wise?

DNS security is primarily a function of using DNSSEC. The lime-to-live for DNS records defines the maximum time a caching server should cache a record without querying a more authoritative server again, but this doesn't have a lot of inherent risks. However, as you yourself pointed out, it may impact your overall security posture in various ways. Specifically:

  1. A long TTL means fewer lookups are done.

    • This has pros and cons regarding availability and server load, but primarily it will reduce your ability to propagate changed records quickly to clients using a caching DNS resolver. This is often mitigated by using a virtual or floating IP, but it's something to keep in mind.
    • Queries that rely on cached results rather than the start-of-authority (SOA) lookups can be at risk for cache poisioning, but depending on your threat model a shorter or longer TTL won't modify this risk very much. A better control is simply to ensure that your primary caching servers query the SOA directly when possible, as TTL is really an advisory value rather than one that is enforced at all layers.
  2. A short TTL means the results change more often.

    • This has pros and cons regarding freshness of data for caching clients, but can put more load on servers, increase network traffic, and can cause values to change more often.
    • While it won't dramatically increase the risk of man-in-the-middle or poisoned caches, a shorter TTL for records that change often will certainly make it harder to validate that the record hasn't changed unexpectedly unless you apply some additional controls (e.g. DNSSEC or some other means of host verification such as known SSH keys).
    • A common practice when changing A and PTR records is to reduce the TTL ahead of the changes, so this represents a bit of metadata about your activities. Again, while not a large inherent risk, it may or may not belong in your threat model.

While not a comprehensive list of all the differences, so think of these examples as representative of a slider where moving the slider more to one side or the other affects the TTL-related tradeoffs. The optimal "slider position" for your specific organization will vary, and can change over time.

Common DNS Security Controls

If you're concerned about DNS security, entire books are written on the subject. However, the advice in many of these books primarily boil down to a few key things:

  1. Turn off zone tranfsers when possible.
  2. Use DNSSEC to secure your DNS data if supported by your infrastructure.
  3. Host hardened and well-monitored caching servers inside your network perimeter to provide a better way to prevent or detect DNS-related tampering.
  4. Use firewalls, IPSec, DNS over HTTPS, and other network-layer controls to ensure that your clients aren't vulnerable to UDP packets from untrusted servers that respond faster than your known-good caching or SOA servers.
  5. Use additional controls to validate resolved hostnames when connecting to them besides their DNS records, e.g. valid SSL certificates, known OpenSSH host keys, and so forth.

This isn't meant to be a comprehensive list. It's just a very small catalog of controls that are generally more meaningful than the TTL itself. Like everything else in security, the TTL value of your DNS records represents a set of tradeoffs, but the TTL itself is rarely a primary risk vector.

As always, your threat model and use cases may vary. Nevertheless, this should give you a reasonable starting point for how to evaluate these issues within your specific context.

1

TTL essentially defines a cache lifetime, and caches always suffer from the same issues: Too short a lifetime and the cache becomes inefficient. Too long a lifetime and it'll take long before changes propagate, especially if multiple layers of caches are used.

So in theory, a shorter TTL would be beneficial in terms of "freshness" of the record, but you run into the dangers of generating a high load on the server, as clients will constantly ask for the new record. Furthermore, as you stated in your question, other DNS servers may choose to ignore extremely short cache lifetimes and use a different lifetime instead.

A longer TTL has the opposite effect, reducing load on the server, while risking that any changes will not propagate quickly, leaving your users unable to connect to your server.

2
  • I use a short TTL (10 minutes) a day before a hosting change, change the hosting provider and change back to the default TTL. This way my clients will hit the wrong server for just a short window.
    – ThoriumBR
    Commented Apr 19, 2022 at 14:23
  • 1
    @MechMK1 you should probably mention the cache poisoning downside where longer TTLs force the compromised DNS client to cache the poisoned query for longer, hence making remediation longer.
    – sandyp
    Commented Apr 19, 2022 at 20:34
1

It's a double-edged sword.

If you make your TTL shorter, and your DNS provider has an outage: Clients won't be able to resolve your DNS after the TTL times out, so they won't be able to find your server.

If you make your TTL longer, and your data center has an outage: Pivoting to a backup server at another data center won't help, because clients will still be resolving to the cached DNS records that point to your primary servers at the data center where there is an outage.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .