I'm having a problem with adding A records to our F5 Big-IP DNS (GTM's) with IPAM.
It seems that whenever I try to create an A record - IPAM creates an entry with a double..dot at the end of the hostname, causing the GTM to reject the record update.
i.e. ipamdns.mycompany.com.. IN A 184.108.40.206 is the result of trying to add a host record to the zone via IPAM. It shows up in IPAM with the double dots but the GTM rejects it as an illegal FQDN.
BigIP-DNS 12.1HF1 - it uses BIND 9.10 - and it is the zone master. Permissions with IPAM are fine - this all worked OK with IPAM 4.3. It's 4.5.1 that seems to exhibit the problem.
I've got a case open with SW but they don't seem to be too interested in the issue - keep telling me to quit putting double..dots on the hostname. (Frustrating)
Is anyone else successfully using IPAM to manage their GTM's?
Another IPAM issue with the F5-GTM's:
Apparently the current release of IPAM does not freeze/unfreeze the zone before making changes to the zonefile on a BIND server (GTM's included) - they only use rndc to reload it after the change.
Because the GTM is a dynamic DNS server, this causes the journal file for the zone to get out of sync and will stop BIND from reloading the zone, or worse, cause BIND not to load due to the error.
I have confirmed that this functionality is missing from IPAM, and as such IPAM *IS NOT* compatible with F5 GTM's for use in modifying the zone in any way. In fact, you can tip over your GTM if you do make changes and then reload the zone via ZoneRunner or CLI.
The missing commands are:
rndc freeze domain1.com IN internal
<modify zone file>
rndc unfreeze domain1.com IN internal
This has been put forward as a feature request - no indication that it will happen any time soon, if at all.
Yes I received a buddy drop on 8/21/17 that corrected the issue.
The root cause has to do with FQDN's. The F5's automatically append a dot on the zone and records to present a full FQDN. The IPAM product would also do the same thing, resulting in the double dot.. I think the IPAM product is assuming the use of $ORIGIN statements, which is common but not required. The 'fix' was to simply omit IPAM's insertion of a dot at the end of the record, leaving the original dot placed by the F5 in place.
I am currently testing the fix for reliability, and will also check it against our regular BIND servers to see how it works.
SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 150,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process. Learn more today by joining now.