On Nov 18, 2020, at 11:26 PM, John W. Blue via bind-users <bind-users@lists.isc.org<mailto:bind-users@lists.isc.org>> wrote:
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. I am probably explaining this poorly. Our college has units in 5 different buildings on two campuses in different cities. The University network has set up Vlans in those buildings on the larger network that they control, and we provide DNS/DHCP/Windows Domain service on those VLANS, so when a dhcp request comes from one of them it is directed to this server. The server itself resides on a vlan that is tied to one port from the switch, and if it is moved to a different port (which it now has to be, since it’s now going to be virtualized) and that is not under our control, but the main campus network management, so that needs to be coordinated. 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? It isn't ‘easy to break’, it’s that I am a neophyte at setting this up. We’ve really had zero issues with DNS/DHCP with the current setup, but I wasn’t the one doing the configuring. As I said, I’m probably overthinking what can go wrong. The previous person who did this told me “Just copy all the configuration files over to the new box, give it the right IP address and you’re good”. 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? It faces the open internet. We have a mix of public and private zones. If one server is responsible for both DNS/DHCP for everything would it make more sense to split the roles out? That’s probably a very good idea, that it hasn’t been done before now is that this setup has worked reliably for decades, and we pretty much proceeded on the “it ain’t broke, so lets not fix it” …then the people who had done this retired or moved to other jobs, I’m now the “*nix ‘Expert’"…and now it’s old enough that we have to deal with replacing it in an orderly fashion rather than on an emergency one. 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". Thanks for these tips, this makes me feel a lot more confident that I'm on the right track. 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<mailto: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<mailto: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 -- 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
