Re: DNS cache poisoning - am I safe if I limit recursion to trusted local networks?
On 04/01/2022 21:12, Grant Taylor via bind-users wrote: Yep. This is where I have settled. But I don't feel I can defend it when asked. Hence my seeking to better understand. There are categories of bugs that specifically affect recursion, and in BIND these are _much_ more common than those that affect authoritative service. Adding auth service barely touches the attack surface. And with BIND's separation between authoritative and recursively cached trees there is (AFAIK) no risk of cache pollution affecting the authoritative data. Furthermore, having the auth data for your own zones present there actually ensures that your own zones' data: 1. will always be served in preference to cached data 2. will be fresher (i.e. not subject to TTLs) assuming that NOTIFYs and/or a short SOA refresh is in place 3. will be present if access to the authoritatives is lost for some period of time (/me waves at Facebook!) I really can't see any downside. Ray ___ 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
Re: DNS cache poisoning - am I safe if I limit recursion to trusted local networks?
On 1/4/22 4:37 AM, Ray Bellis wrote: Better yet, use BIND's mirror zones feature so that the zone is also DNSSEC validated. Completely agreed. I think the type of authoritative information is somewhat independent of the fact that any authoritative information exists. IMHO, the strictures against running authoritative and recursive on the same server seem to get mis-applied a lot of the time. I think it's perfectly fine for an *internal* recursive server to also hold authoritative copies of your own zones. Yep. This is where I have settled. But I don't feel I can defend it when asked. Hence my seeking to better understand. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ 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
Re: DNS cache poisoning - am I safe if I limit recursion to trusted local networks?
On 04/01/2022 03:52, Grant Taylor via bind-users wrote: If I'm allowing recursion and authoritative on the same server, I'd have the recursive + authoritative server do secondary zone transfers off of the internal MS-DNS / AD server. That way the clients can get the info off of the first server they talk to. To me, the secondary copy of the zone is a form of authoritative information on the otherwise recursive server. Better yet, use BIND's mirror zones feature so that the zone is also DNSSEC validated. IMHO, the strictures against running authoritative and recursive on the same server seem to get mis-applied a lot of the time. I think it's perfectly fine for an *internal* recursive server to also hold authoritative copies of your own zones. Ray ___ 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
Re: DNS cache poisoning - am I safe if I limit recursion to trusted local networks?
On 1/3/22 10:57 AM, John Thurston wrote: It must have a 'forward' zone defined on it for each of those stupid domains. And yes, you are right . . at that point it is no longer only performing recursion. ;-) But there is no other way to do it. Even in a combined recursive/authoritative design, your server would have no way to resolve names in those stupid domains; there must be an explicit 'forward' zone defined. If I'm allowing recursion and authoritative on the same server, I'd have the recursive + authoritative server do secondary zone transfers off of the internal MS-DNS / AD server. That way the clients can get the info off of the first server they talk to. To me, the secondary copy of the zone is a form of authoritative information on the otherwise recursive server. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ 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
Re: DNS cache poisoning - am I safe if I limit recursion to trusted local networks?
On 1/3/22 12:15 AM, Borja Marcos wrote: If you separate the roles it is much simpler to implement an effective access control. On 03.01.22 10:35, Grant Taylor via bind-users wrote: The problem I have with separating recursive and authoritative servers has to do with internal LANs and things like Microsoft Active Directory on non-globally-recognized domains. In short, how do you get a /purely/ /recursive/ server to know that internal-corp-lan.example (or any domain not in the global DNS hierarchy) is served by some other /purely/ /authoritative/ DNS server inside the company? you configure your recursive server with internal-corp-lan.example as type forward or static-stub pointing to your authoritative server. however, the "purely recursive" and "purely authoritative" split is not designed to cover domains like "internal-corp-lan.example" but "example.com" that has to be seen from the world clients. I feel like anything you do to the /purely/ /recursive/ DNS server to get it to know that it needs to route based on the DNS domain information slides away from the /purely/ /recursive/ role to somewhat /mixed/ /recursive/ & /authoritative/ role. This is to prevent recursive servers from providing domains to the public. in these cases I recommend setup purely authoritative servers for "example.com" to be accessible from the internet and "purely recursive" server accessible from your LAN, even if it would fetch "example.com" domain from your public authoritative servers. Just don't point NS record for "example.com" to this server as it's designes as internal recursive server. This niche role is the one nagging thing that I have that prevents me from supporting and proselytizing the role separation anywhere and everywhere. -- I've been looking for, but have not yet found, what I consider to be a good method that maintains strict separation of roles in this niche use case. Note: I'm completely on board with the separate roles for public / Internet facing servers. then, you should understand the need for separation of roles well. just the "recursive only" and "authoritative only" have a bit different meaning I tried to explain above. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. The 3 biggets disasters: Hiroshima 45, Tschernobyl 86, Windows 95 ___ 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
Re: DNS cache poisoning - am I safe if I limit recursion to trusted local networks?
On 1/3/2022 8:35 AM, Grant Taylor via bind-users wrote: In short, how do you get a /purely/ /recursive/ server to know that internal-corp-lan.example (or any domain not in the global DNS hierarchy) is served by some other /purely/ /authoritative/ DNS server inside the company? It must have a 'forward' zone defined on it for each of those stupid domains. And yes, you are right . . at that point it is no longer only performing recursion. But there is no other way to do it. Even in a combined recursive/authoritative design, your server would have no way to resolve names in those stupid domains; there must be an explicit 'forward' zone defined. -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska ___ 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
Re: DNS cache poisoning - am I safe if I limit recursion to trusted local networks?
On 1/3/22 12:15 AM, Borja Marcos wrote: If you separate the roles it is much simpler to implement an effective access control. The problem I have with separating recursive and authoritative servers has to do with internal LANs and things like Microsoft Active Directory on non-globally-recognized domains. In short, how do you get a /purely/ /recursive/ server to know that internal-corp-lan.example (or any domain not in the global DNS hierarchy) is served by some other /purely/ /authoritative/ DNS server inside the company? I feel like anything you do to the /purely/ /recursive/ DNS server to get it to know that it needs to route based on the DNS domain information slides away from the /purely/ /recursive/ role to somewhat /mixed/ /recursive/ & /authoritative/ role. This niche role is the one nagging thing that I have that prevents me from supporting and proselytizing the role separation anywhere and everywhere. -- I've been looking for, but have not yet found, what I consider to be a good method that maintains strict separation of roles in this niche use case. Note: I'm completely on board with the separate roles for public / Internet facing servers. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ 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
Re: DNS cache poisoning - am I safe if I limit recursion to trusted local networks?
> On 30 Dec 2021, at 09:07, Danilo Godec via bind-users > wrote: > > 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. Well, it’s certainly best practice to separate the roles. First and foremost: If you separate the roles it is much simpler to implement an effective access control. You can completely disable requests to a recursive DNS server using traffic filtering. If you implement both network filtering and BIND access lists an exploitation would require two mechanisms to fail/be buggy. Assuming that you are using dual role servers, imagine that a bug that allows cache poisoning by crafting requests in some way is discovered. If you are separating roles exploitation will be harder/less likely. Note that traffic filtering to a recursive DNS server is trickier than it seems. You also need to filter out spoofed requests at the network edge or it would be possible to use your own DNS server(s) to launch DoS attacks against your own users. Cheers, Borja. ___ 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
Re: DNS cache poisoning - am I safe if I limit recursion to trusted local networks?
On Fri, Dec 31, 2021 at 10:45:12AM +1100, raf wrote: > On Thu, Dec 30, 2021 at 09:07:54AM +0100, Danilo Godec via bind-users > wrote: > > > On 29. 12. 21 19:24, tale wrote: > > > On Wed, Dec 29, 2021 at 5:31 AM Danilo Godec via bind-users > > > 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=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
Re: DNS cache poisoning - am I safe if I limit recursion to trusted local networks?
On Thu, Dec 30, 2021 at 09:07:54AM +0100, Danilo Godec via bind-users wrote: > On 29. 12. 21 19:24, tale wrote: > > On Wed, Dec 29, 2021 at 5:31 AM Danilo Godec via bind-users > > 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 ___ 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
Re: DNS cache poisoning - am I safe if I limit recursion to trusted local networks?
Am 30.12.21 um 09:07 schrieb Danilo Godec via bind-users: On 29. 12. 21 19:24, tale wrote: On Wed, Dec 29, 2021 at 5:31 AM Danilo Godec via bind-users 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 it don't ___ 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
Re: DNS cache poisoning - am I safe if I limit recursion to trusted local networks?
On 29. 12. 21 19:24, tale wrote: On Wed, Dec 29, 2021 at 5:31 AM Danilo Godec via bind-users 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 ___ 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
Re: DNS cache poisoning - am I safe if I limit recursion to trusted local networks?
On Wed, Dec 29, 2021 at 5:31 AM Danilo Godec via bind-users 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. -- tale ___ 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
Re: DNS cache poisoning - am I safe if I limit recursion to trusted local networks?
Danilo Godec via bind-users 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... Sort of. It's complicated. Of course DNSSEC can prevent cache poisoning, but there is more to this particular question. In older DNS software (BIND 8 and before) there was not much separation between the recursive cache and authoritative data. It was possible for recursive clients to get data into the cache that could leak into authoritative responses, e.g. glue addresses, and addresses of CNAME or MX targets that pointed out-of-zone. This could lead to cache poisoning of other recursive servers, especially those that trusted additional data too much (before RFC 2181). BIND 9 keeps its authoritative and recursive data more separate. As a user you can see this in the ACL options, allow-recursion, allow-query-cache, etc. It is possible to configure BIND 9 so that remote clients see an authoritative-only view, and local clients have access to a recursive view, but it isn't entirely straightforward. Best practice is still to configure servers that appeaar in NS records to be authoritative-only. Tony. -- f.anthony.n.finchhttps://dotat.at/ Trafalgar: Variable 4 or less, but southerly 5 or 6 in northwest. Moderate or rough in southeast, rough or very rough in northwest. Fog patches. Moderate or good, occasionally very poor. ___ 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
DNS cache poisoning - am I safe if I limit recursion to trusted local networks?
Hello, 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... After watching a Computerphile Youtube video (https://www.youtube.com/watch?v=7MT1F0O3_Yw) on that topic I have a rough understanding of how cache poisoning works, but it doesn't explain why limiting recursion to 'trusted' IP networks doesn't help. Is it because with UDP IP's can be 'easily' spoofed and if someone guessed my internal network IPs and spoofed the IP, my DNS server would happily accept their requests? Or is it even wider than that? Danilo ___ 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
