Testing a new master server...

[John W. Blue]

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-bounces at lists.isc.org] On Behalf Of Bruce Johnson
Sent: Wednesday, November 18, 2020 11:35 AM
To: bind-users at 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 at lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users