---
title: TTL (DNS)
description: "DNS Time To Live: how long resolvers may cache an answer before asking again. A key lever for propagation speed."
canonical: https://penasihathosting.com/en/hosting-wiki/dns-ttl
type: wiki
locale: en
updated: 2026-07-15
author: Willya Randika
---

# TTL (DNS)

## Overview

- **Summary:** DNS Time To Live: how long resolvers may cache an answer before asking again. A key lever for propagation speed.
- **Author:** Willya Randika ([profile](/penulis/willya-randika))

## Article

**TTL** (Time To Live) in [DNS](/en/hosting-wiki/dns-domain-name-system) is how many seconds a record may stay cached in resolvers before they ask nameservers again. That value drives how fast DNS changes appear worldwide and sits at the heart of [domain propagation](/en/hosting-wiki/domain-propagation).

Understanding TTL helps you plan hosting moves, mail changes, or [Cloudflare](/en/hosting-wiki/cloudflare) cutovers without lingering surprises across networks and devices.

## A Simple Analogy

TTL is the expiry date on a photocopied map. Until the copy expires, people keep using the old map even if headquarters already printed a new one. Lowering TTL is like printing copies that go stale faster so people fetch the update sooner.

## Common Values

| TTL | Roughly | When to use |
| --- | --- | --- |
| 300 (five minutes) | Changes quickly | Before a migration or cutover |
| 3600 (one hour) | Balanced | Everyday operation for many sites |
| 86400 (twenty-four hours) | Changes slowly | Rarely edited records |

A safe practice is to lower TTL before cutover day, for example twenty-four hours ahead, migrate, then raise it again once stable so DNS queries are not needlessly chatty.

## Pre-Migration Strategy

1. Inventory important records in the active zone  
2. Lower TTL on records that will change  
3. Wait until the old TTL has largely expired at resolvers  
4. Change A, MX, or nameserver records per plan  
5. Verify with [DNS Lookup](/en/tools/dns-lookup) from more than one place when you can  

## What to Watch For

- Lowering TTL after a change does not help clients that already cached the old value  
- Very low TTL means more DNS queries; usually minor, not zero  
- CDNs and proxies add their own caching beyond DNS TTL  
- High MX TTLs make mail fixes feel slow  
- Align team expectations: changed in the panel does not mean every user sees it instantly  

## FAQ

<Accordion>
  <AccordionItem title="Ideal TTL for a normal site?">
    One hour, or 3600 seconds, is a solid default. Lower it when you plan a major move.
  </AccordionItem>
  <AccordionItem title="Does TTL control browser HTML cache?">
    No. This TTL is for DNS records only. Page caching uses HTTP headers, plugins, or a CDN.
  </AccordionItem>
  <AccordionItem title="Why do I still hit the old IP with TTL 300?">
    Some resolvers hold cache longer than ideal, or you edited a non-authoritative zone.
  </AccordionItem>
  <AccordionItem title="Must every record share one TTL?">
    No. Frequently changed records can be lower; stable records can stay higher.
  </AccordionItem>
</Accordion>