Question About Internal Recursive Resolvers

[Greg Choules]

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 at 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 at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20221015/dbf31000/attachment.htm>