Cloud DNS Renewal: Match Every Hosted Zone and Record to a Live Service Owner

A hosted zone can exist in a cloud account, show healthy name servers, contain hundreds of records, and still do absolutely nothing for the live business.

Another zone with the same name may be the one answering customer requests. A delegated subdomain may sit in a different provider. An old record may point at a service nobody owns. The invoice will not explain any of this.

Do not renew managed DNS from the provider’s zone count or last month’s query total. Match every hosted zone and important record to the public delegation, a live business service, an accountable owner, a tested change path, and a deliberate renewal decision.

If the team cannot do that, renewing the platform also renews the mystery.

Build the inventory from four different views

Start with four lists:

Every hosted zone in every DNS account, tenant, subscription, project, managed service, and acquired environment.
The name-server delegation published by each parent domain or parent zone.
The answers returned by the authoritative DNS service for important names.
The applications, mail systems, APIs, identity services, websites, certificates, vendors, and network services the business still uses.

None of those lists is complete by itself.

Create one row per hosted zone. Record the domain or subdomain, public or private status, provider, account, zone identifier, parent delegation, name servers, business owner, technical owner, administrator group, record count, query activity, DNSSEC status, health checks, traffic policies, contract line, cost, and proposed decision.

Do not group duplicate zone names into one row. Microsoft documents that the same Azure DNS zone name can exist in different resource groups or subscriptions, while only one set of name-server addresses can be configured at the registrar. Similar duplicates can appear during migrations, testing, acquisitions, and failed cutovers.

A zone in a portal is not proof that anyone uses it.

Prove which zone is authoritative

For every public domain, compare the parent delegation with the name servers assigned to the hosted zone. Then query those authoritative servers directly for the zone’s SOA and important records.

CISA’s DNS infrastructure guidance tells organizations to verify that public NS records delegate to the intended DNS servers and that records on authoritative and secondary servers resolve to the intended destination. That is a good renewal test because it compares configuration with reality.

Classify each zone:

Status	What it means	Next action
Live and delegated	The parent points to this zone and authoritative answers support current services	Validate ownership, controls, resilience, usage, and cost
Shadow duplicate	The zone exists but the parent does not delegate to it	Confirm whether it is a migration copy, recovery asset, test zone, or waste
Partially delegated	A child zone or service uses it, but ownership or scope is unclear	Trace the delegation and assign an owner
Stale delegation	The parent still points to infrastructure that is wrong, abandoned, or no longer controlled	Treat it as a risk and correct it through controlled change
Unknown	The evidence conflicts or nobody can explain the zone	Investigate before changing or renewing it

Unknown does not mean unused. It means the company has not earned the right to delete it yet.

Keep registration and authoritative DNS separate in the review. The domain registrar renewal audit covers ownership, expiration, transfer, and account recovery. This review covers the zones and records that answer once the DNS hierarchy reaches your provider.

Match important records to live services

A clean zone inventory still leaves the record problem.

Export the records and group them by the service they support. Start with A and AAAA records, CNAMEs, MX records, TXT records used for email or verification, SRV records, CAA records, NS delegations, and any alias or provider-specific routing records.

For each important record, capture:

The business service and technical dependency
The application or service owner
The target resource and the account that controls it
The change owner and approval path
The expected response and test method
The TTL and why it fits the operating need
The last meaningful change
Monitoring, certificate, mail, or security dependencies
The retirement condition

Pay special attention to records that point outside the organization. Marketing platforms, SaaS products, agencies, contact centers, ecommerce tools, customer portals, cloud load balancers, content delivery networks, and old project environments can all leave targets behind.

NIST’s current Secure Domain Name System Deployment Guide warns that stale CNAME records and stale name-server delegations can let another party take control of resolution. It recommends regular review and removal of CNAME records that are no longer required. It also says administrators should validate delegations and use a deletion process that removes both delegation information and zone data.

Do not delete a suspicious record because the target looks dead. Find the business owner, check traffic and service evidence, review certificates and application configuration, test in a controlled window, and define rollback.

The record nobody recognizes may be useless. It may also be the forgotten callback that closes a sale.

Review access like a production control plane

DNS changes can redirect websites, mail, APIs, authentication, certificate validation, and vendor integrations. The administration path deserves more scrutiny than a generic SaaS renewal.

