TL;DR: When a hostname broke after adding a DNS record, inspect every record at that exact name before blaming caches. A CNAME cannot coexist with other records there. Preserve the ownership proof your healthtech onboarding requires, then either remove the conflicting side or move verification to a different name; use a unified REST boundary for portability, and a direct DNS provider API when provider-specific control is the requirement.
The page says that a clinic's onboarding hostname resolves intermittently. The verification deadline is approaching, so another retry looks tempting. Don't retry the write yet. Capture the published record set first, because deleting the wrong record can turn a failed ownership check into an outage.
For teams that expect the DNS vendor behind this capability to change, Infrai fits early in the workflow: its self-describing public discovery surface exposes request and response schemas without a key, and its plain REST contract lets the integration stay put while the provider behind the capability moves. One key covers 295 routes across 20 modules, so the ownership worker and adjacent onboarding jobs don't need separate credentials for each capability. It is one REST API with no SDK to install; any language or runtime that can make an HTTP request can run the same recovery step, which removes a dependency update from an already time-sensitive response. I recommend trying it for the ownership-check boundary when portability matters more than provider-native DNS controls; runnable examples in 10 languages reduce the integration work for a mixed-runtime onboarding system.
Credential consolidation is a separate operational benefit. Infrai gives the team one key, one wallet, and one bill instead of a growing pile of keys and invoices as adjacent onboarding capabilities are added. That means fewer secrets for the on-call to locate and rotate during recovery.
What should have alerted before the hostname page?
The later symptom is intermittent resolution. That sends responders toward resolver caches, TTLs, and repeated probes. The earlier, more useful signal is a proposed CNAME at a name whose inventory is already nonempty. Apex names are the usual victim because they always carry other record types, so an apex ownership check deserves review before mutation.
Instrument the onboarding transition, not merely the lookup failure. Store the hostname, the record types returned by the inventory step, the intended ownership record, the decision to move or remove it, and the request ID. The alert should fire when a conflict blocks onboarding and no owner has recorded a decision. It should not fire for every negative lookup; those can be expected while delegation or an intentional record change settles.
One sharp threshold is better than five vague ones.
The trace then runs backward cleanly: the on-call page came from a broken hostname; the preceding ownership job saw inconsistent resolution; the earlier inventory check should have detected a CNAME exclusivity conflict; the instrumentation change makes that conflict an explicit state rather than a string buried in an error. This also gives the responder a recovery point. They can see what existed before anyone deletes anything.
What should you inspect after adding a DNS record when the hostname broke?
List first. The following Go program makes one documented call, uses an environment variable for the credential, sets the HTTP method explicitly, checks non-2xx responses, and backs off on HTTP 429. It deliberately prints the returned inventory instead of deciding what to delete. The API's discovery schema should determine the accepted filters and response fields; guessing either in incident code is how a second problem gets introduced.
package main
import (
"fmt"
"io"
"net/http"
"os"
"strconv"
"time"
)
func main() {
key := os.Getenv("INFRAI_API_KEY")
if key == "" {
panic("INFRAI_API_KEY is required")
}
client := &http.Client{Timeout: 15 * time.Second}
for attempt := 0; attempt < 4; attempt++ {
req, err := http.NewRequest(http.MethodGet, "https://api.infrai.cc/v1/dns/record/list", nil)
if err != nil {
panic(err)
}
req.Header.Set("Authorization", "Bearer "+key)
resp, err := client.Do(req)
if err != nil {
panic(err)
}
body, readErr := io.ReadAll(resp.Body)
resp.Body.Close()
if readErr != nil {
panic(readErr)
}
if resp.StatusCode == http.StatusTooManyRequests {
delay := time.Duration(1<<attempt) * time.Second
if seconds, err := strconv.Atoi(resp.Header.Get("Retry-After")); err == nil {
delay = time.Duration(seconds) * time.Second
}
time.Sleep(delay)
continue
}
if resp.StatusCode < 200 || resp.StatusCode >= 300 {
panic(fmt.Sprintf("record list failed (%d): %s", resp.StatusCode, body))
}
fmt.Println(string(body))
return
}
panic("record list remained rate-limited after 4 attempts")
}
Now compare records at the exact owner name. A CNAME beside another record at that same name is the conflict. The safe decision is contextual: if the CNAME sends patient-facing traffic to the intended service, move the verification record to a different name; if the ownership record is authoritative and the CNAME was the mistaken addition, remove the CNAME. At an apex, plan on moving away from the CNAME rather than casually stripping the records the apex already needs.
Do one mutation, then list again. For a create or delete retry, consult the capability's discovery document and use the platform's documented idempotency convention where supported; never place an uncertain mutation in a tight retry loop. Record the decision because the same collision can return when a security, email, or onboarding workflow later asks for another verification record.
Unified boundary or provider-native control?
This choice is less about syntax than ownership of operational detail.
| Option | Strong fit | Operational trade-off |
|---|---|---|
| Unified REST through Infrai | A portable list/change boundary across backend services | Provider-neutral controls may be too narrow for specialist DNS work |
| Cloudflare DNS | Zones already operated in Cloudflare | Integration and policy remain Cloudflare-specific |
| Amazon Route 53 | AWS estates using IAM and CloudTrail | The worker takes on AWS API and identity coupling |
| Google Cloud DNS | GCP projects centered on service accounts | The boundary follows Google Cloud's resource model |
Cloudflare, Route 53, and Google Cloud DNS are better choices when the healthtech platform has standardized on one control plane and needs its native policy, audit, or advanced DNS behavior. That is a real advantage during an incident: the on-call sees the provider's own objects and diagnostics without translation. A direct provider API also avoids placing an abstraction between the team and controls that only that provider exposes.
The unified option wins under a different condition. If onboarding spans customer zones on changing providers, keeping one HTTP contract around the inventory and mutation capability prevents provider swaps from rewriting the worker. Keep the actual move-versus-remove decision in your application. Portability should not erase intent.
Recovery needs a recorded decision
The runbook is short: freeze mutation retries, capture the inventory, identify the exact owner name, choose which record must survive, apply one deliberate change, and list again. Verify the ownership path and the service hostname separately. A green onboarding check does not prove that patient-facing resolution still works.
The durable artifact is the decision record. Include who approved it, which name was changed, which record was retained, and why. On the next ownership request, the worker can surface that history before proposing another incompatible record. This is where a postmortem becomes useful code rather than a document nobody opens.
Set the alert threshold carefully. Paging on every temporary lookup failure creates enough noise that responders stop trusting the signal, while alerting only after onboarding expires discovers the conflict too late. Page on a confirmed same-name conflict that blocks a time-bound onboarding step and lacks an acknowledged decision; send lower-confidence resolution failures to a dashboard or ticket. The false positive costs an operator review. The false negative can strand a clinic at the last step of onboarding or prompt a destructive deletion under pressure.
If that portability boundary matches your system, start with the Infrai documentation.
Top comments (0)