Wiki · Concept · Last reviewed June 25, 2026

Recursive Operator Privacy Statement

A Recursive Operator Privacy Statement, or RPS, is RFC 8932's framework for disclosing how a DNS recursive resolver operator handles privacy-sensitive resolver data.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: DNS, RPS, privacy, resolver policy, metadata, agents, surveillance

Definition

A Recursive Operator Privacy Statement is the disclosure framework described in RFC 8932, Recommendations for DNS Privacy Service Operators, a Best Current Practice document published in October 2020 as BCP 232. RFC 8932 says a DNS recursive operator should publish an RPS to be compliant with that Best Current Practice.

The RPS is aimed at recursive resolver operators that offer DNS privacy services to stub resolvers or forwarders. It is not a general website privacy policy, a legal compliance document, or a claim that a resolver is anonymous. It is a structured way to tell users and auditors what the resolver does with DNS data on the wire, at rest, and when sending data onward.

Mechanism

RFC 8932 gives the RPS two main parts: Policy and Practice, followed by an accountability discussion. The policy section asks the operator to state whether IP addresses are treated as personal data, what data is collected and retained, whether it is shared with partners or third parties, how aggregated, pseudonymized, or anonymized data is handled, and what exceptions apply for malicious or anomalous behavior.

The same outline asks operators to declare associated entities, whether DNS data is correlated with other personal information, and whether responses are filtered, edited, or otherwise altered before being returned to clients. The filtering disclosure is meant to distinguish security filtering, mandatory legal filtering, voluntary legal filtering, commercial filtering, and other reasons.

The practice section turns the policy into operational detail: deviations from policy, client-facing transport and authentication capabilities, upstream privacy capabilities toward authoritative servers, support contacts, and links to separate data-processing statements where applicable.

Privacy Boundary

The RPS exists because encrypted DNS transport does not remove resolver trust. RFC 8932 says protocols that encrypt DNS messages on the wire can protect against certain attacks, but the resolver operator still has, in principle, full visibility into query data and transport identifiers for each user.

RFC 9076 gives the broader reason: almost every Internet activity starts with DNS, and a recursive resolver can see a concentrated view of name-resolution activity. An RPS does not solve that privacy problem. It makes the operator's commitments inspectable enough that users, enterprises, regulators, researchers, and agent operators can compare resolver behavior.

Agent Context

Agent systems make RPS documents more important because agents can create DNS traces at machine speed. A browser agent, code agent, crawler, or remote workspace may resolve model APIs, software registries, storage services, payment endpoints, identity providers, and document hosts without a human approving every lookup.

An organization cannot evaluate that privacy surface from the transport name alone. The relevant questions are whether the resolver logs agent lookups, how long it retains them, whether logs join account or workspace identifiers, whether upstream ECS is used, whether QNAME minimisation and EDNS padding are enabled, and whether filtered answers can change agent behavior. An RPS gives those questions a publication target.

Governance Use

For governance, require a resolver RPS before describing a resolver as privacy-preserving. The review should record the operator, publication URL, effective date, retention policy, filtering policy, data-sharing policy, treatment of IP addresses, support contact, and whether the RPS names concrete endpoints and capabilities rather than broad principles.

RFC 8932 also describes accountability mechanisms. Transparency reports may help users trust that operators follow published policies, independent monitoring can check features such as ECS, QNAME minimization, EDNS padding, filtering, and uptime, and a third-party auditor can verify compliance with the published RPS.

Limits

An RPS is not a protocol control, legal advice, certification, anonymity, consent, DNSSEC, or a guarantee that no abuse of data will occur. RFC 8932 explicitly says the outline is non-normative except for the order of headings, is limited to technical operation of DNS privacy services, is not exhaustive, and is not intended as legal or compliance documentation.

The RPS also depends on honesty, specificity, and verification. A vague statement that "we respect privacy" is not equivalent to naming retention periods, filtering categories, third-party sharing terms, endpoint authentication mechanisms, and accountability checks.

Source Discipline

Claims about the RPS definition, BCP status, DNS privacy service scope, policy and practice outline, accountability mechanisms, and non-legal limitation should cite RFC 8932. Claims about the DNSSEC Practice Statement analogy should cite RFC 6841. Claims about why DNS queries create privacy risk should cite RFC 9076.

Spiralist Reading

Spiralism reads the RPS as a confession form for infrastructure. The resolver does not become harmless by using privacy words. It becomes governable when it states what it sees, keeps, alters, shares, and proves.

For agents, that matters because machine work leaves machine-shaped DNS trails. A system that acts on a user's behalf should not hide the resolver trust bargain inside a default setting.

Sources

Return to Wiki