Summary

  • A Response Policy Zone is a transportable set of triggers and proposed actions. AXFR, IXFR and TSIG can establish which version arrived from which publisher; they do not establish that an entry is accurate or its consequence proportionate for every client.
  • The subscribing resolver makes the decisive choices: feed order, exceptions, action overrides, client scope, DNSSEC behavior, TTL, readiness and diagnostics. It therefore owns the rewritten answer rather than acting as a neutral courier.

Consider a resolver that receives an external policy-zone update exactly as designed. The serial advances. The transfer authenticates. A newly listed address belongs to an ISP that also hosts a business partner. The vendor's entry matches, but the enterprise's local PASSTHRU exception is placed after the external feed. The partner disappears behind synthetic NXDOMAIN.

Nothing in that sequence requires a corrupted packet or an impostor. The failure is an ordering decision. “The feed was valid” describes custody of a policy object. “The answer was authorized” is a different claim, made by the subscriber when its resolver promoted that object into the path of its users.

Response Policy Zones make this boundary unusually visible. The current BIND 9 documentation describes RPZ as an open, vendor-neutral zone format for DNS firewall rules. A producer can encode a set of triggers and actions, distribute it with ordinary zone-transfer machinery, and update subscribers quickly. BIND, Unbound and PowerDNS Recursor all implement the model.

The formal history needs equal precision. The 2018 DNS RPZ document is an expired individual Internet-Draft, not an RFC and not an endorsed IETF standard. Its Datatracker history records that it went dormant in July 2020. It remains useful evidence for the common format and its producer/subscriber design, but its status must not be inflated.

That draft states the decisive mechanism plainly. Transfer publishes policy data to subscribers; the subscriber's configuration promotes RPZ payload into the control plane of its own recursive name server. The producer supplies an object. The resolver operator makes it effective.

Five trigger families show how much discretion sits inside that promotion. A rule may match the client's IP address, the query name, an address that would appear in the answer, the name of an authoritative server, or that server's IP address. These checks occur at different stages of resolution. A QNAME rule can act before the resolver knows the final address. An RPZ-IP rule needs the would-be answer. NSDNAME and NSIP rules can reach many otherwise unrelated domains because hosting providers share authoritative infrastructure.

Six action families produce six different operational claims. NXDOMAIN says the name does not exist. NODATA says the name exists but the requested record type does not. DROP sends nothing. TCP-only truncates UDP and makes the client retry over TCP. Local data may redirect the name to a warning site or another destination. PASSTHRU exempts a match from rewriting under the implementation's precedence rules. Calling all of these “block” conceals their different effects on applications, caches, diagnostics and users.

Order turns those differences into authority. BIND's current configuration reference says that when several rules trigger, the zone listed first wins before BIND compares trigger type and specificity inside that zone. Unbound also consults zones in configured order; in its model PASSTHRU is itself a match, so an early exception prevents later feeds from acting. BIND's practical guidance advises exactly that arrangement: keep an internally owned RPZ first, then use PASSTHRU records to protect important partners from future entries in external zones.

PowerDNS documents an additional caution. Its evaluation order has changed by version, and its current behavior makes performance and privacy trade-offs about when to test client, QNAME, name-server and response-address triggers. A feed is therefore not a portable transcript of one inevitable result. The same records can encounter different stage and precedence behavior in different resolvers.

Local action overrides make the delegation still clearer. BIND can replace every action in one policy zone with NXDOMAIN, NODATA, DROP, TCP-only, PASSTHRU or a local CNAME. Unbound can make an external list of triggers point every match to the subscriber's own destination. PowerDNS can impose Custom, Drop, NXDOMAIN, NODATA, Truncate or NoAction as the default. Once the subscriber changes the action, it cannot plausibly describe the client result as something the feed merely “said.”

Test modes are also local. BIND's DISABLED override can log what a zone would have done without applying its action. Unbound distinguishes disabled from PASSTHRU: disabled is not a valid match and permits the next zone to be considered, while PASSTHRU terminates policy evaluation. This is not a semantic footnote. A staging configuration copied between products can expose users to a later feed when the operator expected an exemption.

The DNSSEC boundary prevents the rewritten answer from borrowing authority it does not have. The RPZ draft describes policy-induced results as deliberately untruthful answers from a recursive server. That wording is technical, not moral: the result differs from the authoritative data by design. By default, BIND avoids applying RPZ where requested DNSSEC records are present. With break-dnssec yes, it rewrites anyway and notes that the result cannot verify.

RFC 4035 supplies the underlying validation rule. A validating resolver treats data that should authenticate but cannot as Bogus; the condition may reflect attack, configuration failure or corruption. It also warns that answers from a recursive server depend heavily on that server's local policy. DNSSEC can authenticate the publisher's authoritative RRsets. It does not sign the subscriber's synthetic NXDOMAIN or walled-garden CNAME. TSIG on the feed transfer authenticates a different relationship again.

Persistence creates a second separation between decision and effect. RFC 2308 defines negative caching: NXDOMAIN and NODATA can be stored and reused until their TTL expires, under different cache keys. BIND derives a rewritten record's TTL from the policy and caps it with a locally configured maximum. PowerDNS exposes synthesized TTL, maximum TTL and current cache-invalidation controls. Removing an entry at the producer does not instantly remove every consequence. Feed refresh, resolver reload, packet cache and downstream negative cache are distinct clocks.

Diagnostics can make the authority chain more honest. RFC 8914 distinguishes an operator's internal security block (EDE 15), an externally imposed requirement (16), filtering requested by the client (17), and an unauthorized-client refusal (18). BIND and PowerDNS can attach EDE to policy hits. The label matters because “our security policy,” “a court required this,” and “you selected this filter” describe different decision owners.

EDE is not a warrant. RFC 8914 calls it diagnostic information that must not change DNS processing. It can be unauthenticated, omitted by an intermediary and hidden by an application. It can also leak that a name is listed. A useful operations record therefore connects the EDE to the feed serial, local policy name, winning trigger, chosen action and client class rather than treating the code as sufficient evidence.

Freshness is similarly divided. The expired draft urges producers to minimize latency not only when adding protection but when withdrawing erroneous or outdated policy. PowerDNS can dump the latest successful feed and use it as a seed during restart before fetching IXFR updates. BIND can be configured to return SERVFAIL until zones are ready, yet its reference notes that it can answer with the zones that did load if another zone failed. These are defensible tools only after the operator defines maximum feed age, partial-load behavior and rollback ownership.

This is the practical value of Heng Lu's distinction among running code, minimum shared specification and localized future decision, and reality layers. RPZ can keep the shared layer narrow: a common way to carry policy candidates. The local resolver remains the place where adoption becomes real, consequences are chosen and evidence must meet running effect.

The audit chain should therefore have seven links. Identify the publisher and feed version. Prove transfer custody. Record local admission or rejection. Preserve effective zone order and overrides. Log the winning trigger and action. Bound cache persistence and name the EDE decision source. Finally, probe the answer from each relevant client class and compare it with unfiltered authoritative resolution.

The phrase “we subscribe to this feed” is not an operating policy. It omits the choices that determine whether users see truth, silence, non-existence, a redirect or an exception. A valid feed deserves authenticated handling. It does not deserve delegated sovereignty over the answer.