Infoblox integration

MetalSoft integrates with Infoblox through the same extension mechanism used for all DNS integrations: a workflow extension runs an Ansible bundle on the Site Controller when DNS-relevant events occur, and that bundle talks to the Infoblox WAPI.

Two sample extensions are provided:

• Infoblox Host Records — one Infoblox host record per name, holding all of the instance’s addresses.
• Infoblox A-PTR — separate A, AAAA, CNAME and PTR records, and optionally zones and IPAM networks.

Consult Managing Extensions for how extensions are installed and published.

How this differs from the Power DNS example

The Power DNS integration is a complete end-to-end example: the DNS server itself ships as a container you enable on the Site Controller, and the extension creates its own zones, so the whole flow can be stood up from nothing. It exists for demonstrations and POCs.

Infoblox is the opposite. The grid is deployed, licensed and operated outside of MetalSoft, usually by a network or DNS team. MetalSoft does not install it and only writes records into it over the WAPI. Everything under Prerequisites — the WAPI account, the zones, the network path — has to be arranged with the Infoblox owners beforehand. The extension fails at run time, not at install time, if any of it is missing.

Choosing between the two extensions

	Host Records	A-PTR
Objects created	One record:host per name, all addresses attached	Separate record:a, record:aaaa, record:cname, record:ptr
Zone management	None — zones must already exist	Creates forward and reverse zones on demand; deletes the zone on deprovisioning
IPAM	None	Can create and delete networks, and allocate IPs
Minimum WAPI version	2.13	2.12
Blast radius	Records only	Records, zones and IPAM networks

Use Host Records when Infoblox is an established production grid someone else owns: MetalSoft only adds and removes host objects inside zones that the Infoblox team manages. The consolidated host object also suits multi-homed servers, and matches what most grids already use as their standard for server records.

Use A-PTR when MetalSoft should own more of the lifecycle — labs or dedicated views where zones come and go with infrastructures, environments where reverse zones are not pre-created, or where you want subnet allocations reflected in Infoblox IPAM. It is also the option for grids stuck on WAPI 2.12, or for tooling that queries record:a objects and does not handle host records.

If unsure, start with Host Records.

Prerequisites

1. The Ansible Runner capability must be enabled on the Site Controller. It is not a standalone service — it is turned on by setting ANSIBLE_RUNNER=enabled and its companion variables on the ms-agent service. Follow Enabling the Ansible Runner Capability.
2. The Site Controller must reach the grid VIP or member on TCP 443. No inbound flow is required.
3. A WAPI account with permission to create and delete records in the target zones and views. A-PTR additionally needs permission to create zones, and networks if IPAM management is left enabled.
4. A grid WAPI version of at least 2.13 for host records, or 2.12 for A-PTR.
5. infoblox.nios_modules — plus community.general for host records — must be present in the execution environment image. Collections are never installed from Galaxy at run time, and the collections/requirements.yml in each extension is a build-time input for ansible-builder, not something the runner reads. Neither extension declares an OciImage asset, so both run in the site’s default execution environment: bake the collections into that image and point ANSIBLE_RUNNER_EXECUTION_ENV at it, or add an OciImage asset and an ee option per task. See Execution environments.

Zone prerequisites

The forward zone MetalSoft writes into is the one configured under Global Configuration > DNS and selected on the site under Sites > Site. Record names are built underneath it.

Host Records does not create zones. Zone management was deliberately removed, so every forward zone must already exist in the target DNS view, and every reverse zone must exist before PTR creation is enabled. A missing zone surfaces as a WAPI error.

A-PTR creates zones when needed. The forward zone is created if absent, and reverse (in-addr.arpa) zones are created alongside PTRs while create_reverse_zones is true; ptr_require_existing_zone: true stops that. On a dns_zone_deprovisioning operation it also deletes the zone — consider this before pointing it at a shared production zone.

For both, PTR records require the reverse zone to exist or be creatable.

Infoblox Host-based Records

How it works

