Summary

  • Ray Bellis's RFC 5625 turns a simple DNS proxy's ignorance into a design constraint. Unknown flags, labels, query types, classes and resource records should pass; complete responses, EDNS options, truncation signals and TCP transport should survive; malformed input and active policy should fail visibly rather than masquerade as the future boundary of DNS.
  • The document became BCP 152 in 2009. It does not prove that current gateways comply, and transparent forwarding is not DNSSEC validation or a complete security policy. Its durable contribution is a division of authority: endpoints and specifications own meaning; the proxy owns bounded forwarding, client correlation, interface exposure and explicit local choices.

The reserved bit that did not stay reserved

Picture a broadband router built when a particular DNS header bit was required to be zero. Its parser takes that old rule seriously. Years later, a standards document assigns the bit a purpose. An updated client sends it. The recursive resolver understands it. The proxy between them still treats it as an error and silently discards the packet.

Nothing at either endpoint is wrong. The installed intermediary has converted the age of its firmware into a veto over protocol evolution.

This is the practical problem behind RFC 5625, DNS Proxy Implementation Guidelines. Published in August 2009 as Best Current Practice 152, the document is authored by Ray Bellis, then of Nominet UK. It does not ask a small gateway to implement every DNS feature. It asks the gateway not to confuse the limits of its implementation with the limits of the protocol.

That distinction sounds modest until the proxy sits on the default path for every device in a home or small office. DHCP commonly advertises the gateway as the DNS server. The gateway accepts a query on the LAN, sends a related request to a recursive resolver and returns the response. It now occupies a control point without necessarily possessing the parser, update cycle or operational visibility expected of a full resolver.

Bellis's answer is a deliberately thin role. A simple proxy should forward the request verbatim to a known upstream recursive resolver and return the complete response verbatim to the originating client. It still has work to do, but it should not acquire semantic authority merely by being in the path.

Historical evidence, not a present-day census

The concern was not hypothetical in 2009. The SAC035 executive summary and full report record controlled tests of 24 residential routers or small-office firewalls in July and August 2008.

All 24 devices could route DNSSEC queries directly to an upstream resolver. Twenty-two also offered DNS proxy mode. Six of those proxy implementations had difficulty with DNSSEC-related flags or validated responses. Eighteen limited UDP replies to 512 bytes or an MTU-related size; only four returned proxy responses as large as 4096 bytes, and only one proxied DNS over TCP. Six devices were fully compatible in their default configuration, while nine more could be configured to bypass the proxy incompatibility.

Those figures explain the urgency of the document. They do not describe today's installed base. The sample was small, the tests were conducted in 2008 and firmware, products and network practice have since changed. RFC 5625 is useful precisely because its logic does not require turning that historical test into a modern market claim. Protocol extensions will continue to encounter intermediaries that were built before the extensions existed.

The IETF approval write-up records strong DNS Extensions Working Group consensus and interest from vendors and purchasers. That is evidence about the standards process and the problem's relevance. It is not evidence that purchasers enforced the guidance or that deployed devices adopted it.

Unknown does not mean malformed

RFC 5625 draws its most important line between a value the proxy does not understand and a packet that cannot be valid.

An unknown DNS header flag should be ignored by the proxy and the packet forwarded. The same applies to label encodings and to QTYPE, QCLASS, resource-record TYPE and CLASS values. A parser designed around today's registry cannot be permitted to drop tomorrow's allocation. The endpoint that requested the data and the resolver that answers it are better placed to determine what the value means.

RFC 3597 supplies the more general extensibility rule. A server or resolver that encounters an unknown resource-record type must treat its RDATA as unstructured binary information, store it and transmit it unchanged. This is not an instruction to pretend to understand the record. It is a way to preserve the record until a component with the right semantics receives it.

Malformed input is different. An impossible section count or an invalid compression pointer is not a future extension merely because an old implementation fails to parse it. RFC 5625 allows such a message to be rejected. Its operational preference is still revealing: where safe, return SERVFAIL rather than discard the packet silently. The client can then stop retransmitting and the operator receives evidence of which layer refused the request.

