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
Re: Possible cache poisoning
On 2010-10-26 00:39, The Doctor wrote: My question is how can you detect if a DSN / Domain name has been 'poisoned'? By using DNSSEC ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Possible cache poisoning
Zitat von The Doctor doc...@doctor.nl2k.ab.ca: My question is how can you detect if a DSN / Domain name has been 'poisoned'? Compare what your cache deliver with results from other sites. To prevent cache poison you might use DNSSEC if the zones which are affected support it and at least use a recent Resolver with ID/port randomization. Regards Andreas ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Possible cache poisoning
On 25.10.10 16:39, The Doctor wrote: My question is how can you detect if a DSN / Domain name has been 'poisoned'? quitye hard if it's already been done. You can see what it contains and compare it with what is should contain, but you never know if the incorrect data didn't come from misconfigured server. -- 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. I drive way too fast to worry about cholesterol. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Possible cache poisoning
If we talk about checking after suspected poisoning, my best idea is: dump the cache, then flush the cache and do the lookups again and compare to the cache-dump. Any difference is suspicious and should be looked closer upon. The cure is BTW also to flush the cache of the fake info. Remember that it is only the resolving server, that gets poisoned, the authoritative server does not ask questions and can not be poisoned with false replies. Remember to use best practises to avoid poisoning anyway. On 26/10/10 10:19, Matus UHLAR - fantomas wrote: On 25.10.10 16:39, The Doctor wrote: My question is how can you detect if a DSN / Domain name has been 'poisoned'? quitye hard if it's already been done. You can see what it contains and compare it with what is should contain, but you never know if the incorrect data didn't come from misconfigured server. -- Best regards Sten Carlsen No improvements come from shouting: MALE BOVINE MANURE!!! ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Possible cache poisoning
My question is how can you detect if a DSN / Domain name has been 'poisoned'? -- Member - Liberal International This is doc...@nl2k.ab.ca Ici doc...@nl2k.ab.ca God, Queen and country! Never Satan President Republic! Beware AntiChrist rising! http://twitter.com/rootnl2k http://www.facebook.com/dyadallee Are you a real human: http://www.cuttingedge.org/news/n1334.cfm ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Protecting bind from DNS cache poisoning!!!
Hi Thanks for your valuable suggestions Run an up-to-date version of bind. Be fanatical about applying security patches promptly. Yes , i am running the latest version Bind-9.7.1-P2. Don't allow recursion /at all/ for queries from the general public to your authoritative servers, nor permit authoritative servers to send additional data from cache. I am running separate caching and authoritative servers. As suggested by you, i had disabled recursion to for the authoritative servers. Permit only your trusted clients to make recursive queries through your recursive servers. Yes, in caching servers, i have only enabled recursion for our trusted clients. If you have sufficient DNS traffic to warrant it, it is very good to run completely separate instances of bind as authoritative and recursive servers -- use of virtualization techniques like FreeBSD jails can help reduce hardware costs. Yes, i am running separate instances of authoritative and recursive servers. Allow bind to use as wide a range of port numbers as possible for UDP traffic. Yes this is allowed in the firewall. Make sure your firewalls don't do daft things like forcing any DNS traffic to come from a limited range of source ports, or blocking large UDP packets or EDNS. Allow DNS queries over TCP as well as UDP. Yes in firewall , both TCP and UDP DNS queries are allowed. Implement DNSSEC. I tried implementing dnssec using the following document http://blog.dustintrammell.com/2008/08/01/configuring-dnssec-in-bind/ After modifying named.conf for recursive server, i restarted named. Now named is working with dnssec enabled .But i am not able to verify the same. Kindly let me know how can we verify that dnssec is enabled and running , from the logs. Thanks in advance. Shiva Raman ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Protecting bind from DNS cache poisoning!!!
Allow bind to use as wide a range of port numbers as possible for UDP traffic. On 09.08.10 17:14, Shiva Raman wrote: Yes this is allowed in the firewall. note that bind also should not have port potion in query-source statement. Make sure your firewalls don't do daft things like forcing any DNS traffic to come from a limited range of source ports, or blocking large UDP packets or EDNS. Allow DNS queries over TCP as well as UDP. Yes in firewall , both TCP and UDP DNS queries are allowed. allowed is one part, not to have broken firewalls that inspect (and break) DNS packets is another one. -- 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. I drive way too fast to worry about cholesterol. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Protecting bind from DNS cache poisoning!!!
Allow bind to use as wide a range of port numbers as possible for UDP traffic. On 09.08.10 17:14, Shiva Raman wrote: Yes this is allowed in the firewall. note that bind also should not have port potion in query-source statement. In addition, be carefull with the use of NAT on your firewall. This will probably unrandomize the port numbers on your outgoing requests. Ciao, Wolfgang -- wolfg...@solfrank.net Wolfgang Solfrank ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Protecting bind from DNS cache poisoning!!!
Am Mon, 09 Aug 2010 14:08:26 +0200 schrieb Wolfgang Solfrank wolfg...@solfrank.net: Allow bind to use as wide a range of port numbers as possible for UDP traffic. On 09.08.10 17:14, Shiva Raman wrote: Yes this is allowed in the firewall. note that bind also should not have port potion in query-source statement. In addition, be carefull with the use of NAT on your firewall. This will probably unrandomize the port numbers on your outgoing requests. Ciao, Wolfgang Port deviation could easily be tested via porttest.dns-oarc.net dig +short @127.0.0.1 porttest.dns-oarc.net txt porttest.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net. 195.180.9.198 is GREAT: 53 queries in 9.1 seconds from 53 ports with std dev 19687 Every result other than GREAT should alert you. Also, checking wether DNSSEC is working or not, send a recursing querie to your resolver and check the returned flags for ad. [t...@daddelkiste ~]$ dig +dnssec @127.0.0.1 iis.se a ; DiG 9.6.2-P2-RedHat-9.6.2-5.P2.fc12 +dnssec @127.0.0.1 iis.se a ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 12422 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;iis.se.IN A ;; ANSWER SECTION: iis.se. 21 IN A 212.247.7.218 iis.se. 21 IN RRSIG A 5 2 60 20100815115001 20100805115001 53249 iis.se. pWMYsqufhD4RkHX6IltLOcxMob3rNpc1+UnXZKgOMsO5HgbtIjALoq9+ ReqKziKev3PiEBLNdqrxT95TVlzVb7qgnLmlHABsap7m2uzuHFQKsFmh RGxqpiuzu9bPEIfZKout4TmzILaP1Nua4ntSXyyjS35EUszfX+F/Mqrm fcc= ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mon Aug 9 14:35:37 2010 ;; MSG SIZE rcvd: 217 Ciao Torsten ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Protecting bind from DNS cache poisoning!!!
On Mon, 9 Aug 2010, Shiva Raman wrote: I tried implementing dnssec using the following document http://blog.dustintrammell.com/2008/08/01/configuring-dnssec-in-bind/ That is rather out of date: it does not cover some important BIND-9.7 DNSSEC validation features, specifically RFC 5011 automatic trust anchor rollover, and it does not explain how to install the root trust anchor. Also you do not need to explicitly turn on DNSSEC validation: it is on by default but only works if you have configured one or more trust anchors. Here is my recent how-to: http://fanf.livejournal.com/107310.html Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ NORTH FITZROY SOLE: WEST OR SOUTHWEST, BECOMING CYCLONIC IN SOLE, 4 OR 5, INCREASING 5 TO 7. MODERATE OR ROUGH. RAIN. MODERATE OR GOOD, OCCASIONALLY POOR. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Protecting bind from DNS cache poisoning!!!
Dear All I am running Bind caching and bind authoritative servers with current 9.7 version. I would like to know the steps to be followed to protect bind from DNS Cache poisoning. The bind DNS server is running behind the firewall which allows only DNS queries . kindly share your views. Thanks in advance. Shiva Raman ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Protecting bind from DNS cache poisoning!!!
On 08/08/2010 11:29:52, Shiva Raman wrote: I am running Bind caching and bind authoritative servers with current 9.7 version. I would like to know the steps to be followed to protect bind from DNS Cache poisoning. The bind DNS server is running behind the firewall which allows only DNS queries . Run an up-to-date version of bind. Be fanatical about applying security patches promptly. Don't allow recursion /at all/ for queries from the general public to your authoritative servers, nor permit authoritative servers to send additional data from cache. Permit only your trusted clients to make recursive queries through your recursive servers. If you have sufficient DNS traffic to warrant it, it is very good to run completely separate instances of bind as authoritative and recursive servers -- use of virtualization techniques like FreeBSD jails can help reduce hardware costs. Otherwise, make use of the views feature to control who may or may not perform recursive queries via your servers. Allow bind to use as wide a range of port numbers as possible for UDP traffic. Make sure your firewalls don't do daft things like forcing any DNS traffic to come from a limited range of source ports, or blocking large UDP packets or EDNS. Allow DNS queries over TCP as well as UDP. Implement DNSSEC. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: cache poisoning
On 11.08.09 13:27, Nelson Serafica wrote: I need to set bind to listen to all address. I'm using AMAZON EC2 no, you don't. you configure listening IPs/ports by using listen-on and listen-on-v6. query-source only configures from which IP/port will your requests come from. -- 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. - Holmes, what kind of school did you study to be a detective? - Elementary, Watson. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
cache poisoning
Last year, there was a global threat about cache poisoning so I updated immediately my bind. I update it to BIND 9.5.0-P1 and did nothing to its named.conf Now, I'm setting up a secondary dns (in my previous emails) and I used BIND 9.6.1-P1. But when I do dig +short @NS2 IP porttest.dns-oarc.net txt, it is poor but when I do it on my ns1, it is great. ns2 is running the latest bind. I believe the fix for this is just update named to its new version. How come I'm still having poor when I'm running the new version of bind. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: cache poisoning
In message 4a80e783.4090...@gmail.com, Nelson Serafica writes: Last year, there was a global threat about cache poisoning so I updated immed iately my bind. I update it to BIND 9.5.0-P1 and did nothing to its named.conf You should have at least checked the query-source clauses to ensure that there wasn't a port specified. query-source * port 53; // bad query-source 10.53.0.1; // ok query-source *; // ok (default) query-source-v6 * port 53; // bad query-source-v6 10.53.0.1; // ok query-source-v6 *; // ok (default) Now, I'm setting up a secondary dns (in my previous emails) and I used BIND 9 .6.1-P1. But when I do dig +short @NS2 IP porttest.dns-oarc.net txt, it is poor but when I do it on my ns1, it is great . ns2 is running the latest bind. I believe the fix for this is just update named to its new version. How come I'm still having poor when I'm running the new version of bind. If the query-source is ok then NAT's and firewalls can change the port as seen on the outside. Mark ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: cache poisoning
Thanks Mark! it works. I change my query source to one of the entry below and it works. Mark Andrews wrote: query-source * port 53; // bad query-source 10.53.0.1; // ok query-source *; // ok (default) query-source-v6 * port 53; // bad query-source-v6 10.53.0.1; // ok query-source-v6 *; // ok (default) ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: cache poisoning
On Aug 10, 2009, at 10:06 PM, Nelson Serafica wrote: Thanks Mark! it works. I change my query source to one of the entry below and it works. Maybe a strange question. Why did you have a query source statement in your configuration in the first place? Bill Larson Mark Andrews wrote: query-source * port 53; // bad query-source 10.53.0.1; // ok query-source *; // ok (default) query-source-v6 * port 53; // bad query-source-v6 10.53.0.1; // ok query-source-v6 *; // ok (default) ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: cache poisoning
I need to set bind to listen to all address. I'm using AMAZON EC2 Maybe a strange question. Why did you have a query source statement in your configuration in the first place? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: cache poisoning counter-measures
On 05.01.09 15:29, Chris Henderson wrote: I'm trying to implement some basic counter-measures against the Kaminsky bug. I have had to configure my switch to allow any incoming query to TCP and UDP port 53 on my slave DNS server. I was wondering if this is going to cause any problem as far as security is concerned. Bind version 9.4.1 running in chroot jail. The bug does not lie server operations. It lies in client operations. While people are querying your slave server, you have no problem. If you send recursive queries to the mentioned name server, and it sends queries out, that is a problem. It must send queries from randomised ports, which means, that not only packets to tcp/udp port 53 from outside must be allowed, but packets from any port on your server to tcp/udp 53 anywhere must be allowed and also packets from tcp/udp port 53 anywhere to any port on your server must be allowed. -- 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. Linux IS user friendly, it's just selective who its friends are... ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
