Question About Internal Recursive Resolvers

[Matus UHLAR - fantomas]

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

>On 10/15/22 10:34 AM, Matus UHLAR - fantomas wrote:
>>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.

On 15.10.22 11:50, Grant Taylor via bind-users wrote:
>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.

recursion must be allowed on the BIND server that is supposed to forward 
queries from clients, and those clients need to have recursion enabled on 
that BIND server.

the Bob mentions copnfiguring recursive server so I assume everything is 
already allowed, I just noted that recursion is needed for zone types above.

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

Company has internal/recursive servers only accessible by internal clients.

If you configure internal zones on these servers, all internal clients will 
immediately have access to these zones, no measures needed (though possible)

If you configure internal zones on separate servers, you must:
- configure recursive servers to direct lookups to authoritative servers
- control access to those zones on authoritative servers.

so, you must take two more measures.


>I feel like, by default -- as Bob described, any hosted zone is going 
>to be accessible by any client that can query the server.

Bob describes moving internal zones to non-recursive servers.
https://lists.isc.org/pipermail/bind-users/2022-October/106756.html

Which requires those measures above, without obvious need, except the 
misunderstood principle "separate recursive and authoritative servers".


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

the point is to make the system simple and robust.

separating DNS servers may make DNS more robust and it may make DNS less 
robust.


Bob describes access to different zones from different clients (internal, 
wi-fi, ...) configured on recursive server.

There's no visible gain if Bob moves internal zones to another server.

However there are still some questions to this
https://lists.isc.org/pipermail/bind-users/2022-October/106764.html

- where/how/why is TSIG used
- how is the DNS configured now, don't internal recursive servers have 
   access to the internet now?



-- 
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.
Fighting for peace is like fucking for virginity...