Summary

  • DNS Response Rate Limiting (RRL) reduces an authoritative server’s repeated, similar answers when forged UDP queries could turn it into a reflection amplifier.
  • Paul Vixie’s role was consequential but shared: ISC describes defensive sessions with him, while a BIND development record names both Vixie and Vernon Schryver on the patch.
  • RRL groups answer classes and client address ranges. That can suppress abusive volume, but the grouping is traffic policy—not authentication, attribution or proof of intent.

The answer can become the payload

In a DNS reflection attack, a query is made to an authoritative server with the victim’s address forged as the apparent source. The server’s reply then travels to the victim. If the answer is much larger than the query, the attacker has recruited the server to send more traffic than the attacker sent directly.

ISC’s 2014 presentation gives a concrete illustration: a 36-byte ANY query for isc.org could yield a 3,576-byte answer. That example explains the attraction of reflection; it is not a universal amplification ratio. The size depends on the query, the zone data, DNSSEC state, transport and response. The operational question is narrower: how much repeated answer traffic should one authoritative service continue to emit when requests look alike?

ISC says defensive strategy sessions at the company with Paul Vixie led to RRL. A BIND development ticket credits the BIND 9 patch to Vixie and Vernon Schryver. The public record supports Vixie’s central involvement, not a sole-inventor story. That distinction matters because RRL was a response to an operational problem assembled through organizational work, implementation and later tuning.

The Internet Hall of Fame profile places that episode within a broader DNS career. It says Vixie began maintaining BIND 4 at Digital Equipment Corporation in 1988, later became BIND 8’s primary author and technical architect, and founded MAPS, PAIX and the Internet Software Consortium. It also records his doctoral work at Keio University on DNS and DNSSEC. Those milestones show the range of his work; they do not change the shared credit for RRL, whose BIND patch record also names Schryver.

BIND 9.9.4 introduced RRL as an optional build feature. ISC’s “BIND 9.10 Significant Changes” page says RRL later became part of the default build configuration. These are statements about availability in BIND, not evidence that every authoritative operator enabled it or that every DNS product behaves the same way.

A bucket counts resemblance, not identity

The current BIND 9.20.29 manual describes token or credit buckets formed around similar responses and DNS clients. Responses consume credits; the configured rate restores them over a window. An operator can limit classes such as non-empty answers, NODATA, NXDOMAIN, referrals, errors or all UDP responses. Once a bucket is over its rate, BIND can drop or alter selected replies.

The word “client” hides a policy choice. BIND’s documented defaults aggregate IPv4 addresses by /24 and IPv6 by /56: addresses in each block count together for the relevant accounting. A resolver, company network, campus or access provider can place many unrelated users behind the same prefix. If one source drives a bucket over its limit, another user sharing that bucket may encounter a delayed, truncated or omitted answer.

That is not proof that prefix aggregation is wrong. A per-address limiter can be evaded by spreading queries over addresses, and a server must choose how to allocate scarce outbound capacity during a flood. The prefix, response class and rate are control settings with an availability cost. They should be treated as explicit operating policy, not as a neutral observation of who the client “really” is.

BIND’s documented slip behavior makes the trade-off visible. With the default slip=2, every second rate-limited request without a valid server cookie receives a smaller response: a client presenting a cookie can receive BADCOOKIE; otherwise BIND sets the truncation bit so the resolver can retry over TCP. Some errors cannot be truncated and pass at the slip rate. A setting of slip=1 sends truncated answers for all limited replies, favoring response integrity and client delivery over maximum reflection suppression; slip=0 drops all limited answers. The retry path is part of the defense, not an incidental detail.

The boundary is the operating role

ISC recommends RRL for authoritative servers. Its guidance warns that recursive use can create false positives and slow clients that repeatedly ask for the same names; open recursion should be closed rather than “protected” by leaning on RRL. The same feature can have a different cost when the service is answering public authoritative queries versus serving a population of end users.

BIND provides log-only to observe candidate limits before enforcement, with counters including RateDropped, QryDropped, RateSlipped and RespTruncated. Those counters are operational evidence about what the configured mechanism would or did do. They do not reveal an attacker’s identity. An observed source address may itself be forged, and RRL’s bucket membership is not an attribution system.

Heng Lu’s Note 65 supplies an editorial lens here: running behavior is the test of what an implementation actually controls. It contributes no historical evidence about Vixie or technical fact about RRL. For this feature, the relevant evidence is the deployed BIND version, configuration, bucket counters and client retry behavior—not simply the presence of an RRL directive in a document.

The supported conclusion is deliberately bounded. RRL can reduce an authoritative server’s contribution of repeated similar answers to reflection traffic. It can also pool legitimate users and trade delivery for suppression. It does not authenticate requests, establish motive, measure universal adoption or guarantee that a victim will see no reflected traffic. Vixie’s contribution is best understood as helping turn an operational defense into a configurable implementation whose limits operators can inspect.

Sources