It asynchronously sends out DNS queries to each configured nameserver
I believe that may be a mistake in some deployments. As is many hosts are poorly configured in terms of "search", "domain" and IPv4/IPv6 priority resulting in a 3x or greater amplification of invalid requests. Now send all those invalid requests to all upstream resolvers at the same time and a host could be IP rate limited depending on what resolver is being used at the edge of data-centers and how they are configured. Some SIEM may also detect this as an attack and would require some de-tuning to avoid false positives. Adding to this, sending valid requests to all the upstream resolvers at the same time mean that the outbound SNAT of data-centers will be seen as making many duplicate requests and that could also be detected as a small resource attack, especially if a company for whatever reason is not talking directly to the root servers and is instead using one of the corporate open resolvers such as Cloudflare or Google.
This is not theory. I bring this up as someone that has had to untangle many Dev, Staging and Prod environments where people coded applications to depend on search vs. FQDN and SIEM rules had to be muted until I could get developers to fix this. It can be a multi-month challenge and requires pulling many managers and directors into many meetings. People default to being dismissive until I show them the traffic being generated, graphs before and after. This includes application latency and amplification of server outages.
What worked best in the past to reduce the impact of all the poorly configured applications was to just run a local instance of Unbound on every node and it handled negative cache and TTL's to keep the load down on the edge and improve application latency. That bought time to fix the applications to use FQDN and to get IPv4/IPv6 priority fixed everywhere. Unbound also keeps track of which upstream resolvers are the fastest and which ones are not working.
Will this feature have a toggle or option in /etc/resolv.conf to disable the behavior for those that find they need it disabled?
Bender•3mo ago
I believe that may be a mistake in some deployments. As is many hosts are poorly configured in terms of "search", "domain" and IPv4/IPv6 priority resulting in a 3x or greater amplification of invalid requests. Now send all those invalid requests to all upstream resolvers at the same time and a host could be IP rate limited depending on what resolver is being used at the edge of data-centers and how they are configured. Some SIEM may also detect this as an attack and would require some de-tuning to avoid false positives. Adding to this, sending valid requests to all the upstream resolvers at the same time mean that the outbound SNAT of data-centers will be seen as making many duplicate requests and that could also be detected as a small resource attack, especially if a company for whatever reason is not talking directly to the root servers and is instead using one of the corporate open resolvers such as Cloudflare or Google.
This is not theory. I bring this up as someone that has had to untangle many Dev, Staging and Prod environments where people coded applications to depend on search vs. FQDN and SIEM rules had to be muted until I could get developers to fix this. It can be a multi-month challenge and requires pulling many managers and directors into many meetings. People default to being dismissive until I show them the traffic being generated, graphs before and after. This includes application latency and amplification of server outages.
What worked best in the past to reduce the impact of all the poorly configured applications was to just run a local instance of Unbound on every node and it handled negative cache and TTL's to keep the load down on the edge and improve application latency. That bought time to fix the applications to use FQDN and to get IPv4/IPv6 priority fixed everywhere. Unbound also keeps track of which upstream resolvers are the fastest and which ones are not working.
Will this feature have a toggle or option in /etc/resolv.conf to disable the behavior for those that find they need it disabled?