The extension binds the same playbook, host_records_playbook.yml, to seven stages: serverInstanceGroupUpdateDNS, serverInstanceUpdateDNS, clusterUpdateDNS, serverCreateDNS, serverDeleteDNS, switchCreateDNS and switchDeleteDNS.

MetalSoft writes the event payload to variables.json beside the playbook. The role normalizes whatever shape arrives — serverInstanceDNSRecordSet, clusterDNSRecordSet, or a raw serverInstanceRecordSet IP inventory — into a flat list of { host_name, ipv4_list, ipv6_list, state, ttl } items. Only A records seed the list, and all of a record’s addresses are collected into one item, so a multi-homed instance becomes a single host object rather than several records.

Each record’s status sets the desired state: active becomes present, deleting becomes absent — this is how deletions flow through, rather than a separate delete instruction. Items are applied with nios_host_record_compat and tagged managed-by=metalsoft. PTRs are created per address only when create_ptr (IPv4) or create_ipv6_ptr is enabled. Wildcard cluster names such as *.apps.example.com are included or skipped via include_wildcard_host_records.

Recommended use cases

• Production grids owned by a separate team, where MetalSoft should have no authority over zones or IPAM.
• Environments whose Infoblox standard is host records — IPAM views, DHCP integration and reporting are built around the host object.
• Multi-homed servers, where one name should resolve to several addresses in one object.
• Cluster and application records, including wildcards, via clusterUpdateDNS.

Activation and setup

1. Clone the repository and enter the extension directory:

git clone https://github.com/metalsoft-io/metalsoft-extensions
cd metalsoft-extensions/infoblox-host-records

2. Set your grid details in ansible/roles/host_records/defaults/main.yml:

infoblox_hostname: "infoblox.example.com"
infoblox_username: "metalsoft-api"
infoblox_password: "change-me"
infoblox_validate_certs: true
infoblox_wapi_version: "2.13"
infoblox_dns_view: "default"

The shipped file contains lab values, including a working-looking password — replace all of them. infoblox_wapi_version must be 2.13 or higher. While here, review create_ptr and create_ipv6_ptr (both false as shipped) and enable them only once the reverse zones exist.

3. Package the bundle:

cd ansible
zip ../infoblox-hosts.zip -r collections library roles host_records_playbook.yml
cd ..

library must be included — it holds nios_host_record_compat.py, which Ansible resolves relative to the playbook. collections carries only requirements.yml; the collections themselves come from the execution environment image.

4. Upload infoblox-hosts.zip to an HTTP server the Global Controller can reach, then set that URL in the assets section of extension.json:

"assets": [
  {
    "label": "infoblox-configuration",
    "name": "infoblox-configuration",
    "assetType": "AnsibleBundle",
    "url": "https://repo.example.com/extensions/infoblox-hosts.zip"
  }
],

5. Create and publish the extension:

metalcloud-cli extension create infoblox-host-records workflow "Infoblox host records" --definition-source extension.json --format json
metalcloud-cli extension publish <extension-id>

6. In Global Configuration > DNS, confirm the zone and nameserver configuration matches Infoblox. Then in Sites > Site, enable the extension for the site and select the matching DNS zone.

Infoblox A Records

How it works

This extension binds sync_infoblox.yaml to the same seven stages, plus serverInstanceUpdate — which lets it keep Infoblox IPAM in step with MetalSoft’s IP allocations even when no DNS record changed.

The playbook loads variables.json into dns_operation and detects the payload shape. It creates the forward zone if absent, then applies active records: A and AAAA individually, CNAMEs for the load-balancing record set, and PTRs either from explicit entries or auto-generated for A records marked ptr: enabled, creating reverse zones as needed. Records marked deleting are removed along with their auto-generated PTRs. When a serverInstanceRecordSet is present it reconciles IPAM networks, governed by autoCreateAndDeleteNetworks. On dns_zone_deprovisioning it deletes the zone.

Two shipped defaults will bite you:

