Records are published with a very short TTL
What this check looks for
Your records tell resolvers to forget them almost immediately, so the world re-asks your nameservers constantly. It adds latency to every first visit and load you are not being paid for.
Why it matters
A very low TTL removes the caching that makes the DNS fast. Every visitor whose resolver has just expired the record waits for a full round trip to your nameservers, and an outage at those nameservers becomes visible within seconds instead of being absorbed by caches.
When the check passes, your report says: “Record TTLs are long enough to be worth caching”.
What it costs your score
When this check fails it removes 3 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.records.ttl family ceiling of 6 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
- 3 points
- Family cap
- dns.records.ttl · 6
- Category
- DNS
- Module
- Dns records
- Fix owned by
- dns host
- In the ruleset since
- 2026.09
How to fix it
Raise the TTL on these records back to a normal value once the change has settled.
A permanently low TTL removes caching and makes every nameserver hiccup visible immediately.
Confirm no migration is in progress for these records.
Set the TTL to 3600 seconds (1 hour) for records that change rarely, or 300 seconds for records you expect to move.
Lower it again deliberately, a full TTL before your next planned change.
How to confirm it worked
dig +noall +answer A ‹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
These record sets publish a TTL below ‹minimum seconds› seconds: ‹record list›. A low TTL is the correct setting *during* a migration and the wrong one as a permanent state. RFC 1035 §3.2.1 leaves the value to the operator; the practical floor is the point at which caching stops helping, which is a few minutes. Restore a normal TTL once the change you lowered it for has settled.
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.
Other dns records checks
- The domain has no IPv6 address
- The domain apex is a CNAME, which the DNS does not allow
- A CAA record marked critical uses a tag no authority understands
- CAA forbids every authority from issuing a certificate
- The CAA reporting address is not a usable URL
- No CAA record says which authorities may issue certificates
- Two TXT records of the same kind are published at one name
- The domain has no A or AAAA record
- Records are published with a very long TTL
- A TXT record looks cut off at the 255-character limit
- A wildcard record answers for every subdomain