Summary

  • The IETF Datatracker listed ten RFCs for Ray Bellis on 5 August 2026, including the newly published RFC 10029 on DNS Multiple QTYPEs. It showed no active Internet-Drafts at that check. The index records work over time; it is not a claim of sole ownership or universal adoption. [1]
  • An earlier Bellis-authored DNS-over-TCP specification, RFC 5966, was later obsoleted by the five-author RFC 7766. The newer document made TCP a required part of a full general-purpose DNS implementation and treated it as a valid transport, not merely an emergency retry after UDP. [3] [4]
  • RFC 7828 and RFC 8490 addressed the state that comes with persistent DNS connections. They specified ways to signal idle time, manage sessions, communicate termination, and distinguish success, failure, timeout, and shutdown. [5] [6]
  • RFC 8906 described silence itself as an operational problem. A missing response can make packet loss, unsupported features, filtering, rate limiting, and broken server behavior look alike. It recommended explicit protocol responses in ordinary conditions and documented tests for failures. [7]
  • RFC 9619 preserved the practical rule that a normal DNS query has one primary question. RFC 10029 then added an Extension Mechanisms for DNS (EDNS) option, a standard way to add capabilities to ordinary DNS messages, for asking for related record types alongside that question, with explicit completion signaling, fallback to separate queries, and operator-configurable limits. [8] [9]

A small question passes through many independent systems

A DNS lookup begins with a name and a type of information. An application might ask for an IPv4 address, represented by an A record, or an IPv6 address, represented by an AAAA record. Modern connection setup may also need an HTTPS record, a service-discovery record, or data used to validate a signed answer.

The application commonly gives the question to a resolver supplied by the operating system. That resolver may send it to a recursive server. The recursive server follows delegations until it reaches servers that are authoritative for the relevant part of the name. Caches can answer some steps. Proxies, firewalls, load balancers, and network address translators can sit between entities.

No single standards author or institution operates this entire path. Device makers write implementations. Network operators choose capacity and filters. Domain operators maintain delegations and authoritative data. Resolver operators decide how to retry and when to give up. Applications decide how long a user will wait.

That division makes clear messages valuable. If an authoritative server says that a name does not exist, the resolver has an answer it can cache and explain. If a server says a request type is not implemented, the client can decide whether another method is useful. If a message is truncated, the client can retry over a transport that carries a larger response.

Silence is different. It carries no reason. The client can wait, retry the same path, switch transport, remove an extension, ask another server, or return an error to the application. Each choice consumes time or changes the request. A workaround that helps with one broken server can conceal a different problem elsewhere.

The public work associated with Ray Bellis repeatedly approaches this boundary. The documents do not try to centralize DNS operations. They describe what a entity should send, accept, reject, time out, or retry so independent systems can make failures less ambiguous.

DNS over TCP moved from exception handling to ordinary capability

Many people learn a simplified rule: DNS uses UDP, and TCP is for unusually large answers or zone transfers. That description reflects common history but can turn an essential capability into an optional afterthought.

UDP has advantages. A server can answer a small request without maintaining a connection. A simple exchange can complete quickly. The cost appears when a response is too large, when fragmentation is unreliable, or when source-address spoofing enables reflection and amplification. DNSSEC and IPv6 contributed to larger responses, while privacy transports added reasons to revisit connection-oriented DNS. [4]

RFC 5966, published in 2010 with Bellis as its named author, set implementation requirements for DNS over TCP. [3] It did not remain the last word. In 2016, RFC 7766, written by John Dickinson, Sara Dickinson, Ray Bellis, Allison Mankin, and Duane Wessels, obsoleted it. [4]

That succession matters for two reasons. First, it shows that a standards contribution can be useful and still be replaced. A later group can preserve the problem, incorporate operational experience, and change the normative text. Obsolescence in this case is not evidence that the earlier author failed. It is evidence that readers must follow the document chain rather than stop at a familiar number.

Second, RFC 7766 made the operational boundary clearer. It required general-purpose DNS implementations to support both UDP and TCP. It allowed resolvers to choose TCP for local operational reasons rather than only after a UDP attempt. If a suitable TCP connection is already open, the document recommended reuse. [4]

For a non-specialist, the practical point is straightforward. A DNS server that answers small UDP questions but cannot handle TCP is not fully interoperable under the newer requirement. A firewall that silently drops TCP port 53 can create resolution failures or long application timeouts. The user sees a name that “does not work,” even though the name, address, and authoritative data may all be correct.

The RFC does not prove that every implementation meets the requirement. It provides a public behavior against which an operator can test. Send queries over both transports. Observe whether connections establish, whether responses return on the same connection, whether large answers survive, and whether timeouts reflect explicit resource policy or accidental filtering.

A proxy can preserve a packet while changing its meaning

