On 10/15/22 10:03 AM, Bob McDonald wrote:
My understanding has always been that the recommendation is/was to separate recursive and non-recursive servers.
I too (had) long shared -- what I'm going to retroactively call -- that over simplification.
Now I understand I'm talking about an INTERNAL environment and the rules have over the years become somewhat lax... In this case I also believe this would provide a more granular approach to using security features such as tsig keys to control updates.
I don't know if the rules have become more lax so much as been clarified to indicate internal / private vs external / (semi)public servers. Semi-public in things like an ISP allows it's IP space to perform recursive queries.
If a non-secure client (read the next sentence...) accesses the same recursive server as a regular client, it will have access to the internal zones by default.. Therefore we need to have some sort of access controls in place.
I think the emphasis is on "by default". I also believe there are many ways to alter this default behavior.
Please forgive me if my post was confusing, arrogant, or naive. I'm simply trying to seek the wisdom of those on the list that have more experience or different experience than myself. Hopefully, I can gain from that wisdom and we can provide a kind environment where those less educated feel mentored.
I've found that almost everyone, myself included, tends to get invested and energetic in discussions. Sometimes even animated. But as long as we don't make anything personal and keep things at arms length, we can almost always see through the fog and help / learn from each other.
By all means, feel free to dislike / disagree with things I say / do. Please ask why I do things. Please share why you think / do what you do as I'd like to learn from you. But please, for the love of $DEITY please do not perpetuate ad hominem attacks. -- Not that anyone has in this thread.
-- Grant. . . . unix || die
smime.p7s
Description: S/MIME Cryptographic Signature
-- 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
