Part one of this story ended with an honest caveat: the rate limiter still answers five oversized responses per second per query name, and each of those was a full-size answer. The two layers that close that gap are now in production - and verifying one of them uncovered a bug that had nothing to do with the attack.
The EDNS clamp. Whatever buffer size a client advertises, the public edge now truncates UDP answers at 1,232 bytes and echoes the same limit back in the response OPT. Measured live, the attack's favourite query dropped from a 2,257-byte answer honouring udp: 10000 to 1,186 bytes with TC=1 - real clients retry over TCP, spoofed sources cannot complete a handshake. The residual amplification on the rate limiter's answered budget fell from 31.8x to roughly 16.7x. The instructive part: our backend resolver had been Flag-Day-clamped for years, and it made no difference. The proxy in front of it retried truncated answers over loopback TCP and re-served them at full size over public UDP. A limit on a hop the attacker cannot reach is not a limit.
The 4 KB bug. Testing the truncation promise with a genuinely large answer - cisco.com TXT, 6,816 bytes over TCP - returned SERVFAIL instead. The cause was a silent legacy limit in dnscrypt-proxy's TCP path: a 4,096-byte constant sized for UDP was also capping TCP responses, which are legal to 65,535 bytes. Every answer over 4 KB had been failing for years, looking like an occasional upstream error. Fixed in our fork; large answers now arrive intact.
DNS Cookies, as relief. RFC 7873/9018 cookies run at the edge as relief, not as a gate: a client that returns a valid server cookie has proven its address is real and is exempted from rate limiting. Clients that send no cookie lose nothing - old stubs are never punished. The flood stays identifiable by the absent cookie regardless of which query name it moves to next.
The full account - the clamp, the tcpdump that caught the 4 KB failure, the fix, and the cookie rollout: When UDP Clamping Exposes a TCP Bug.