Re: Testing a new master server...

[Bruce Johnson]

On Nov 18, 2020, at 11:26 PM, John W. Blue via bind-users 
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
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 

Re: How bind select NS record during recursive queries

[Tony Finch]

Duleep Thilakarathne  wrote:
>
> How does bind select NS entry during recursive queries  , when the answer
> section has multiple NS entries.

It's roughly based on measuring the smoothed round trip time (SRTT) to
each nameserver and picking the closest, with a lot of randomness in the
mix. Try searchengineering [BIND SRTT] for lots of discussion of the
algorithm.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
a fair, free and open society
___
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

How bind select NS record during recursive queries

[Duleep Thilakarathne]

Hi,

How does bind select NS entry during recursive queries  , when the answer
section has multiple NS entries.


regards
DT
___
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