On Fri, Dec 31, 2021 at 10:45:12AM +1100, raf <b...@raf.org> wrote: > On Thu, Dec 30, 2021 at 09:07:54AM +0100, Danilo Godec via bind-users > <bind-users@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@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 _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
