OK, if a known client accesses DNS on the internal network, that client is pointed at a recursive resolver (e.g by DHCP). That resolver either provides access to the internal DNS zones (e.g. via stub zones) or sends the client query to the root servers on the internet. An unknown client (e.g. guest WiFi) will be given the same resolver address for its DNS server. At this point it would require ACLs to prevent that unknown client from accessing the internal DNS zones. All DNS traffic from that client would be sent to the internet.
Another way to achieve that would be to have a separate set of DNS resolvers for unknown clients (resolver addresses handed out via DHCP). That's my current view of how to get things done in this case. What I'm discerning from the discussion so far is that this isn't strictly necessary. The internal DNS zones can/should reside on the recursive resolvers. The question of unknown client access to internal DNS zones is resolved (no pun intended...). RPZ COULD be implemented on ANY of the recursive DNS resolvers. The tsig key discussion is around its use as a method of allowing updates to internal DNS zones. Strictly hypothetical. Don't get hung up on it. Thank you all for the information. You've provided answers to my questions and have renewed my faith in geekdom. If anyone is still confused, I'd be glad to discuss this offline until we have a final solution. Then we can publish if necessary. 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
