Caching & TTL
Understand which ResolveDB answers can use shared DNS caches and which always use TTL 0.
Cacheable Surfaces
DNS TTL caching applies through standard DNS and DoH wire to data that is safe
to share publicly. The DoH JSON endpoint uses HTTP no-store:
- Public weather, finance, GeoIP, unit, sun, and moon services
- Public dataset manifests and identity facts
- Operator-managed public-read demonstrations such as Hooli
Recursive resolvers and local DNS caches may reuse those answers according to their RR TTL. Resolver floors, caps, prefetching, eviction, and RFC 8767 stale serving can change observed behavior.
Private Hosted Records
Customer namespaces are private by default. Every successful private answer:
- Requires the namespace's opaque
rdbqquery token in anauth-label - Returns DNS TTL 0
- Uses
Cache-Control: no-storethrough the DoH JSON endpoint
The record's configured ttl_seconds does not make an authenticated private
answer cacheable. TTL 0 directs compliant caches not to retain
bearer-token-authorized data; intermediaries can still apply a brief floor or
stale-serving policy.
dig +tls-ca +tls-hostname=dot.resolvedb.io @dot.resolvedb.io \
TXT "get.auth-${RDBQ}.config.your-namespace.v1.resolvedb.net" +shortPublic-Read Records
public_read is an operator-only control used for living demonstrations. It is
not a customer setting. Public-read answers are tokenless and use the normal
cacheable public get TTL.
For example, this read-only Hooli fixture can be cached:
dig TXT get.dark-mode.flags.hooli.v1.resolvedb.net +shortCustomers cannot create or modify the reserved hooli, hooli-staging, or
hooli-dev namespaces.
Dataset TTLs
Dataset identity queries normally use a short TTL. An as-of fact whose validity window is safely in the past can use a longer immutable TTL. Dataset manifests are versioned and attested; clients should still verify the payload attestation when provenance matters.
Negative Responses
ResolveDB's authoritative zone normally represents an unknown UQRP name as
NOERROR with no answer records (NODATA). DNSSEC-protected negative responses
use NSEC black lies. Resolver negative-caching behavior follows the DNS response
and resolver policy.
Failures such as SERVFAIL, FORMERR, and REFUSED are not successful data
answers and should not be application-cached as records.
Application Guidance
- Treat public RR TTLs as cache-lifetime directives, not guarantees of source freshness.
- Never place an
auth-rdbq...qname in shared application caches or logs. - Do not implement private-record freshness around DNS caching; private answers are TTL 0.
- Version public immutable data rather than relying on early cache invalidation.
- Use DoH or DoT when a query contains a bearer token.