Route 53 DNS Setup and Design | Cloud DevOps Solutions

Route 53 and Azure DNS Setup: Hosted Zones, Delegation and Safe Record Management

DNS setup decides who controls your domain and how services find each other. We create public and private hosted zones in Route 53 or Azure DNS, delegate subdomains to the right accounts, manage records as code, secure the registrar, and add health checks and certificate validation where needed.

Key takeaways

Your domain registrar login is as sensitive as your cloud root account, since whoever controls DNS controls your traffic and email.

Delegating subdomains to workload accounts keeps teams autonomous without sharing a single powerful DNS account.

Private hosted zones give internal services stable names inside your VPCs.

Records managed in Terraform have history, review and rollback; records edited in a console do not.

Lower TTLs before planned migrations, and know what you will do if a record is wrong.

DNS is small, until it breaks

DNS is the part of the stack that nobody thinks about until a record is deleted and customers cannot reach the site, or a certificate fails to renew because a validation record vanished. It is also a favourite target of attackers: a hijacked domain redirects traffic, intercepts email and passes certificate checks.

Because of that, DNS is on the list in every cloud setup engagement. It touches networking, identity and certificates, so we design it alongside the VPC layout and the account structure.

Typical problems in inherited setups

The domain is registered under a former employee’s personal account.
Several zones exist for the same domain in different accounts, and nobody knows which is authoritative.
Records for decommissioned services still point to released IP addresses, which creates takeover risk.
Verification records for tools used years ago clutter the zone.
Every change is made by hand in the console, with no history.
Email records (SPF, DKIM, DMARC) are missing or contradictory.

A DNS inventory before any change is therefore essential, and it forms part of the ClickOps inventory.

What good looks like

The registrar account is owned by the company, has MFA and a registrar lock, and auto-renew is enabled.
There is one authoritative zone per domain, with delegation documented.
Production subdomains are delegated to workload accounts, or managed centrally if you prefer.
Internal names live in private hosted zones.
All records are defined in code.
Email authentication records are present and correct.
Dangling records are removed.

How it works in practice

Hosted zones and delegation

A public hosted zone in Route 53 gives you four nameservers. You set those at the registrar. For a multi-account organisation, a typical design is this: the apex zone, example.com, lives in a shared services account. Each environment has its own subdomain zone, such as prod.example.com, in the matching workload account. The parent zone contains NS records pointing at the child zone’s nameservers.

resource "aws_route53_zone" "prod" {
  provider = aws.prod
  name     = "prod.example.com"
}

resource "aws_route53_record" "prod_delegation" {
  provider = aws.shared
  zone_id  = aws_route53_zone.example.zone_id
  name     = "prod.example.com"
  type     = "NS"
  ttl      = 300
  records  = aws_route53_zone.prod.name_servers
}

The apparent complexity buys real safety: a team working in prod.example.com cannot alter the root records for the website or email.

Private zones and hybrid resolution

A private hosted zone is associated with one or more VPCs and resolves only there. Cross-account association needs an authorisation step, and in larger setups, shared Route 53 Resolver rules forward queries between VPCs and to on-premises resolvers. We keep naming predictable, for example service.environment.internal.example.com, so names are self-explanatory.

Records as code and Kubernetes

Static records belong in Terraform. In Kubernetes, dynamic records for ingresses and services are better handled by a controller such as external-dns, limited to a specific subdomain and zone so it cannot touch anything else. See our Kubernetes consulting pages for how that fits a cluster. The glossary entry for an ingress controller explains the traffic side.

Certificates

ACM certificates validated by DNS create a CNAME in the zone. If that record is removed, renewal fails silently until expiry. Managing validation records in Terraform stops accidental cleanup from breaking certificates.

Email authentication

SPF, DKIM and DMARC records decide whether your mail is trusted. We document each sending service, start DMARC in monitoring mode, and move to enforcement once reports show legitimate mail passes. This is often quietly neglected and has a direct business effect.

Health checks and routing

Route 53 offers weighted, latency, geolocation and failover routing, with health checks. These are useful for failover and gradual rollouts, but add behaviour that is hard to reason about during an incident. We use the simplest policy that meets the availability need, and test failover rather than assuming it works. For deeper resilience planning, see backup and disaster recovery.

