Hi Grant. My understanding is this, which is almost identical to what I did in a former life:
client ---recursive_query---> recursive_DNS_server ---non_recursive_query---> internal_auth/Internet where: client == laptop/phone/server running stub resolver code recursive_DNS_server == what Bob is asking about, a recursive-only DNS server internal_auth == the other component, an authoritative-only DNS server Separation of internal and external clients - preventing external ones from accessing internal names - is easily achieved with a couple of views, such as this: view "external" { match-clients { address_match_list }; # the set of all possible addresses that external clients may be given. match-destinations { address_match_list }; # the address(es) given to external clients for their DNS service. ... }; view "internal" { # there is no `match clients`. Any client not already match by the "external" view potentially has access to this view, if they target the correct service address(es). match-destinations { address_match_list }; # the address(es) given to internal clients for their DNS service. Different from the one(s) given to external clients. attach-cache "external"; # internal clients have access to records that have already been cached due to queries made by external clients. ... }; Greg On Sat, 15 Oct 2022 at 18:52, Grant Taylor via bind-users < bind-users@lists.isc.org> wrote: > 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 servers > > stub zones - named fetches NS records from primary servers and > > uses them for resolution > > static-stub zones - named forwards iterative (non-recursive) requests to > > primary servers > > > > clients 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 > > -- > 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 >
-- 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