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, uh...@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...
--
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
