Question About Internal Recursive Resolvers

Matus UHLAR - fantomas uhlar at fantomas.sk
Mon Oct 17 08:34:12 UTC 2022


On 15.10.22 16:03, Bob McDonald wrote:
>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...).

bind supports views, which work like virtual DNS servers, you can define 
some zones only in internal views.

you can even support multiple views for internal, wi-fi and external 
clients, where the internal clients will get recursion and see internal 
zones, wi-fi clients get recursion w/o seeing internal zones, and external 
zones only see public zones.

You can separate these clients by their source IPs, without any need to 
configure separate servers with separate iP addresses.

you may want to share dns cache between internal and wi-fi zones using 
attach-cache directive, and share public zones to the internal and wi-fi 
directives by configuring thoze zones using "in-view".

>RPZ COULD be implemented on ANY of the recursive DNS resolvers.

note that RPZ is designed to prevent/redirect access to destinations, not to 
clients - it's not designed to separate clients and access to zones this 
way.

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

Tsig is good security measure to only allow specific clients to submit 
updates. You can configure tsig key to belong to particular view even 
without having proper client IP address.


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

-- 
Matus UHLAR - fantomas, uhlar at fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Microsoft dick is soft to do no harm


More information about the bind-users mailing list