primary or secondary for a DNS grid member?

Posts: 10
6482     0

running 8.1.3 ....


I have one unit as my Grid Master  (of course).  It does not serve DNS zones to the public.  I have two members that do serve zones to the public.


For years I have configured my DNS NameServerGroup to have the GM as the Grid Primary for the zone (in stealth mode to avoid its NS record being added) and the two public members listed as Grid Secondary nameservers using grid replication for data transfer.


Now I am reviewing all this (about to import 500 new primary zones from a downstream client) and am stumped ... what are the Pros and Cons to marking the two public members as Grid Primaries?


I believe today as Grid Secondaries, their NS records are put in every zone they serve, so that's not a reason to make them a Primary ...


I am not doing any DDNS.


Naturally the GUI always goes to the GM ... so any actual zone edits are done only on the GM.


That brings up a side question ... if the public facing units were to be marked as Primary, how would they get data from the GM ?


Maybe I am poking the bear ... AFAIK its working fine and perhaps I should just leave it the way it is.


Been trying to find hints in the Admin Guide ...


thoughts anyone ?


Re: primary or secondary for a DNS grid member?

Posts: 357
6483     0

With your planned import, I am not sure how you have planned about going about this but the first thing I would suggest is to setup a Name Server (NS) Group and assign that NS group to your zones. This allows you to set the name server assignments (primaries and secondaries, etc) for your zones one time within that NS group so if you ever need to make any changes in the future, you only need to update that NS group and restart services without having to go in and touch every single zone. Both the CSV Import feature or Data Import Wizard allow you to set this on the fly during the import process, or you can even leverage the CSV Import feature to set this after the fact as well. This really goes a long way to making it easy to manage your zones on an ongoing basis.


With that said, the 'multi-master' feature that you referenced where you can set multiple servers as primaries for your zones is useful where you want the primary name server (mname) returned in the SOA record for client queries to use the name of the server which is being queried and is probably more important when using DDNS. By default, the behavior in the backend will pretty much be the same as what you are used to. Updates to the zone will be processed from the Grid Master and sent to the servers assigned to the zone as part of the Grid replication process.


If DDNS was involved, updates would be sent from the primary handling the update, send it to the Grid Master as part of the Grid replication process and then the updates would trickle down as appropriate to other servers using the configured update process (Grid replication or zone transfers).





Showing results for 
Search instead for 
Did you mean: 

Recommended for You