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 <bmcdonal...@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@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