<div dir="ltr">Hi Grant.<div>My understanding is this, which is almost identical to what I did in a former life:</div><div><br></div><div>client ---recursive_query---> recursive_DNS_server ---non_recursive_query---> internal_auth/Internet</div><div><br></div><div>where:</div><div>client == laptop/phone/server running stub resolver code</div><div>recursive_DNS_server == what Bob is asking about, a recursive-only DNS server<br></div><div>internal_auth == the other component, an authoritative-only DNS server</div><div><br></div><div>Separation of internal and external clients - preventing external ones from accessing internal names - is easily achieved with a couple of views, such as this:</div><div><br></div><div>view "external" {</div><div>    match-clients { address_match_list }; # the set of all possible addresses that external clients may be given.</div>    match-destinations { address_match_list }; # the address(es) given to external clients for their DNS service.<br><div>  ...<br>};<br>view "internal" {</div><div>   # 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).<br>  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.<br>  attach-cache "external"; # internal clients have access to records that have already been cached due to queries made by external clients.</div><div>   ...<br>};<br></div><div><br></div><div>Greg</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 15 Oct 2022 at 18:52, Grant Taylor via bind-users <<a href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 10/15/22 10:34 AM, Matus UHLAR - fantomas wrote:<br>
> If you are an ISP/registry/DNS provider, it makes sense to separate <br>
> authoritative zones for your clients' domains, for all those cases your <br>
> client move their domains somewhere else without notifying you (hell, <br>
> they do that too often), or to be able to prepare moving domains to your <br>
> servers.<br>
<br>
#truth<br>
<br>
> forward zones     - named sends recursive query to the primary servers<br>
> stub zones        - named fetches NS records from primary servers and <br>
> uses them for resolution<br>
> static-stub zones - named forwards iterative (non-recursive) requests to <br>
> primary servers<br>
> <br>
> clients accessing any of these zones must have recursion allowed and <br>
> recursion must be enabled in BIND.<br>
<br>
Please clarify where recursion needs to be allowed; the BIND server <br>
clients are talking to and / or the back end server that BIND is talking <br>
to on the client's behalf.<br>
<br>
I'm not completely clear and I think it's better to ask than to assume <br>
incorrectly.<br>
<br>
> On 10/15/22 10:03 AM, Bob McDonald wrote:<br>
>> If a non-secure client (read the next sentence...) accesses the same <br>
>> recursive server as a regular client, it will have access to the <br>
>> internal zones by default.. Therefore we need to have some sort of <br>
>> access controls in place.<br>
> and THIS is exactly the reason you SHOULD put your internal zones on <br>
> your internal server.<br>
<br>
Sorry if I'm being particularly dense this morning, but I'm not <br>
following ~> understanding Bob's and Matus's statements like I want to.<br>
<br>
How does hosting the zone on an internal server provide any additional <br>
security?  Or are you simply relying on other security mechanisms to <br>
prevent non-secure clients -- as Bob described them -- from accessing <br>
the server ~> zone?<br>
<br>
I feel like, by default -- as Bob described, any hosted zone is going to <br>
be accessible by any client that can query the server.<br>
<br>
With this in mind, I feel like the type of zone; primary / secondary / <br>
mirror / stub / static-stub / forward, makes little difference in and of <br>
itself.  Rather, it would be dependent on global and / or per-zone <br>
allow-* statements to protect the server / zone(s) at the BIND <br>
application level.<br>
<br>
Does that make sense?<br>
<br>
What am I missing / misunderstanding?<br>
<br>
> that's why we are here.<br>
<br>
:-)<br>
<br>
<br>
<br>
-- <br>
Grant. . . .<br>
unix || die<br>
<br>
-- <br>
Visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list<br>
<br>
ISC funds the development of this software with paid support subscriptions. Contact us at <a href="https://www.isc.org/contact/" rel="noreferrer" target="_blank">https://www.isc.org/contact/</a> for more information.<br>
<br>
<br>
bind-users mailing list<br>
<a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
</blockquote></div>