DNS proxies are common in gateways and local networks. A client may believe it is speaking to a resolver at a nearby address, while the proxy forwards the question elsewhere. This can be convenient, but it adds another implementation that must understand message size, transport, flags, extensions, response codes, and fallback.

RFC 5625, published in 2009 with Bellis as the named author, records implementation guidance for DNS proxies. [2] Its presence in the standards record is useful to this article not because every proxy follows it, but because proxies make the distinction between an original message and a delivered message operationally important.

A proxy can forward an ordinary A query and appear correct during simple testing. Problems may emerge only with a larger signed response, an unknown type, an EDNS option, or TCP. If the proxy removes information it does not understand, substitutes silence for a valid error, or supports UDP but not the required TCP path, a client can misdiagnose the authoritative server.

This is a recurring Internet infrastructure problem. Each intermediate system may have a local reason for filtering or rewriting traffic. Yet the end-to-end result is measured by whether the original entity receives a response it can interpret. A configuration screen that says “DNS proxy enabled” does not prove the behavior of that path.

Operators therefore need tests that vary more than the domain name. They can ask known and unknown record types, use ordinary and extended DNS, compare UDP with TCP, request a response large enough to exercise truncation, and inspect whether error codes survive. The goal is not to force every device to implement every new feature immediately. It is to distinguish an unsupported feature from a device that disappears the evidence.

Bellis's documented role here is bounded. RFC 5625 is an authored public record. Manufacturers and operators decide whether to implement and test it. The source does not provide an adoption count, a list of compliant products, or a measured reduction in failures.

Keeping a TCP connection open creates a resource decision

Making TCP a normal DNS transport solves some problems and creates operating choices. A server must remember connection state. It must allocate memory, sockets, queues, and processing time. A client needs to know whether a quiet connection can be reused or is about to be closed.

Opening a new connection for every question can add delay and work. Keeping every connection open indefinitely can exhaust a busy server. A fixed timeout chosen by one side may be too short for a client and too long during a resource shortage.

RFC 7828, co-authored by Paul Wouters, Joe Abley, Sara Dickinson, and Ray Bellis, defined the edns-tcp-keepalive option. [5] It lets a server signal the idle timeout associated with a TCP session. A client can express interest in keeping the connection open. The server can return a value based on its local resource constraints, including zero when it wants clients to finish outstanding work and close.

The option is a good example of coordination without surrendering local control. The standard defines the field and its interpretation. It does not require every server to keep every connection for the same duration. The server remains responsible for capacity. The client remains responsible for honoring the signal and deciding what to do next.

The document also records complications. Long-lived sessions can be disrupted when routing changes the destination reached through an anycast address. Middleboxes may interfere with EDNS options or messages above particular sizes. Clients need fallback behavior for paths that do not carry the option cleanly. [5]

None of those cautions makes persistent connections useless. They show why a timeout must be observable and why the operator needs more than a connection count. Useful measurements include reuse rate, connection setup time, idle closure reason, outstanding requests at closure, failed fallback, and differences among anycast sites.

A standards field cannot allocate memory or repair a firewall. It can make the resource decision visible enough for both ends to react. That is a smaller claim than “TCP makes DNS reliable,” and a more useful one.

Stateful DNS required states that both ends could name

Keepalive signaling addressed one part of a larger question. If a DNS connection persists, how do the endpoints manage session-level operations that are not ordinary name queries?

RFC 8490, co-authored by Bellis and five others, defined DNS Stateful Operations, or DSO. [6] It created a DNS operation code and message structure for session functions. The initial operations cover keepalive, retry delay, and encryption padding. It also allowed server-initiated messages in a persistent session.

The document distinguishes connection establishment from DSO session establishment. A connection can exist before a DSO session is active. A session request can succeed, fail with a response code, or time out. Once established, both ends can send DSO messages. Either end can shut down, and a server can communicate a retry delay. [6]

This state model matters because “the TCP socket is open” is not the same as “both parties agreed that a DSO session exists.” Treating the two as identical would hide an incomplete handshake. Similarly, waiting without limit for a DSO response would leave the client in an indeterminate state.

RFC 8490 addresses that uncertainty with defined transitions and failure behavior. A timeout during session establishment leads the client to abort the connection; depending on circumstances, it may reconnect without DSO. A nonzero response code identifies an unsuccessful attempt while allowing ordinary DNS operation to continue in the connected but sessionless state. [6]

The mechanism does not eliminate all ambiguity. A lost connection still needs diagnosis. A middlebox can still disrupt traffic. Server capacity can still change. The document also does not prove that DSO is widely deployed.

What it contributes is a public record of state. The client can say whether it was merely connected, attempting a session, established, rejected, timed out, or shutting down. Those labels can appear in logs and tests. When a later team investigates, it has more than “DNS failed.”

Silence makes different failures look identical

