Phase 2 — Validate

Phase 2 confirms the zone from Phase 1 is live: records resolve publicly, the F5 XC configuration matches what Terraform declared, and a re-plan reports no drift.

Readiness gate

Query the zone through the F5 XC API and confirm the expected record set exists. Fill the placeholders from the form at the top of the page, a .env file, or your shell.

curl -s \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  "xF5XC_API_URLx/api/config/dns/namespaces/system/dns_zones/xF5XC_DOMAINx" \
  | jq '{
    zone: .metadata.name,
    group: .spec.primary.rr_set_group[0].metadata.name,
    records: [.spec.primary.rr_set_group[0].rr_set[] | .a_record.name],
    status: (if (.metadata.name != null) then "PASS" else "FAIL" end)
  }'

A PASS with the demo-records group and the www / app / api names confirms the F5 XC side.

Public resolution

The domain is delegated to F5 XC, so the records resolve on the public internet. Check each name:

for name in www app api; do
  echo "$name.xF5XC_DOMAINx -> $(dig +short "$name.xF5XC_DOMAINx" A | tr '\n' ' ')"
done

Note

If the default RFC 5737 documentation addresses (203.0.113.x) are still in place, resolution returns those addresses even though nothing is hosted there — that is expected for a documentation demo. Replace them with real targets to serve live traffic.

Idempotency

A second plan against the unchanged configuration must report no changes:

1. Re-run the plan:

   cd terraform
   terraform plan

2. Confirm the output is No changes. Your infrastructure matches the configuration.

In CI, the same guarantee holds: reopening a pull request that does not change terraform/ produces an empty plan.

Continue to Phase 3 — Failover.