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
