DNS record TTLs in 2026: a 600-domain measurement and how to choose a value

TTL is how long resolvers keep a DNS answer. A short TTL means an address change is picked up quickly; a long one means fewer queries reach your name servers and the site survives their temporary unavailability.

The commonest mistake is to treat TTL as a site-performance parameter. It barely affects load time: the DNS answer is cached at the ISP and in the browser, and for a returning visitor it costs nothing. TTL is a manageability parameter: it determines how fast you can move traffic during an incident.

On 27 August 2026 we queried A, NS and MX record TTLs for 600 domains (150 per zone):

There are two differences, running in opposite directions. On the A record the .ru median is twice as long and the share of short TTLs is 25% against 66–69%. On the NS record, conversely, the .ru value is six times shorter: one hour against six.

Caveats: these are domains somebody brought to our tools, not a random slice of a zone; comparing zones is sound as they were collected identically. The median is taken over the first record of each type.

A five-minute TTL on an A record is almost never an administrator’s decision but a CDN default: it exists so traffic can be shifted between nodes on failure. So the share of short TTLs in a zone effectively measures CDN penetration rather than owner awareness.

Our own HTTP/3 measurement supports this: there 7.1% of .ru sites advertise support against 36.5% in .com, and two thirds of those advertising in .com sit behind one particular CDN. Two independent signals point the same way.

The NS record is a different case: six hours is typical of large managed DNS services, while one hour is a common default in hosting control panels. Here the short value is no advantage — name servers change rarely, while the extra queries to the zone are continuous.

• Normal operation — one to four hours on A records. That is enough to spare your name servers while keeping migrations predictable.
• A day before a planned migration, drop the TTL to 5 minutes, wait for the old value to expire in resolvers, and only then change the address. Restore it afterwards. This is the only way to make an address change fast — TTL cannot be shortened retroactively.
• Keep NS long — several hours at least. Changing name servers requires registrar action anyway, and a short TTL here only adds queries.
• Do not set 60 seconds "just in case". Large providers’ resolvers often clamp very short values up to their own minimum, so there is no gain and the load rises.

To see your domain’s current TTLs, use the DNS lookup; to see how long a change takes to spread across resolvers, the propagation checker.