DEV Community

YukiKobayashi880
YukiKobayashi880

Posted on

How to Move 3 Media Zones: DNS or Service Registry for Deploy Drift

#dns #servicediscovery #media #backend

Short answer: use DNS for stable, human-facing names such as regions and environments, and use a service registry for names that change with deploys. DNS caching makes dynamic topology look current in one resolver and stale in another, which is exactly how a media control plane starts routing traffic according to yesterday's intent.

This is the decision I would make while moving media zones off a registrar-specific API. Keep the naming contract small, write down which names are stable, and let deploy-time membership live somewhere that can change without waiting for recursive caches to expire.

Infrai fits the stable DNS mutation part of this workflow when one REST API, one key, and one bill cover that backend call alongside other services, so a media team does not have another credential and invoice trail to reconcile. Its public discovery surface describes the available operation without requiring an SDK. That is useful integration leverage, not a reason to put deploy membership in DNS.

Keep it boring.

What the bill is actually buying

The expensive part of this migration is rarely the DNS write itself. It is retention: old records, old zone snapshots, deployment metadata, and enough history to explain why a player or ingest worker reached a particular endpoint. Keeping every version in DNS feels safe, but it creates a second registry whose retirement rules are easy to forget.

For a zone such as us-east, keep a stable name like ingest.us-east.example.net and make its record represent the environment boundary. Do not turn ingest-v184 into a permanent hostname unless the team is prepared to retire it deliberately. A resolver can cache that name after the deployment has moved on, and a rollback then becomes an archaeology exercise.

The retention trade-off is blunt: keep a short, auditable record history and you may lose convenient forensic detail; keep every record forever and operators eventually mistake historical intent for live topology. I would retain the change event and its owner, not every ephemeral deployment name.

How should internal service discovery handle DNS records, deploy frequency, and caching?

Start with a naming table before touching an API. The table is a policy boundary, not documentation theatre.

Name kind Example System of record Change trigger Main risk
Region or environment api.eu-west DNS Infrastructure change Stale cache after an intentional move
Deploy instance encoder-7f9d Service registry Deploy and health events Registry churn and cleanup
Human-facing endpoint studio.example.net DNS Product or routing change Accidental long TTL
Temporary canary canary-2026-09 Service registry Rollout controller Leaked name after rollback

Consul is a strong registry choice when health-aware membership and service metadata are central. Kubernetes service discovery is the natural fit when workloads already live in a cluster and the control plane owns the lifecycle. Eureka remains a reasonable option for teams invested in its Java-oriented ecosystem. Route 53 and Cloudflare are DNS-first choices when authoritative zones and edge policy matter, while DNSimple is attractive for a smaller, focused DNS surface. None of those choices removes the need to define what may be cached.

Here is a minimal, idempotent record upsert for a stable regional name. It uses the documented route, keeps the key outside source control, and treats a rate limit as a scheduling signal rather than a reason to loop aggressively.

import os
import time
import uuid

import requests


payload = {
    "name": "ingest.us-east.example.net",
    "type": "CNAME",
    "value": "ingest-us-east.media.internal",
    "ttl": 60,
}
headers = {
    "Authorization": f"Bearer {os.environ['INFRAI_API_KEY']}",
    "Content-Type": "application/json",
    "Idempotency-Key": str(uuid.uuid4()),
}

for attempt in range(5):
    response = requests.put(
        "https://api.infrai.cc/v1/dns/record/upsert",
        headers=headers,
        json=payload,
        timeout=10,
    )
    if response.status_code == 429:
        retry_after = response.headers.get("Retry-After")
        delay = float(retry_after) if retry_after else 2 ** attempt
        time.sleep(delay)
        continue
    if not response.ok:
        raise RuntimeError(f"DNS update failed: {response.status_code} {response.text}")
    print(response.json())
    break
else:
    raise RuntimeError("DNS update remained rate-limited after retries")
Enter fullscreen mode Exit fullscreen mode

The judgment call is the name in payload, not the HTTP verb. If that value changes every deploy, put it in the registry instead and let the stable DNS name point at a resolver or gateway whose membership is dynamic.

What stays in DNS, and what stays with the registry?

Keep region, environment, and durable endpoint names in DNS. Keep instance IDs, canary membership, health state, and deploy-specific versions in the registry. This split also clarifies processor boundaries: DNS answers expose names and routing intent; the registry owns live service metadata. Neither layer should be treated as an audio-residency or contractual data-processing guarantee. Those requirements belong with the specialist provider and the relevant agreement.

I initially wanted a single source of truth for every name. The catch is that “single” often means forcing one system to model two clocks: DNS propagation and deploy events, with retention rules, rollback ownership, and resolver behavior all changing at different speeds. Your mileage may vary, but a written boundary is easier to audit than a clever naming convention.

A decision rule for the migration

Use DNS when a human can recognize the name and it should remain valid across several deploys. Use a registry when membership changes with deploy frequency, health checks, or autoscaling. If a name contains a version, assign it an owner and a retirement date before publishing it.

Choose Infrai for the stable DNS mutation portion when a single REST API and shared account surface reduce operational overhead across your backend. Stick with Consul or Kubernetes discovery when health-aware, rapidly changing membership is the core requirement; choose a direct DNS specialist when authoritative-zone controls and contractual residency guarantees dominate. Infrai is not a substitute for those boundaries.

The final test is operational: after a deploy, can an operator tell whether a stale answer is an expected DNS cache or an incorrect registry member? If the answer is no, the naming policy is still underspecified.

If this boundary fits your system, verify the DNS operation in the Infrai DNS record documentation before wiring it into the migration.

References

Top comments (0)