• use_host_records is true in roles/infoblox/defaults/main.yml, despite the role’s own header comment saying the default is false. Left alone, this extension creates host records too — set use_host_records: false for genuine A/AAAA plus PTR behavior. The role also silently falls back to A/AAAA mode if infoblox_wapi_version is below 2.13.
• sync_infoblox.yaml sets allocate_ipv4: true and allocation_ipv4_network: "10.0.0.0/24" as play-level variables, overriding the role default of false. Correct these in the playbook, not the role defaults — play vars win.

Recommended use cases

• Grids on WAPI 2.12 that cannot be upgraded.
• Labs and dedicated views where zones are created and destroyed with infrastructures.
• Environments where reverse zones are not pre-created and you want PTR coverage without a request per subnet.
• Deployments that also want MetalSoft’s subnet allocations reflected in Infoblox IPAM.
• Tooling that queries record:a objects specifically and does not handle host records.

Activation and setup

1. Clone the repository and enter the extension directory:

git clone https://github.com/metalsoft-io/metalsoft-extensions
cd metalsoft-extensions/infoblox-a-ptr

2. Set your grid details in ansible/roles/infoblox/defaults/main.yml. Note the variable is infoblox_host here, not infoblox_hostname as in the host records extension:

infoblox_host: "infoblox.example.com"
infoblox_username: "metalsoft-api"
infoblox_password: "change-me"
infoblox_validate_certs: true
infoblox_wapi_version: "2.12"
infoblox_view: "default"

3. In the same file, set the record mode and the zone and IPAM policy:

use_host_records: false
host_record_ptr_enabled: false
create_reverse_zones: true
ptr_require_existing_zone: false
autoCreateAndDeleteNetworks: true

If the Infoblox team owns zones and networks, use create_reverse_zones: false, ptr_require_existing_zone: true and autoCreateAndDeleteNetworks: false — a missing network then fails the run rather than being created silently. Also change serverRecordsDomain, which ships as .example.invalid.

4. Correct the IP allocation variables in ansible/sync_infoblox.yaml, which override the role defaults:

  vars:
    dns_config_file: "{{ playbook_dir }}/variables.json"
    allocate_ipv4: false
    allocation_ipv4_network: ""

Set allocate_ipv4: true with a real subnet only if you want MetalSoft to allocate addresses from Infoblox IPAM.

5. Package the bundle:

cd ansible
zip ../infoblox.zip -r collections roles sync_infoblox.yaml
cd ..

6. Upload infoblox.zip to an HTTP server the Global Controller can reach and set that URL in the assets section of extension.json, as in step 4 of the host records setup.

7. Create and publish the extension:

metalcloud-cli extension create infoblox-a-ptr workflow "Infoblox A and PTR records" --definition-source extension.json --format json
metalcloud-cli extension publish <extension-id>

8. In Global Configuration > DNS, confirm the zone and nameserver configuration, then in Sites > Site, enable the extension and select the matching DNS zone.

Configuration requirements

Both extensions are configured entirely through their Ansible role defaults — neither declares extension inputs or configVars, so values are baked into the bundle at packaging time. Re-package and re-upload the zip to change them.

Required in both: the grid address (infoblox_hostname for host records, infoblox_host for A-PTR), infoblox_username and infoblox_password. Set infoblox_validate_certs: true for any grid with a trusted certificate; it ships as false.

Host records — behavior flags in roles/host_records/defaults/main.yml: create_ptr and create_ipv6_ptr (false), include_wildcard_host_records (true), delete_only and force_state for one-off maintenance runs. The README bundled with the extension lists different defaults for create_ptr and include_wildcard_host_records; the values in defaults/main.yml are the ones that apply.

A-PTR — beyond the flags in the setup steps, default_ttl (3600) applies when the payload carries none, and ip_record_comment_template sets the comment written on created IP records. ms_force_delete, force_delete_names and delete_active are manual override controls: useful for cleaning up after a failed run, but leaving any of them enabled in a published extension will delete records on the next event.

More details

Consult the extension READMEs for the full behavior of each playbook and for guidance on adapting them:

• Infoblox Host Records
• Infoblox A-PTR