On 12/27/24 15:40, Roberto Braga wrote:
For this, I must use 2 servers:
I agree that you should use two servers. But I also believe you could
do what you're doing with one server, one OS image, and maybe even one
instance of BIND.
The first, like Recursive DNS itself, is what clients will use to
configure DNS.
The second, as a copy of root, must be consulted to the first if it does
not have a cache.
Forming a hyperlocal recursive DNS composed of 1 computer with the
address that clients will use as DNS and 1 computer with the root copy
(slave of the root servers).
Why not have a copy of the root zone on the same recursive server that
clients use?
You can easily include secondary copies of the root zone in the
recursive DNS server itself.
There may be some room for discussion on if this should be done or not.
But I've not had any problems including root on my personal recursive
servers for years.
If you do want to have some separation, you can use separate views in
the same daemon.
If you want more separation, you can have separate daemons on the same
system.
The scheme below is working, but I would like someone more experienced
who can review and identify if I'm doing it correctly, if there are
flaws or how I can improve this structure... Thank you.
The biggest thing that I see is that you have two cascaded single points
of failure. If either of them goes offline, say for patching, your
entire user base is without recursive DNS service.
I would suggest configuring both servers identically; zones, same mirror
copy of root, same named.conf values.
I would also encourage you to explore VRRP (likely via keepalived) to
have the two IPs that clients are configured to use be able to float
back and forth between the two identical systems. Each IP should have
an affinity to one system but also be able to be hosted by the other system.
Yes, clients should fall back to the secondary DNS server if the primary
is unreachable. However I've seen some really bad failure modes with
this. And all of these failure modes can be avoided if the surviving /
online server simply adds the down / offline server's service (virtual)
IP (VIP) to it. That way clients still see both IPs as online and usable.
To use the VRRP technique properly you will need a management IP for
each server and a service / virtual IP (VIP) for each server, so a total
of four IPs.
With this technique, either server can be offline for maintenance and
clients will have full functionality using either IP.
As Greg suggested, explore "mirror" zones instead of a secondary zone
transfer of the root zone.
I would also encourage you to read about and consider a local instance
of the AS112 Project wherein you also have mirror copies of some
infrastructure zones to help keep DNS internet background radiation
contained in your environment.
Link - AS112 Project
- https://www.as112.net/
Note, just because you have a local copy of the root zone doesn't mean
that you will be able to resolve names without an Internet connection.
The root zone is just a very small subset of the names on the internet.
Some additional comments on your config:
- Why are you disabling query name minimization? That has privacy
implications? Is that an optimization for your configuration?
- You may want allow-query-cache { ... };
- You might want to define an ACL and place your IP networks therein.
That way you can reference that ACL name in your allow-* statements.
This helps ensure that you don't miss and update to the duplicated data
in the future.
- Check out empty-zones-enable, empty-server, and empty-contact.
- Checkout server-id, version, and minimal-responses.
- Seeing as how you're not showing any authoritative zones, it might
not matter. But it's really nice to have rndc capability to have BIND /
named alter / reload some things on the fly.
--
Grant. . . .
--
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