There is also an explicit policy exception. A proxy implementing an active security or network policy may deliberately block or alter traffic. But a deliberate rule should remain attributable as policy. It must not emerge accidentally from an incomplete parser and then be described as protocol compliance.

Custody includes size and transport

DNS meaning is carried not only in names and record types but in how a response declares its completeness. A proxy that clips a UDP reply to 512 bytes without setting the TC flag creates a plausible-looking incomplete answer. A proxy that removes TC erases the server's instruction to retry over TCP.

RFC 5625 therefore says the proxy should not truncate merely because a UDP response exceeds 512 bytes. If it has an unavoidable local limit, it must set TC; it must never remove a TC indication received from upstream. The difference is epistemic as much as technical. The client can react to declared truncation. It cannot recover information whose absence has been disguised as success.

TCP is part of the same custody. A proxy must be ready to receive and forward DNS over TCP. If the client arrives over TCP, the upstream query should remain TCP rather than being downgraded to UDP for a speculative attempt that is already likely to truncate. RFC 7766, co-authored later by Bellis and four colleagues, made TCP support a requirement for DNS implementations. That later Standards Track document strengthens the transport boundary; it does not demonstrate compliance by every gateway.

EDNS makes the extension problem concrete. RFC 5625 says an OPT record must not cause a proxy to reject a query. RFC 6891 later states that a conforming middlebox must not impose the old 512-byte UDP ceiling and that a simple forwarder must not modify or delete OPT content in either direction. The 4096-byte capability recommended in the 2009 proxy document belongs to its implementation era, not to a timeless maximum.

Transparency still has an operating surface

A thin proxy is not a wire. It chooses or learns an upstream recursive resolver. It maps a returning answer to the right LAN client. It decides how long to retain that state, which interfaces accept queries and what resolver address DHCP advertises. It may change the outbound Query ID for client correlation.

Those choices are real authority and need their own controls. RFC 5625 points to the forgery-resistance measures in RFC 5452, including randomized query identifiers and source ports. Randomization reduces a class of spoofing exposure; it does not authenticate an answer or replace DNSSEC.

Packet integrity narrows the room for helpful rewriting. In a TSIG-signed exchange, modifying authenticated DNS content causes verification to fail, apart from the specifically permitted treatment of the query identifier. A proxy must either preserve the message or correctly implement the full authentication behavior. Partial interpretation is not assistance. It is observable corruption.

Interface scope matters too. A gateway proxy intended for LAN clients should not listen by default on its WAN side. An exposed proxy can contribute to reflection attacks, the risk described in RFC 5358. Transparency toward a legitimate client does not require indiscriminate availability to the Internet.

Finally, bypass is part of the boundary. Except where an explicit policy says otherwise, users should be able to direct queries to named upstream resolvers rather than being forced through the proxy. A convenience service becomes a semantic choke point when the network captures every attempt to exit it while offering no proof that it preserves unfamiliar features.

Bellis's rule for an intermediary that will age

The IETF Datatracker profile lists ten RFCs for Ray Bellis, including RFC 5625. The ISC team page identifies him today as Director of DNS Operations. That career context is relevant because the document reads less like a catalogue of DNS features than an allocation of operational responsibility.

Its test is not whether the proxy knows enough. The test is what happens when it does not know. Does an unfamiliar flag pass? Does an unknown resource record survive intact? Does the client see TC, receive SERVFAIL, retain TCP and keep the OPT data that an endpoint understands? Can an operator distinguish an explicit policy decision from firmware ignorance?

RFC 8906, later co-authored by Mark Andrews and Bellis, turns many of these cases into explicit DNS resolver test vectors: unexpected fields, record types, EDNS versions, options and flags, truncation and TCP. The later document does not make silence a new problem. It makes the old problem measurable.

RFC 5625 never claims that transparency supplies validation, privacy or availability. Nor does it deny the operator's right to set upstreams, secure interfaces or enforce a declared policy. It does something narrower and more durable. It prevents an intermediary from silently treating ignorance as jurisdiction.

The proxy can own forwarding state. It can own its exposure and its local policy. It cannot own the future meaning of every bit it happens to carry.

Sources