RFC 8906 gives the article's central problem its clearest form. Written by Mark Andrews and Ray Bellis, it describes an operational pattern in which DNS servers fail to respond to well-formed queries. [7]

A missing answer can have several causes. The packet may have been lost. A server may not understand an EDNS option. A firewall may drop the message. A server under attack may rate-limit responses. A broken implementation may ignore an unknown type or flag. From the client side, these different conditions can look like the same empty wait.

The distinction matters because fallback changes behavior. If a resolver assumes that silence means EDNS is unsupported, it may retry without EDNS. That can interfere with DNSSEC validation or prevent newer features from working. If it assumes packet loss, it may repeat the same request and spend more of the application's time budget. If it immediately switches servers, it may conceal a persistent fault at an authoritative endpoint.

RFC 8906 argues for explicit responses in ordinary conditions. A server receiving an unknown data type can return the response appropriate to a recognized type for which it has no data. An unknown operation code has a defined “not implemented” response. A server should answer over TCP, while a firewall that refuses TCP should terminate cleanly instead of silently discarding the connection attempt. [7]

The document recognizes an exception: a nameserver under attack may need to drop packets or limit responses. That operational authority remains local. The problem is that widespread unexplained silence prevents legitimate clients from distinguishing attack controls from broken behavior.

The RFC also connects response behavior to delegation maintenance. It advises parent-zone operators to check that the name-server (NS) records used for delegation—the records that identify the servers responsible for a zone—agree with those at the delegated zone. [7] A server that receives a query for a zone it is supposed to serve should not simply disappear. An explicit answer and consistent delegation give the resolver evidence about where responsibility lies.

This is not a promise that every query deserves unlimited resources. It is a design preference for usable failure information. A negative answer, an error code, a reset, or a retry signal can be processed. Silence transfers the cost of guessing to every client.

An error response protects the client's retry budget

An application does not wait for DNS forever. A browser, mail server, monitoring agent, or software updater has a limited amount of time before it reports failure or moves to another task. The resolver spends part of that allowance on each transmission, connection attempt, alternate server, and fallback.

Consider a resolver that sends an EDNS query and receives nothing. It cannot know whether the request was lost, the server ignored all EDNS messages, one unfamiliar option caused trouble, the network filtered the packet, or a rate limiter discarded it. It may repeat the EDNS query, try ordinary DNS, switch authoritative servers, and then try TCP. Each branch can be reasonable, but the combination can consume the user's time without identifying the fault.

An explicit response shortens the decision tree. A format error identifies a problem with the request format. “Not implemented” identifies an operation the server does not support. A normal negative answer says the server understood the question but has no matching data. A clean TCP refusal shows that the connection path was reached even if service was unavailable. These outcomes are not all successful answers, yet each carries more operational value than silence.

RFC 8906 makes this distinction central. It documents how non-response encourages resolvers to remove EDNS and how that fallback can interfere with DNSSEC or newer features. It also gives operators a sequence for testing: establish that ordinary DNS works, vary the extended request, and then repeat the original request to distinguish persistent failure from ordinary packet loss. [7]

The same logic appears in DSO. A nonzero response code tells the client that session establishment failed. A timeout indicates that the state is indeterminate and leads to connection abort. Those are different conditions and should remain different in logs. [6] Treating both as a generic disconnected event would discard the protocol's evidence.

RFC 10029 continues the pattern. A response option says which requested types were completely processed. A missing type does not force the client to guess whether its answer is hiding somewhere in the message. The client sends a standalone query for what remains. If the extension is unsupported, the primary answer can still be used before fallback. [9]

This does not mean every client should retry every branch. Repeated attempts add traffic and may worsen an overload or attack. The operating decision is to define a retry budget: which explicit results allow another method, how many servers to try, how long to wait, and when to return an error to the application.

A useful record therefore includes more than elapsed time. It names the transport, server, question type, extension, response code, truncation flag, connection result, retry reason, fallback method, and final outcome. Privacy and data-retention limits still apply, so operators need not retain full user queries to count protocol states. Aggregate measurements can show where the budget is being spent.

The benefit reaches beyond troubleshooting. When a new feature is introduced, explicit unsupported responses allow controlled fallback while deployment grows. If unsupported servers simply disappear, clients must retain broad heuristics indefinitely. Those heuristics can make old behavior difficult to remove because the final request often succeeds after several hidden attempts.

Bellis and the other named authors do not set the retry budget for every resolver. Their documents define response and state information that local software can use. The operator still decides capacity, delay, privacy, and risk. The standards contribution is to make more branches distinguishable before that decision is made.

One question became the base for asking for several kinds of data

DNS messages have count fields, including QDCOUNT for the number of questions. The original wire format appeared to allow more than one question, but implementations did not develop dependable shared behavior for multi-question queries.

