Infraova
Docs/Verification

Operations

Verification

A change is not complete until Infraova proves it worked — DNS resolution, post-change checks, and what happens when verification fails.

Why verification exists

Executing a change through a provider API does not guarantee the change is working. DNS propagation can be delayed. A record can be written correctly at the provider but not yet visible globally. An authentication record can be syntactically correct but still fail validation. Verification is how Infraova closes the loop — it independently confirms that the change reached the expected state before marking an issue resolved.

What verification checks

Verification runs the same checks that monitoring runs, but targeted specifically at the change that was just made. For a DNS record change, verification checks that the new record is visible and resolves to the expected value — from multiple locations if propagation is a factor. For an authentication record change, verification parses and validates the record to confirm it is syntactically correct and matches the intended policy.

Remediation complete↓Verification starts↓DNS resolution checked↓Record validated↓Expected state confirmed↓Issue resolved

DNS propagation

When Infraova changes a DNS record, the change is applied to the authoritative nameserver immediately. But DNS propagation — the time it takes for resolvers around the world to see the new value — takes time. The TTL of the previous record determines the minimum propagation time. Infraova waits for the TTL to expire and then runs verification against multiple resolvers to confirm the change is visible globally.

Note

Infraova does not mark an issue resolved until DNS propagation is confirmed. If you see a change in Completed status but the issue is still showing as open, propagation is likely still in progress.

Verification failures

If verification fails — the expected record is not visible, the value does not match, the authentication record does not validate — Infraova surfaces a verification failure. A verification failure means the change was applied at the provider but something went wrong between execution and the expected outcome. Common causes include propagation delays beyond the expected window, a conflicting record from another source, or a provider caching issue.

What happens after a verification failure

A verification failure reopens the issue with a Verification Failed status. Infraova records what was expected and what was found. You can investigate from the issue detail view. In most cases, waiting for full propagation and then manually triggering a re-verification resolves the issue. If the problem persists, the diagnosis in the failure record points to what needs to be investigated.

Verification and the audit trail

Every verification pass is recorded in the audit trail — what was checked, what was found, and whether verification passed or failed. This creates a complete operational record: the change was made, and the change was confirmed. For clients or stakeholders who want proof that infrastructure changes were successful, the audit trail provides the timestamped verification record.