11-28-2017 10:16 PM
when you have your domain controllers updating the ADNS Grid member for a zone, if you have a single master configuration, then aren’t you running the risk of having no DNS server to update if that single master “Primary for the zone” goes down for some reason.
Would the domain controller accumulate the updates until that primary server comes back online? If not would you recommend a multi-master.
In my scenario, it is actually a migration from Microsoft to Infoblox, which means that the domain controllers will still need to do the updates.
Finally, if I needed those updates to be GSS-TSIG signed, then the keytab file will need to be installed on the DNS grid member, right?
Solved! Go to Solution.
11-28-2017 10:44 PM - edited 11-28-2017 10:51 PM
The best way to have redundancy for the Grid DNS Primary would be to have an High Availability (HA) Grid Member.
> Would the domain controller accumulate the updates until that primary server comes back online? If not would you
> recommend a multi-master.
Actually, the AD is not as dynamic as you might think. Unless you add/remove new DCs or do some fundamental changes, the records remain to be the same. So your AD will still work, even when the dynamic updates are not working (for hours/days), unless you do fundamental changes. However, each DC will send a update of the SRV records every hour. So once the Grid DNS Primary is back, it can recieve the updates.
> Finally, if I needed those updates to be GSS-TSIG signed, then the keytab file will need to be installed on the DNS
> grid member, right?
You can upload the keytab file in the Grid DNS Properties (Grid Level) or on the respective Grid Member. Then you would allow the GSS-TSIG updates on the respective zones or on the Grid Level.
Grid Level might be the better choice, as you implicitly allow all Forward (_msdcs and ad domain) + all reverse zones, including all future reverse zones.
Be aware. If you upload the keytab on the Grid Level, you need to open the Grid Member properties once, to make the GSS-TSIG options available. (Seems to be a little bug in the UI).
> In my scenario, it is actually a migration from Microsoft to Infoblox, which means that the domain controllers will
> still need to do the updates.
As said above ... once you imported the zones via DIW and did the cut-over (pointing DCs to Infoblox and deleting the Auth zones on MS DNS) your AD will continue to work. Even if the GSS-TSIG is not working immediatelly.
To verify the updates are working, you can do the following:
$ ipconfig /registerdns
// this will update the IPv4 address of the DC to DNS (A & PTR)
$ net stop netlogon && net start netlogon
// This will update the SRV Records. Be aware, you will not see an update in the Infoblox db as the records are exiting. You need to review the logs (Admin/Log/Syslog).
Consider the following options
Grid DNS Props / Updates / Advanced
// this will update the time-stamp even if no real chage. important for scavenging, if ever enabled.
Grid DNS Props / Updates /Advanced
Track the GSS-TSIG principals that create dynamic records - TRUE
// this will add the SPN to each of the records. It will show which member did the upgrade.
11-28-2017 11:19 PM
This is what I call the perfect answer. Thank you Stefan.
11-29-2017 11:57 AM - edited 11-29-2017 11:59 AM
One last clarificatin please Stefan.
Let's say that I configured my zone in the Grid to have a multi-master. Then when the domain controller sends an updated as a result of a fundemental change, does it send it to both primary Grid Members for that zone or only to one of them, which is the prefered?
If only one of them, does it send it to the second primary in a situation where the first or prefered primary can not be updated for some reason? If so is this process automatic and instant or would a delay be there.
11-29-2017 11:44 PM
I guess 'Default Primary' (as in the Admin Guide 'Defining the Default Primary' Page 970), comes in play for
Grid DHCP DDNS Updates (Grid internaly).
However, for your DDNS Updates from you MS Clients and DCs - they are querying the SOA Record of your AD Zone in DNS, like:
$ dig SOA example.com
example.com. 2430 IN SOA sns.dns.icann.org. noc.dns.icann.org. 2017102417 7200 3600 1209600 3600
The clients are using the MNAME field (in this case sns.dns.icann.org) to determin which is the DNS Master of the zone and will send the updates to this server.
So in your case, whatever server is used as Primary in the resolver conf of your Clients/DCs, will be asked for the SOA and the updates will be send to the server in the MNAME accordingly.
This is also the reason why it does not make a difference if the resolvers are pointing directly to the DNS Master or to any secondary or even to a caching DNS server. As long they are able to resolv the SOA record and subsequently the A record of the FQDN in the MNAME filed, the clients will be able to send the update to the DNS Master.
11-30-2017 12:00 AM - edited 11-30-2017 12:13 AM
Thank you Stefan. I guess in a multi master environemt though, there will be two SOA records and my qurey is if the first primary designated by the first SOA record can not be reached, then would the update be sent from the Domain Controller to the second SOA record automatically?
So would the flow be like this:
DC checks its prefered resolver for the SOA record of the zone and the resolver returns two SOA records. The DC tries to update the first master of the zone and since the first master is down then it will automatically try updating the second mater . Is this correct?
11-30-2017 11:00 PM
[Sorry for the delay. Was on the road.]
The resolver would always return only one SOA.
If the Primary Resolver = DNS Primary and fails, it would just use the secondary resolver and get the other DNS Primaries SOA.
Don't worry to much about it. It is in general very robust (AD and DNS), as long you can resolv the zone and have a running master it will work.
12-01-2017 12:18 AM
Thank you Sir. If there is anyone who needs to apologise it is me not you for being so persistent in my questions. I have made the Primary ADNS for all zones highly available as per your advise.