Summary
As of November 15th, 2018 our DNS resolvers (both staging and production) advertise an EDNS reassembly buffer size of 512 bytes. This change should not require any adjustment by subscribers.
Background
Previously we shared our initial thoughts on a potential mitigation to help defend against DNS fragmentation attacks. By reducing the maximum size of responses we’re willing to accept over UDP, we reduce the likelihood of receiving an IP-fragmented response, which increases resistance to DNS spoofing attacks.
In practical terms, we set edns-buffer-size: 512 in our Unbound configuration.
When we proposed this mitigation we identified two potential downsides:
-
Authoritative resolvers that return large responses but don’t support TCP would stop working.
-
An increase in the frequency of TCP fallback would use more resources on the recursive resolver.
We found that the number of authoritative nameservers that truncate responses but don’t support TCP fallback is tiny. To reach this conclusion we ran a series of experiments comparing A, AAAA, and TXT lookups for ~44 million fully qualified domain names using a recursive resolver with an edns-buffer-size setting of 4096 bytes, and a recursive resolver with an edns-buffer-size setting of 512 bytes. We found only differences that could be explained by a baseline of flaky nameservers (intermittent timeouts, 0x20 case randomization intolerance, etc).
The experiment results also confirmed that setting a small EDNS requester payload size effectively stopped authoritative resolvers from sending fragmented replies. In one run of the experiment performing A/AAAA queries we found that changing our EDNS buffer size reduced the number of fragmented response packets from over 975,000 to 8. All 8 were from a single misconfigured authoritative nameserver.
Overall, the difference in system load on our recursive resolvers from the increase in TCP fallback was not a problem. We slowly rolled the mitigation out to our staging environment beginning Oct. 29th and monitored the impact carefully to assure a successful production implementation.
This mitigation alone is not sufficient to address the threat of BGP hijacking but we believe it is a strong countermeasure against off-path DNS spoofing attacks. We continue to work on multiple perspective domain-validation and to pursue other avenues of defense.
Thanks!