08-21-2018 12:41 PM
I am in the process of moving my internal DNS to use MS IPAM Sync versus standard zone transfers between Infoblox and our MS AD DNS Servers.
As a part of the process, in order to transfer the zones, I would have to delete the production zones from my current view, allow the zones to replicate via MS Sync and then readd the zones to my grid members.
I am looking for a way to do this so that I won't incur an outage and have to delete zones. My though was to create a different DNS view with a deny acl so that it doesn't get used by clients, place that view at the bottom of the view order for my grid members, and replicate the zones from AD into this new view. I believe that this would allow me to sync all of the data without deleting the zones in the old view and then when I am ready I can simply flip the DNS view order and match client ACL's to the new zone.
Has anyone else done this? What was the process you used? Is my logic sound?
08-29-2018 08:21 PM - edited 08-29-2018 08:23 PM
Sorry for the delay in our response. If the account used for synchronization have adequate privilege over the Microsoft server, you don’t necessarily have to delete them in order to add grid secondaries. If yes, you may just add additional name servers to the zone which has already been synchronized. In addition to this ensure that zone transfers are allowed to the grid secondary IP addresses from Microsoft & make sure to ‘notify’ them. What you need to keep in mind is, a data which came into Infoblox via MSSYNC *do not* take part in DNS resolution. So the same data should come into Infoblox via zone transfer.
Additional important note : In case if the Microsoft server fails(or delays) to notify the grid secondaries upon addition of a new record & if the data gets replicated to Infoblox via MSSYNC(Before zone transfer could happen), you may expect NXDOMAIN responses for that newly added record from Infoblox Secondary. You would continue to see NXDOMAIN response for that newly added record from Grid secondary until the data gets pulled via zone transfer. In such cases an administrator would wonder why the Infoblox Grid secondary is returning NXDOMAIN responses though they could see the record in Infoblox. This would be the case when you create a new record inside the MS managed zone from Infoblox. You’ll be able to add a new record to the secondary zone because of the reason that the grid is managing the Microsoft zone(While in normal cases a secondary server *does not have* the privilege to add new RRs & should be done from the master server). Now depending upon the Microsoft synchronization interval(Grid -> Microsoft servers -> Select the Microsoft server to check out this property) -> The data would be pushed to Microsoft server -> This would change the serial number for the zone on Microsoft server & the grid secondaries gets notified -> Zone transfer happens between the grid secondary and the Infoblox DNS server & now Grid secondaries would start resolving the record as expected.
I hope this makes sense. Let me know if this is not what you need or whether there are any additional questions left to be answered.
08-30-2018 05:46 AM
Thanks for the response. Let me clarify some things for you. I understand what you are saying in your post. Here's my situation:
- MS AD DNS is authoritative for internal DNS zones
- Infoblox is currently serving these zones as a secondary name server.
- Infoblox receives these zones via zone transfer currently.
- When I implement MS IPAM DNS Synchronization, there will be conflicts because the zone already exists in my internal view.
- In order to clear those conflicts I would have to delete the existing zone on Infoblox and allow MS IPAM to synchronize the new zone. This will obviously create the NXDOMAIN situation as you described.
- Once replication is complete, I will then have to add the infoblox members back to each zone replicated. There is a caveat to this. If there are host records that already exist in IPAM that are in conflict with a replicated record, the host records have to be deleted before you can add the Infoblox members back to the zone.
What I am trying to solve:
- Avoid deleting the zone to clear conflicts - Some of my zones are rather large and could have significant impact during the replication and member addition to the zones. I cannot have a situation in which I am sending NXDOMAIN's for a period of 3 to 5 minutes for these zones.
- Avoid deleting host record conflicts - I have several hundred host records (IPAM only. Not enabled in DNS) that would be in direct conflict with replicated DNS records. This may be unavoidable but if I have to delete them, I would rather do it in a controlled manner instead of during a window when I am trying to replicate zones and incurring a DNS outage.
My proposed solution to mitigate:
- Create a new DNS view for MS IPAM Sync
- Place a match client ACL on the new view to match more specifically than the current internal view
- Move the new view to the bottom of the view order
- Configure MS IPAM Sync to replicate AD DNS zones into the new view.
- Post-replication, add Grid Members to the zones so they will serve them.
- Fix up host record conflicts.
When I am ready to flip, I believe I should be able to move the new view up in the view order and change the match client ACL to allow my networks to resolve. At the same time, I will move the old view down and change it's match client ACL to deny all.
I believe this process will work and significantly minimize the overall impact of converting over to MS IPAM Sync. I really am looking for guidance to see if this has been tested by anyone else and if there are any caveats I need to consider.
10-23-2018 07:59 AM
In case somebody has the same questions...
I went ahead and stood up a test to verify that this will work.
Here's what I came up with:
- Stood up an Azure 1425 as a standalone lab box.
- Connected the lab box to our Dev / Stage AD environment.
- Created two named acl’s for match clients: RFC-1918-Allow and Deny-All
- Used default DNS view as zone transfer view
- Configured zone transfers and verified proper transfer and DNS resolution for clients.
- Applied RFC-1918-Allow to Zone Transfer View
- Created New Internal View for MS IPAM Sync
- Added Microsoft Servers and configured synchronization to use MS IPAM Sync View
- Applied Deny-All match client ACL to MS IP Sync view
In testing, we were able to successfully flip the match client ACL’s between the two views and get proper DNS resolution after the fact.
Some things that might need to be taken into consideration / tested:
- Shared Record Group Associated Zones may need to be updated
- If Infoblox is authoritative for zones, they will need to be moved into the new view
- If you have other MS Servers already sync'ing, you'll need to change their sync views
- vDiscovery Jobs may need to be updated with new view
Will update once I have fully vetted this...