DNS cache poisoning - am I safe if I limit recursion to trusted local networks?

[raf]

On Thu, Dec 30, 2021 at 09:07:54AM +0100, Danilo Godec via bind-users <bind-users at lists.isc.org> wrote:

> On 29. 12. 21 19:24, tale wrote:
> > On Wed, Dec 29, 2021 at 5:31 AM Danilo Godec via bind-users
> > <bind-users at lists.isc.org> wrote:
> > > I have an authoritative DNS server for a domain, but I was also going to
> > > use the same server as a recursive DNS for my internal network, limiting
> > > recursion by the IP. Apparently, this is a bad idea that can lead to
> > > cache poisoning...
> > In short, no, this configuration with a BIND 9 server does not
> > increase your risk of cache poisoning any more than running your local
> > server in pure recursive mode.  I'm curious to hear more from the
> > source that has given you this impression.  I suspect there were some
> > additional qualifications that don't align with what you've described.
> > 
> The source is a security audit report, claiming that using a single server
> for both authoritative (for public use) and recursive (limited to internal
> clients by means of 'allow-recursion' directive) roles increases the risk of
> DoS attacks and DNS cache poisoning... They mentioned CVE-2021-20322 that
> supposedly makes cache poisoning feasible (again) - that made them increase
> the concern level to a 'medium'.
> 
> While I understand how and why DoS and cache poisoning are bad, I don't
> understand how separating these two roles would help mitigate the risk.
> 
> Thanks for helping me understand,
> 
>       Danilo

This site might explain it: https://www.saddns.net/

If it doesn't, perhaps you could ask the vendor of the
system that produced the security audit report to explain
their rationale. The only theory I can think of is that
separating the functions makes it more likely that the
resolving server would reside on a non-publically accessible
network, but it should still be possible to inject ICMP
packets directed at it by an attacker that can observe
its outgoing query packets. But that's an on-path attacker,
not an off-path attacker, so it would count as an improvement.
But even if the above isn't nonsense, it's not the separation
of functions that improves the situation, it's the location
of the resolving server. So it's probably a dumb theory.

But the main thing is that the Linux kernel has been patched,
so it shouldn't be a problem after your next security update.

Until then, you could block outgoing ICMP if doing so doesn't
cause more problems than it solves.

cheers,
raf