RFC 9619, written by Ray Bellis and Joe Abley and published in 2024, clarified that a normal DNS query generally carries one question. [8] That rule narrowed ambiguity, but applications often need related types for the same name. A client preparing a connection might want A, AAAA, and HTTPS data. Sending separate questions costs additional exchanges and work.

RFC 10029, authored by Bellis and published as a Proposed Standard in July 2026, addressed that use case without returning to an unreliable multi-question interpretation. [9] It keeps one primary question and uses an EDNS option to list additional record types that the client wants alongside it.

The response has its own option. A conforming server returns that option for a valid request even when the overall response is truncated. The option lists the additional types that were processed completely. If an answer has a response-code or flag mismatch, or does not fit, the server leaves that type out rather than implying complete success. [9]

The client then has an explicit fallback. If the server does not support the option, returns a format error, or omits a type that is still needed, the client sends standalone queries for the remaining types. The extension can reduce exchanges when it works, but it preserves the older path.

The RFC also names a cost. Asking for additional types can increase server work and the amplification potential of DNS responses. It therefore calls for configurable limits, with the suitable value depending on the operating environment. [9]

The pattern resembles the earlier transport and session work. A new capability is useful only when support, completion, resource limits, and fallback are visible. The standard defines the exchange. Operators and implementers decide whether to enable it, how to limit it, and how to measure the result.

The standards record shows replacement and handoff, not a single finished design

The IETF profile for Bellis listed ten RFCs and no active Internet-Drafts on 5 August 2026. [1] That snapshot should not be treated as a complete biography. It is a record of documents associated with a person at a point in time.

Within that record, authorship changes shape. RFC 5625 and RFC 5966 name Bellis as author. RFC 7766, RFC 7828, RFC 8490, RFC 8906, and RFC 9619 are collaborative. RFC 10029 again names Bellis as author while documenting working-group consensus. [2] [3] [4] [5] [6] [7] [8] [9]

The replacement of RFC 5966 by RFC 7766 is especially useful. The earlier text remains discoverable, but implementers are directed to the newer specification. The later document adds authors and incorporates more operating experience. Bellis appears on both, yet the standard is not presented as his private property.

RFC 8490 updated the DNS-over-TCP work with stateful operations. RFC 10029 depends on the one-question clarification in RFC 9619. Documents refer to one another, constrain one another, and sometimes replace one another. That chain allows responsibility to move without erasing earlier work.

Credit should follow the records. Bellis can be described as a documented author or co-author. The documents also belong to working groups, reviewer communities, implementers, and operators who test them. No source reviewed here supports claims about his private intentions, leadership style, current employer, or individual control over deployment.

The durable entity is therefore not a personal legend. It is a sequence of public specifications that another engineer can retrieve, compare, implement, reject, update, and test against running systems.

The unresolved work is at the boundary between protocol and operation

Publishing an RFC does not make old middleware disappear. A proxy can still mishandle extended messages. A firewall can still block TCP. A server can still run out of connection capacity. An anycast route change can still move a persistent connection toward a different site. A resolver can still spend too much time guessing after silence.

Newer mechanisms add their own questions. DSO creates session state that must be monitored and protected. Multiple QTYPE requests can reduce separate exchanges but increase work and possible amplification. Limits that protect one server may reduce the feature's benefit for a client. Fallback preserves interoperability but can hide low support if operators measure only final success.

These are not reasons to reject the standards. They are reasons to separate specification from outcome. A requirement is a test target. A response code is evidence. A timeout is a state transition. A fallback is a visible branch. None guarantees that a particular service is fast or available.

Bellis's documented work offers a consistent operating lesson within those limits. DNS evolves more safely when entities communicate what they understood, what they completed, what they rejected, and what the other side should try next. That makes a distributed system more observable without creating a central operator.

The question left for implementers and network teams is measurable: as DNS adds transports, persistent sessions, extensions, and combined requests, do their running systems preserve enough explicit behavior that a failure can be classified before the application gives up? The RFCs cannot answer for every network. They make it possible to ask with precision.

Sources

  1. IETF Datatracker, profile for Ray Bellis.
  2. RFC Editor, RFC 5625: DNS Proxy Implementation Guidelines.
  3. RFC Editor, RFC 5966: DNS Transport over TCP — Implementation Requirements.
  4. RFC Editor, RFC 7766: DNS Transport over TCP — Implementation Requirements.
  5. RFC Editor, RFC 7828: The edns-tcp-keepalive EDNS0 Option.
  6. RFC Editor, RFC 8490: DNS Stateful Operations.
  7. RFC Editor, RFC 8906: A Common Operational Problem in DNS Servers: Failure to Communicate.
  8. IETF Datatracker, RFC 9619: In the DNS, QDCOUNT Is (Usually) One.
  9. IETF Datatracker, RFC 10029: DNS Multiple QTYPEs.