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

[raf]

On Fri, Dec 31, 2021 at 10:45:12AM +1100, raf <bind at raf.org> wrote:

> 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

I've just watched the two videos referred to on that
site, and I think what I said above refers mostly to
the original SADDNS (CVE-2020-25705), not the new
variant (CVE-2021-20322).

But I think the second video might answer your question:

  https://dl.acm.org/action/downloadSupplement?doi=10.1145%2F3460120.3486219&file=CCS21-fp236ab.mp4

It does make a distinction between "public-facing" and
"private-facing" port scans, but they seem to just be
terms used for referring to the difference between
un-"connect()"ed and "connect()"ed UDP sockets, and how
the kernel handles them.

It's complicated. The attacks are different in each
case, and the attack for the "private-facing" (i.e.
"connect()"-ed sockets) is much more complicated, but
still possible.

So it didn't help me understand how separating
functions in the name server would matter. I think
asking your security vulnerability scanner vendor for
an explanation is probably a good idea.

cheers,
raf