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 rdbq query token in an auth- label
  • Returns DNS TTL 0
  • Uses Cache-Control: no-store through 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" +short

Public-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 +short

Customers 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

  1. Treat public RR TTLs as cache-lifetime directives, not guarantees of source freshness.
  2. Never place an auth-rdbq... qname in shared application caches or logs.
  3. Do not implement private-record freshness around DNS caching; private answers are TTL 0.
  4. Version public immutable data rather than relying on early cache invalidation.
  5. Use DoH or DoT when a query contains a bearer token.

Next Steps