ResolveDB

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.

Native DNS and DoH now observe each identity item's facts and validity windows together. A query during synchronization can finish with the complete earlier item or the complete replacement, including the TTL derived from that same window. Removing an item does not invalidate an observation already held by an in-flight query. Current answers stop being cacheable at the selected window's exclusive end; current gap negatives stop at the next window's inclusive start. The remaining lifetime is rounded down when the DNS response is assembled.

Explicit history requires a synchronized validity window. A legacy current-only value without that evidence yields NODATA for an as-of query. Invalid indexes, inconsistent facts and storage failures yield SERVFAIL, not cacheable absence. For example:

dig TXT identity.bin-acme-k-411111-t-2023-11-14.datasets.public.v1.resolvedb.net

This returns a fact only if the dataset has a window covering that date at 00:00:00 UTC. Identity retains its rdb-id.v1 format; license, provenance and payload attestation are supplied by the separate manifest.

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.

Effective Lifetime

The shared answering contract requires cacheable results to respect known record expiry and relevant temporal validity transitions. For example, a public record expiring in ten seconds must not receive a one-hour effective DNS TTL. Settled historical facts retain their long-cache policy.

Shared hosted and identity answering implement these lifetime bounds. Authenticated hosted negative answers have zero DNS cache lifetime, including their SOA and denial-proof handling. Public negative caching remains enabled, bounded by known temporal transitions where relevant.

Record expiry, payload ttl hints, effective DNS TTL, and HTTP cache policy stay distinct. The target does not turn JSON's HTTP no-store policy into wire-DoH HTTP caching, or make a payload hint override a private answer's TTL 0.

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