On 10/15/22 10:34 AM, Matus UHLAR - fantomas wrote:
If you are an ISP/registry/DNS provider, it makes sense to separate authoritative zones for your clients' domains, for all those cases your client move their domains somewhere else without notifying you (hell, they do that too often), or to be able to prepare moving domains to your servers.
#truth
forward zones - named sends recursive query to the primary serversstub zones - named fetches NS records from primary servers and uses them for resolution static-stub zones - named forwards iterative (non-recursive) requests to primary serversclients accessing any of these zones must have recursion allowed and recursion must be enabled in BIND.
Please clarify where recursion needs to be allowed; the BIND server clients are talking to and / or the back end server that BIND is talking to on the client's behalf.
I'm not completely clear and I think it's better to ask than to assume incorrectly.
On 10/15/22 10:03 AM, Bob McDonald wrote: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.and THIS is exactly the reason you SHOULD put your internal zones on your internal server.
Sorry if I'm being particularly dense this morning, but I'm not following ~> understanding Bob's and Matus's statements like I want to.
How does hosting the zone on an internal server provide any additional security? Or are you simply relying on other security mechanisms to prevent non-secure clients -- as Bob described them -- from accessing the server ~> zone?
I feel like, by default -- as Bob described, any hosted zone is going to be accessible by any client that can query the server.
With this in mind, I feel like the type of zone; primary / secondary / mirror / stub / static-stub / forward, makes little difference in and of itself. Rather, it would be dependent on global and / or per-zone allow-* statements to protect the server / zone(s) at the BIND application level.
Does that make sense? What am I missing / misunderstanding?
that's why we are here.
:-) -- 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
