The record's TTL makes a change slow to take effect
What this check looks for
This record tells resolvers to remember it for a long time. Any change you make — including undoing a mistake — takes that long to reach everyone, and there is nothing you can do to speed it up.
Why it matters
The TTL you publish today sets your recovery time tomorrow. A record cached for a day means a bad deployment stays live for a day for a share of your visitors, however quickly you fix the record itself.
When the check passes, your report says: “The TTL is low enough for a change to take effect quickly”.
What it costs your score
When this check fails it removes 4 points from your DNS score, before the status, confidence and repeat multipliers are applied. DNS carries a weight of 10 in the overall score.
It shares the dns.propagation.ttl family ceiling of 4 points: however many findings that family produces, together they cannot remove more than that from DNS. One underlying problem showing up in several places is still one problem.
- Severity
- low
- Default confidence
- confirmed
- Status when triggered
- warn
- Deduction
- 4 points
- Family cap
- dns.propagation.ttl · 4
- Category
- DNS
- Module
- Dns propagation
- Fix owned by
- dns host
- In the ruleset since
- 2026.09
How to fix it
Lower the TTL to 300 seconds before any planned change, and restore it afterwards.
The TTL in force before a change decides how long the change takes to reach everyone.
Set the TTL on this record to 300 seconds.
Wait a full old-TTL period — ‹ttl human› — so every cache has expired the longer value.
Make the change, and confirm it with a propagation check.
Restore the TTL to 3600 once the new value is everywhere.
How to confirm it worked
dig +noall +answer ‹type› ‹domain› — check the TTL column
A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.
Technical detail
‹type› at ‹domain› is published with a TTL of ‹ttl› seconds (‹ttl human›); above ‹ceiling› a planned change needs its own preparation window. The technique is fixed and works everywhere: lower the TTL, wait one *old* TTL period so every cache has picked up the shorter value, then make the change, then restore the normal TTL once it has settled. Doing it in that order is what makes a migration take minutes instead of a day.
Standards and references
- RFC 1035 §3.2.1 — Format § 3.2.1
Test this on your domain
Run the check that produces this finding, on its own, against any domain.