List every person, group, service account, API key, automation identity, managed-service user, and emergency account that can create or change records. Compare that list with the current team, identity provider, privileged-access process, infrastructure code, CI/CD workflows, and support agreement.

Ask:

Does every administrator still need the role?
Can a vendor change records without customer approval?
Are automation credentials scoped, rotated, and monitored?
Does the platform log record, policy, DNSSEC, and delegation changes?
Can the team export those logs to a system it controls?
Are production changes reviewed and tied to a ticket or deployment?
Can two current employees regain control if the primary administrator leaves?
Does emergency access still work if the main identity platform is unavailable?

Test resilience instead of buying the label

“Global DNS” and “high availability” sound reassuring. Buyers still need to understand what the service protects and what remains theirs to operate.

NIST says DNS is mission-critical and should be regularly assessed. Its current guide recommends resilient authoritative service, including network and geographic dispersion. A managed cloud provider may handle replication and server placement, but the customer still owns the zone data, delegation, access model, change quality, dependencies, and recovery plan.

Run controlled tests for the failures that matter:

Query each assigned authoritative name server and compare important answers.
Test from more than one external network and geographic location.
Verify monitoring detects a wrong or missing answer rather than stopping at provider uptime.
Confirm secondary services, health checks, or traffic policies behave as designed.
Restore a known zone export into a safe test environment.
Walk through an urgent record change when the normal administrator is unavailable.
If DNSSEC is enabled, test the signing, delegation, rollover, and recovery process.

DNSSEC protects the integrity and authenticity of DNS data. It does not make bad records correct. Name the key owner, rollover method, monitoring, failure response, and migration sequence.

Use the network monitoring renewal audit to verify who receives DNS availability alerts and what action they take. A red dashboard nobody owns is not resilience.

Rebuild the price from the operating design

Managed DNS cost may include hosted zones, query volume, routing policies, health checks, private resolvers, logging, DNSSEC features, premium support, managed changes, professional services, and traffic-management products.

Reconcile the renewal quote with actual configuration and invoices. Separate:

Live public zones from private zones and shadow duplicates
Normal query volume from unexplained spikes
Standard records from advanced routing or health-check features
Provider service from MSP administration
Included support from project work
Current operating cost from migration and exit cost

Do not chase a tiny zone charge while ignoring the labor and risk behind it. A second provider may improve resilience, or it may create two control planes that drift because nobody owns synchronization. Price the design the company can operate correctly.

Make migration and retirement prove themselves

Before renewing, export a zone in a usable format and import it into a safe test account or alternate service. Confirm what does and does not travel. Provider-specific alias records, health checks, traffic policies, DNSSEC settings, access roles, logs, and monitoring may require separate work.

For a migration, document the source and target zones, record comparison, name-server change, TTL plan, DNSSEC sequence, validation queries, freeze window, owners, communication, rollback criteria, and observation period. Do not combine a registrar transfer, authoritative DNS migration, certificate change, mail change, and application cutover unless the business has a very good reason to accept that much ambiguity at once.

For retirement, remove the service dependency first. Then monitor, remove the record, monitor again, remove child delegation where applicable, and finally remove the hosted zone when the evidence says it is safe.

NIST specifically warns that deleting a hosted zone while leaving its original delegation in place can create a hijacking opportunity. Retirement needs a sequence, not a delete button.

Put one decision on every zone

Renew zones that are live, owned, controlled, tested, priced correctly, and tied to current services.

Correct zones with stale records, weak access, unclear ownership, missing monitoring, broken resilience, or contract scope that does not match the operating design.

Consolidate when fewer platforms or accounts improve control without creating a fragile administrative or availability dependency.

Migrate when another provider or service model materially improves control, resilience, support, portability, or cost, and the team has tested the move.

Retire zones and records only after the dependency, delegation, monitoring, and rollback work is complete.

Investigate anything the evidence cannot explain. Give it an owner and deadline so it does not return as the same mystery next year.

If your managed DNS, cloud, domain, MSP, or network agreement is approaching renewal, request a Contract and Spend Risk Review. Bring the agreement, renewal quote, hosted-zone and record exports, registrar delegation data, account and role lists, query and cost reports, change logs, incident history, resilience tests, invoices, and notice dates. Catch Advisors will help you decide what to renew, correct, consolidate, migrate, retire, or investigate before the current term makes the choice for you.