10-21-2015 06:56 AM
We have just started to use it in production. We have 50 or so reverse zones running on 4 physical master servers. So far we have not seen any issues.
We have been asking for some performance data on multimaster to see what moving several thousand zones to this configuration would do to our grid and the individual members. To date we have not been provided any rough numbers to go on so we have been attempting to gauge this on our own.
01-11-2016 04:07 AM
I use Infoblox multi-master DNS along with multiple GSS-TSIG Keys. It has been running about a year now. I have 6 HA Authoritative DNS Servers that span Americas, EMEA, and ASPAC that are Multi-Master for 4 AD Domains. I have also used it with non-AD domains as well and it works great! I am in the process of consolidating over 130+ AD Domains into 4 AD Domains. My 6 Infoblox servers are processing over 200+ updates per seconds for just one of the AD Domains. In my testing what was taking 15 minutes to 3 hours to update DNS with a MS DNS AD replication environment. With Infoblox the same updates now happens within seconds with the Infoblox solution. This has made a huge difference in our cloud environments that need to make changes quickly on our internal networks. With the multiple GSS-TSIG keys we can now update all our reverse zones using all 4 AD Domains securely. I have not seen a difference in performance of the Infoblox boxes since turning it on. That being said I would still not make every domain multi-master all at once. Start with your largest domains and enable one at a time giving it a week or so before doing your next domain. Keep an eye on your servers performance.
01-25-2016 02:22 PM - edited 01-25-2016 02:25 PM
When I look at our Multi Master DNS going forward, I have run into a issue.
We have a conbiniation of DNS zones needing GSS-TSIG updates on Microsoft servers and some getting GSS-TSIG updates mastered on Infoblox.
At smaller edge sites a very common setup for us is to have a single infoblox device runing an anycast DNS and DHCP fail over back to other core Infoblox devices.
So the current Infoblox DHCP severs SEND GSS-TSIG updates to Microsoft hosted DNS zones.
Currently the edge devices are read only secondaries for any DNS zones they host locally with the masters being in the core.
Occasionally, this has been an issue when an edge site looses WAN connectivity. DDNS updates fail and the longer that the site goes with no local DDNS udpates, the more things start to break as their IPs change but the DNS zone cannot be updated.
I thought that multimaster DNS was going to help with this but it apears that it will not. A single Infoblox piece of hardware cannot BOTH send GSS-TSIG via its DHCP service AND accept GSS-TSIG updates via its DNS service.
In the core, with a seperation of services, this is not an issue. But a small edge site could not host a mutimaster DNS zone updated via GSS-TSIG AND send GSS-TSIG updates to microsoft via its DHCP service.
Is there a solutoin I am missing besides buying two pieces of hardware?
Snip from 7.2 Admin guide:
A NIOS appliance can use GSS-TSIG authentication for DDNS updates for either one of the following:
• A NIOS appliance serving DHCP can send GSS-TSIG authenticated DDNS updates to a DNS server in an AD domain or multiple AD domains whose domain controller is running Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, or Windows Server 2012 R2. The DNS server can be in the same AD domain as the DHCP server or in a different domain.
— For information about sending secure DDNS updates to a DNS server in the same domain, see Sending Secure DDNS Updates to a DNS Server in the Same Domain on page 917. — For information about sending secure DDNS updates to a DNS server in a different domain, see Sending Secure DDNS Updates to a DNS Server in Another Domain on page 925
• A NIOS appliance serving DNS can accept GSS-TSIG authenticated DDNS updates from DHCP clients and servers in an AD domain or multiple AD domains whose domain controller is running Windows 2000 Server, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, or Windows Server 2012 R2. — For information, see Accepting GSS-TSIG-Authenticated Updates on page 935.
Note: A NIOS appliance cannot support both of these features at the same time.
01-25-2016 02:33 PM
Do you really need to have the DHCP server authenticate though GSS-TSIG? Infoblox allows you to securely update a DNS domain without using a GSS-TSIG key. You could use option 81 to allow updates for different domains.
01-26-2016 06:02 AM - edited 01-27-2016 10:39 AM
The problem is, we have some DNS zones hosted on Infoblox and some hosted on Microsoft Active Directory domain controllers. Even if we were to make the decision to move all the DNS zones to Infoblox, the migration would take a year or more. During the migration the Infoblox DHCP server would need to be able to update both Infoblox hosted DNS zones and Microsoft zones.
Likewiese during a migration, Infoblox hosted DNS zones will need to accept DDNS updates from both Infoblox and Microsoft DHCP servers.
Because of this limitation, multimaster cannot be used to its fullest potential until you have fully migrated to Infoblox. In a large enterprise, this may take years to ... never.
02-23-2017 07:14 AM
I wanted to update this with our status after another year.
We have moved several thousand zones over to multi master. Our DDNS updates from non infoblox clients are working very well. They are finding their closest master and sending their updates there. The changes are replicating quickly around the grid.
The load on the members or the grid master does not seem to be significantly different than the updates coming to a single master.
However, in looking at update traffic patterns, we discovered that all of our Infoblox DHCP servers were sending their updates to one master in the multi master configuration. This is apparently by design. If you do not configure a preferred master for DDNS updates at the member level, the grid chooses a single master for every DHCP member to send every update to.
If that master member is down, nothing triggers the grid members to fail over to another master to send their updates to. The Infoblox DHCP servers simply queue their requests until that member comes back online or you manually change the grid configuration to select a different member.
Choosing a default master for each member does allow you to manually spread the load around by manually selecting a best master for that member to send its updates to. However, that member again will not search out another member if their manually configured default is not reachable.
It’s somewhat concerning that Infoblox isn’t auto failing between its own multi master environment for its DHCP members. A multi master environment should not require configuration changes to continue to function when a single master fails.
Yes, we could solve this by putting an anycast IP on each of our masters, but that really is adding complexity to solve a problem that multi master should have already solved.
We are working with our SE and sales team to see what the plans are for fixing what we see as a fairly large design flaw in how their DHCP server uses their multi master DNS configuration.