Azure DNS

Azure DNS hosts public zones and, with Private DNS zones, internal names linked to virtual networks. Delegation works the same way. For private endpoints, Private DNS zones linked to the hub network are essential, and are a common source of confusing resolution failures in hub-and-spoke designs.

Migrating DNS without an outage

Moving a zone is routine when done in order. First export every existing record and compare it with what is actually in use, because old zones often hold stale entries nobody dares delete. Create the new hosted zone and load the records through code, then test the new name servers directly with dig @ns-example.awsdns.com app.example.com before touching the registrar. Lower TTLs a day or more ahead, so resolvers pick up the change quickly, then update the delegation at the registrar and watch queries move across. Keep the old zone alive for a while after the switch as a fallback, and only remove it once logs show no traffic still arriving there.

Decisions and trade-offs

Route 53, Cloudflare or the registrar’s DNS? Route 53 integrates tightly with IAM, ACM and VPCs. Cloudflare offers strong edge features and a good interface. Staying inside your cloud simplifies access control; using a separate provider adds independence from a single vendor. Choose deliberately.

DNSSEC. It protects against spoofed answers but adds operational risk, such as broken key rollovers. Worth it for high-value domains once you have monitoring in place.

Low or high TTLs. Low TTLs speed changes but raise query volume. We lower them before a planned migration and raise them afterwards.

When not to delegate. Small teams with one account are better served by a single zone and clear code review than by delegation they will not use.

Common failure modes

Registrar lapses. Expiry notices go to an unread mailbox.
Dangling CNAMEs pointing to deleted cloud resources, enabling subdomain takeover.
Duplicate zones where changes go to the wrong one.
Wrong zone edited on the day of a migration.
Automation with too much access letting a bug rewrite a production zone.

Delivery and handover

We provide a DNS inventory, a diagram of zones and delegation, Terraform for all zones and records, the email authentication settings and a procedure for adding a domain or subdomain. We also recommend restricting who can edit production zones in your SSO permission sets.

How to tell it is working

Every record is traceable to a commit.
No dangling records or orphaned zones remain.
Certificates renew without anyone noticing.
The registrar and zone owners are documented and reachable.
A planned migration happens with no customer-visible blip.

To audit your DNS and registrar setup, contact us.

References

How we deliver it

Inventory domains and records

We list registrars, nameservers, existing zones and records, including email, verification and legacy entries nobody remembers.

Secure the registrar

MFA, registrar lock, a company-owned account and auto-renew on, with contacts that are monitored mailboxes.

Design the zone layout

Decide the apex zone, which subdomains are delegated to which accounts, and where private zones live.

Create zones and delegation

Hosted zones are created, NS records delegated, and the registrar updated only after the zone is verified.

Codify records

Existing records are imported into Terraform and future changes flow through pull requests.

Add certificates and checks

ACM validation records, health checks and failover routing are configured where the design needs them.

Frequently asked questions

What is a Route 53 hosted zone?

A hosted zone is a container for the DNS records of a domain or subdomain. Public hosted zones answer queries from the internet, while private hosted zones answer only for associated VPCs. Each public zone is assigned four nameservers that you delegate to from your registrar.

Should we move our domain registration to AWS?

Not necessarily. You can host DNS in Route 53 while keeping registration elsewhere, simply by pointing nameservers at Route 53. Moving registration consolidates billing and access, but the priority is securing whichever registrar you use with MFA, locks and company ownership.

How should DNS work in a multi-account setup?

A common pattern keeps the root domain in a shared services account and delegates subdomains, such as prod.example.com, to workload accounts via NS records. Teams then manage their own records without access to the parent zone, and a mistake in one subdomain cannot break the others.

What is a private hosted zone used for?

It provides internal names such as db.internal.example.com that resolve only inside associated VPCs, which keeps internal addresses off the public internet and gives services stable names. Cross-account and hybrid setups also use Route 53 Resolver rules and endpoints to forward queries.

How do you avoid DNS outages during a migration?

Lower TTLs a day or two ahead, create and test the new records before switching, change one thing at a time and keep the old target alive until traffic drains. We also keep a rollback record ready, because a wrong DNS entry can take effect worldwide within its TTL.