Hello Bruce!
For opening comments .. I have nothing but empathy for you and the firefight
you are in. "Intuitional inertia" is never enjoyable especially when you are
the one tasked with change.
So you indicated "upstream network management" is sending DNS/DHCP traffic but
then you say that it is from your vLAN's. That does not make sense.
It feels like what you meant to say is that you have a bunch of zones and there
is a ton of traffic (DNS/DHCP) being sent from your vLAN's *and* you need to
coordinate and changes with "upstream network management". The reason why I
bring this up is because (without extra data points) it feels like you are
attempting to replace an old bandaid with a new one hoping that will resolve
user angst.
Some things to think about as a sanity check:
If the current configuration is so easy to break, do you really want to keep
administrating a design that is doing that?
What change management processes are in place when OS patches need to be
applied or there DNS/DHCP maintenance to be done?
Does this server face the open Internet or is it exclusively an RFC1918 box?
If one server is responsible for both DNS/DHCP for everything would it make
more sense to split the roles out?
Assuming there is currently one RFC1918 server for everything, my thoughts (at
a very high level) would be to redesign the environment to start using a hidden
primary. Next, stand up two DNS servers as secondaries (configured with '
allow-update-forwarding ') each running DHCP to take advantage of "auto partner
down". With a hidden primary there is now a single source of truth on the
network that is being dynamically update by the secondaries.
When it comes time for maintenance, rebooting or taking one of the secondary
servers offline will not kill off the services for the users. When it is time
to apply patches to the hidden primary, do that after hours. "
allow-update-forwarding" is real-time forwarding not store and forward.
To address your question about "allow-transfer" and "allow-update" I don’t
think those are as important as disabling "also-notify".
Regardless, I do hope your migration goes smooth!
John
-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Bruce
Johnson
Sent: Wednesday, November 18, 2020 11:35 AM
To: bind-users@lists.isc.org
Subject: Testing a new master server...
I’m in the process of migrating our master DNS server from an ancient system
(it’s running RHEL4.0) to a modern system. This kind of fell in my lap; I’m
familiar with adding host assignments and such but managing the server itself
in the past is pretty much relegated to ’service named reload’ and finding the
newly introduced typo in the hosts or zone file if it fails...
It's a mildly complicated setup with a bunch of zones (including a big one that
is dynamically updated) and more pressingly I will need to coordinate with
upstream network management that sends DNS and dhcp requests from our VLAN's to
the specific switch port it is on when we do the cutover, then change the IP
address on the new server so that it repsonds as the old master, so if I can be
sure it’ll work I’ll have fewer main campus network mnanagers annoyed with me
and many fewer end users with torches and pitchforks at my door for breaking
everything...
I've made some changes to the configuration (mostly removing zones and address
assignments that are no longer valid) and I'd like to bring it up for testing
so I know it’s working before we do the cutover to production.
If I comment out the the allow-transfer directive so it does not divert
requests to our ‘real' secondary servers and the allow-update for the
dynamically updated zone, I think I should be able to bring it up in a master
server role (on a different IP address) without it interfering with our real
one, as the only clients that would actually talk to it would be ones that
specify that IP address for resolution.
Am I missing something or overcomplicating things?
--
Bruce Johnson
University of Arizona
College of Pharmacy
Information Technology Group
Institutions do not have opinions, merely customs
___
Please 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
___
Please 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
