Question About Internal Recursive Resolvers

[Greg Choules]

Hi Bob.
In a previous life I did just this. Large resolvers for customers and
internal users, defaulting to the Internet but with specific configuration
to internal auth-only servers for private zones (I used stub but
static-stub and mirror are alternatives - they each behave slightly
differently). In my case these resolvers forwarded (only) to Internet-edge
resolvers, which then did recursion. There were no internal roots anywhere.
Essentially the idea was, treat internal resolution as specific exceptions
to the general rule of "everything lives in the Internet".

One note of caution is, beware DNSSEC validation. These days it is on by
default, which is not necessarily a problem, even if your internal zones
aren't signed. But what it does mean is that internal zones *must* be
properly delegated from parent zones in the Internet, otherwise the chain
of trust will be broken and validation will fail. e.g. if your registered
domain in the outside world is "example.com" then a valid internal zone
could be "internal.example.com".
You can configure BIND to *not* validate certain zones, which is a way
around it. But I'd recommend doing it right from the start, if you have the
option.

I hope that helps.
Greg

On Fri, 14 Oct 2022 at 17:08, Bob McDonald <bmcdonaldjr at gmail.com> wrote:

> I'm thinking about redesigning an internal DNS environment. To begin
> with, all internal DNS zones would reside on non-recursive servers
> only. That said, all clients would connect to recursive resolvers.
>
> The question is this; do I use an internal root with pointers to the
> internal zones (as well as the outside DNS world) or do I include stub
> zones to point at the non-recursive internal servers?
>
> Access to the internal DNS zones would be controlled by location.
> (e.g. guest WiFi devices would NOT have access to internal DNS
> zones...)
>
> Recursive resolvers would allow implementation of features such as RPZ,
> etc.
>
> Regards,
>
> Bob
> --
> 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/20221014/d154e505/attachment-0001.htm>