On Fri, Jul 18, 2025 at 9:02 AM Marc Binderberger via NANOG <nanog@lists.nanog.org> wrote:
are we talking about BCP-140, aka RFC5358 ("Preventing Use of Recursive Nameservers in Reflector Attacks") ? Well, it's both, a BCP and RFC - which statement above wins? ... ;-)
Some RFCs are proposed standards, and some are just publication of Informational documents and merely suggested Best Current Practices to aid in implementation of the standards. The language at the header of the BCPs always say the request discussion and suggestions for improvements. Their publication doesn't mean the recommendations are perfect.
Joking aside, I don't see why this BCP would not be relevant today. If you run an open recursive DNS in the Internet, this still seems to me a valid
The BCP-140 is perfectly valid, and a good implementor should still take the issues discussed into consideration before developing DNS software and when planning the implementation of DNS services. The recommendations don't necessarily apply to every implementation; the SHOULDs might be infeasible, or not necessarily the best option, or an option. It is Not necessarily the case that you want to actually follow every recommendation. You can consider scenarios and problems discussed in the BCP; make some determinations about whether they apply, and the risks your implementation poses, then design and build other solutions. For example, You can likely detect a possible attempted amplification attack from a remote recursor by maintaining per IP address byte rate counters for each querier and the response size against your recursor network. Force TCP-only to an IP or cap UDP response sizes and throttle UDP packets for a period of time after a certain query volume has been exceeded. You might also drop the first DNS request packet, and look for possible query retry request packets to fingerprint. Ampther type of alternate solution for a Public DNS provider whose DNS service is inherently external. You can also begin to deprecate direct UDP DNS access in general in favor of DoH/DoT. You can also through Anycast publication of your numerous public DNS instances Identify _which_ of your DNS sites a specified query source IP address should actually reach based on internet topology and historic legitimate query data assuming the source IP address is not spoofed for amplification purposes, and implement a protocol where the DNS queries are ignored and discarded If received by the incorrect site until you see a TCP exchange proofing a legitimate query from that source, instead of the correct region Anycast site peered with the provider of that source IP address. -- -JA