09-12-2018 06:09 AM
We are trying to integrate our Infoblox platform with our vRA environment and so far everything works (almost) perfect, but we have an issue that we hope someone can help answer
When a VM is requested through the vRA catalog, vRA should create a host record in Infoblox, we have specified below attributes to accomplish that:
When a VM is requested in vRA the host record is created in Infoblox (by vRA), which is as intended. As a part of the provisioning workflow the VM will be renamed, to apply with our naming convention. As the last part of the workflow, the VM is powered on and joined to our AD domain (with the new name). Soon as the VM is joined to the Domain it will register itself in Infoblox with its new name. That causes the host record prior created to be converted to a record (and now two A-records and one PTR record exists in the Infoblox IPAM on the given IP). After some time the Infoblox/Update workflow is triggered in vRO to update the host record, but that will fail, as the host record has been converted to an A-record.
How to change this behavior?
Infoblox plug-in: 4.4 (same behavior with 4.3)
09-12-2018 08:10 AM
It sounds like the record created by the plugin is being overwritten by the DDNS update from the client. When this happens, the new record does not contain the extensible attributes (EA's) that the plugin supplied and the plugin will search for the record based on these EA's when performing updates (including removing the records). This is why you are seeing the workflows fail after the client performs its dynamic update.
To prevent the client from updating this record, make sure that it is not allowed to update the zone. This would result in its DDNS attempt to be refused, leaving the record created by the plugin intact.
09-12-2018 12:57 PM
Thanks for the quick reply!
It is unfortunately not an option to disallow DDNS in those network segments/zones.
Is is possible to add an "protect" to the host record through the API?
I assume other is facing the same issue/challange, do you know how they overcome this challange, is creating A-records/PTR (Infoblox.IPAM.createAddressAndPtrRecords) preferred? What is your recommendation?
Would it be possible to trigger the update of the host record faster (before the VM is powered on) as that would prevent the overwrite of host record?
09-12-2018 01:35 PM
This will be a consequence of allowing clients to update records in a zone since that is not secure. There is a "ddns_protected" function available in the record:host API construct so you may be able to do something to protect these records from being updated, but I do not have the steps available for implementing this. You can find additional details in the Infoblox RESTful API documentation.
Hope this helps.
02-04-2019 01:36 PM
Were you ever able to get past this? We too use a custom workflow that names our servers. The temporary name that the server gets built with is registered to infoblox. We need to update that name to reflect the name change and not have two different host entries.
02-04-2019 01:44 PM
There are a couple of different ways you might be able to handle this use case.
- Do not use the plugin to create records in DNS. Leave this to the client (your servers) to handle when they come online.
- Leverage two different zones. The plugin would be configured to update a different zone (and does not even need to be enabled) than what your servers are on and then when your servers send their updates, they will update a different zone altogether. This would eliminate the 'collision' that you are running into now, and still allow you to track the records from the plugin in IPAM.
02-08-2019 06:29 AM
Thank you for the suggestion. I'm a server guy, so I'm trying to make sure I understand things correctly. The issue we've ran into. Even if we only create a reservation, say in a different zone. Windows will come online and register itself with DNS. However, when we destroy that server. IPAM in vRA is unaware of the dynamically registered host entry created and only destroys what it knows about(the reservation).
Ultimately we're just trying to automate it from beginning to end as much as possible.