Registrars, Third-Party Domains and Hybrid DNS

By the end of this lesson you will be able to

• Tell a domain registrar from a DNS service, and explain why the two can be different companies.
• Register a domain in Route 53 and know what it sets up for you: the hosted zone, the yearly fee, auto-renew, the transfer lock and privacy protection; and know the basics of transferring a domain in or out.
• Make Route 53 the DNS service for a domain bought at GoDaddy or Namecheap, in the right order, and migrate a live domain without downtime.
• Diagnose the classic delegation mistakes: name servers switched before the records exist, old name servers still cached, a recreated hosted zone, a half-updated NS list, and an old DS record left at the registrar.
• Explain what the VPC Resolver answers on its own, and how inbound endpoints, outbound endpoints and forwarding rules connect it with DNS servers in your data centre.
• Answer the exam’s hybrid DNS questions: endpoints, rules, security groups, AZs, connectivity, sharing with AWS RAM, and the newer side features (DNS Firewall, query logging, Profiles, Global Resolver).

#Registrar and DNS service: two different jobs

When people say “I bought a domain”, two separate services are involved, and the exam likes to check that you can tell them apart.

• A domain registrar is the shop where you rent the name, usually by the year: GoDaddy, Namecheap, Cloudflare, or Amazon Route 53 itself (through Amazon Registrar, or its associate Gandi for some TLDs). The registrar records you as the owner with the registry of the TLD (for example Verisign for .com) and tells that registry which name servers answer for your domain.
• A DNS service runs those authoritative name servers and holds the hosted zone with your records: A, AAAA, MX, TXT, CNAME and so on. It is the part that actually answers “what is the IP of www.example.com?”.

Almost every registrar also offers a free basic DNS service, so beginners often think the two are one thing. They are not: you can buy the name at GoDaddy and let Route 53 manage the DNS records. The only link between them is the NS records that the registrar publishes in the parent TLD zone.

For the general picture of registries, registrars and DNS hosts, see the System Design lesson DNS. Here we focus on what Route 53 adds and what the exam asks.

#Registering a domain in Route 53

Route 53 is a registrar as well as a DNS service. In the console you go to Domains → Registered domains → Register domains, search for a name, choose the number of years and auto-renew, enter the contacts and pay. What happens then:

• A public hosted zone is created automatically for the domain, and the domain’s name servers are set to that zone’s four name servers. Nothing to copy, so nothing to get wrong. The hosted zone costs 0.50 USD a month on top of the registration (deleting it within 12 hours of registering avoids that charge).
• An annual fee per TLD. Prices differ by TLD and change every year (a .com went from 15 to 16 USD a year on 1 July 2026: check the current Route 53 domain price list). Registrations and renewals are not refundable, AWS credits cannot pay them, and a registered name cannot be changed later.
• Auto-renew renews the domain shortly before it expires. Leave it on for anything in production: an expired domain stops resolving, and after the grace period someone else can register it.
• Transfer lock (clientTransferProhibited in WHOIS) stops anyone from moving the domain to another registrar without your permission. Keep it on unless you are transferring.
• Privacy protection hides the owner’s contact details from public WHOIS lookups (where the TLD allows it).
• E-mail verification. ICANN rules require the registrant to click a link in a verification e-mail; otherwise the domain is suspended and stops resolving.
• A new account can register 20 domains by default (a quota you can raise).

One trap from the AWS documentation: do not use a domain registered in an AWS account as the e-mail domain of that same account’s root user. If the account is closed or suspended, the domain is suspended too, the root user can no longer receive the password-reset e-mail, and you cannot recover either.

Transferring a registration (briefly; the exam rarely goes deeper):

• Into Route 53: the domain must have been registered or transferred at least 60 days ago, it must be unlocked at the current registrar, and you get an authorization code from that registrar and enter it in Route 53. Remove any DNSSEC DS record first. A transfer usually takes up to 7 days for generic TLDs and up to 10 for country-code TLDs, and for most TLDs it adds one year to the registration.
• Move DNS first. Some registrars switch off their free DNS the moment a transfer starts. Make Route 53 (or another provider) the DNS service before you transfer the registration, so the website keeps resolving.
• Out of Route 53: turn off the transfer lock, get the authorization code from the Route 53 console, and start the transfer at the new registrar.

Transferring the registration and changing the DNS service are independent: you can do either one without the other.

#Using a third-party registrar with Route 53

The owner’s notes describe the most common real-world case: you bought the domain at GoDaddy or Namecheap, but you want Route 53 to manage it, for Alias records, routing policies and health checks (lessons 8.2 to 8.4). You do not transfer anything. You only change where the TLD sends DNS queries.

1. 1. Create a public hosted zone

   In Route 53, create a public hosted zone with exactly the same name as the domain, for example example.com. Route 53 automatically adds an SOA record and an NS record that lists the four name servers assigned to this zone. Do not delete or edit those two records, and do not add other NS records at the apex.

2. 2. Note the four name servers

   They look like ns-203.awsdns-25.com, ns-718.awsdns-24.net, ns-1361.awsdns-42.org and ns-1820.awsdns-35.co.uk: one each under .com, .net, .org and .co.uk. That is deliberate. Each lives under a different TLD, so even an outage of one TLD’s own servers leaves three working paths to your zone. Every hosted zone gets its own set of four (its delegation set).

3. 3. Create the records first

   Recreate every record that the old DNS service had: website, www, MX for mail, TXT for SPF and verification, any CNAMEs. If the old provider can export a zone file, import it into the hosted zone. This must be done before step 4.

4. 4. Replace the name servers at the registrar

   In the GoDaddy or Namecheap dashboard, choose custom name servers, delete the registrar’s defaults and enter all four Route 53 name servers, and nothing else. The registrar passes the change to the TLD registry.

5. 5. Wait for caches, then check

   The registry usually publishes the new NS within minutes, but resolvers keep the old delegation until its TTL runs out. For .com that TTL is 172,800 seconds (2 days), which is where the old “up to 48 hours” warning comes from. Check with dig NS example.com +trace that the TLD now hands out the awsdns servers.

#Migrating a live domain without downtime

Steps 1 to 5 are enough for a new domain. For a domain that already serves a website and e-mail, add the TTL care you learnt in lesson 8.1 (Records, Hosted Zones and TTL). The order AWS recommends:

1. Get the current configuration (a zone file or a list of records) from the old DNS provider.
2. Create the hosted zone and all records in Route 53. Nothing has changed for users yet.
3. Lower the TTL of the NS record, both at the old provider and in the Route 53 hosted zone, to 60–900 seconds.
4. If the domain uses DNSSEC, remove the DS record from the parent zone (at the registrar). Two providers cannot sign the same zone at once.
5. Wait for the old TTL to expire: two days for a typical NS TTL of 172,800 seconds.
6. Replace the name servers at the registrar with the four Route 53 ones.
7. Monitor website and mail traffic. If something breaks, put the old name servers back: thanks to the short TTL, most users follow within minutes.
8. Raise the NS TTL again (AWS suggests 172,800 seconds), keep the old provider’s zone until no one uses it, and optionally re-enable DNSSEC in Route 53 and add the new DS record.
9. Optionally, transfer the registration to Route 53 as well.

#What goes wrong

Play with each case:

#Hybrid DNS with the Route 53 VPC Resolver

Now the second half of the notes. Many companies run part of their systems in a data centre (on-premises) and part in AWS VPCs, joined by a private connection. Servers on each side need to find names on the other side:

• AWS → on-premises: an EC2 instance must reach web.corp.internal, which only the company’s own DNS servers (often Active Directory DNS) know.
• On-premises → AWS: a server in the data centre must reach app.aws.internal, a record in a Route 53 private hosted zone that only VPCs can see.

Resolving names between the two worlds is called hybrid DNS, and on AWS it is done with Route 53 Resolver endpoints.

#What the VPC Resolver answers on its own

Every VPC has a built-in DNS resolver, the one lesson 3 called the Amazon-provided DNS server. It listens at the VPC base address + 2 (10.0.0.2 in a 10.0.0.0/16 VPC), and also at 169.254.169.253 and, for IPv6, fd00:ec2::253. Instances use it by default through the VPC’s DHCP options, and it needs the VPC attribute enableDnsSupport (on by default). With no configuration at all it answers:

1. Local VPC names of EC2 instances, such as ip-10-0-1-30.ec2.internal or ec2-192-0-2-44.compute-1.amazonaws.com.
2. Records in private hosted zones associated with the VPC.
3. Public internet names, by doing the full recursive lookup itself from AWS public addresses (so private subnets need no NAT gateway for DNS).

What it does not know is anything that exists only in your data centre, and servers in the data centre cannot use it either, because it is reachable only from inside the VPC.

#Connectivity first: Site-to-Site VPN or Direct Connect

Endpoints carry DNS queries, not the network itself. Your data centre and the VPC must already be connected privately:

• AWS Site-to-Site VPN: an encrypted IPsec tunnel over the internet between your router and the VPC. Quick to set up, cheap, bandwidth limited by the internet.
• AWS Direct Connect (DX): a dedicated private line from your data centre to AWS. Steady latency and high bandwidth, but takes weeks to set up.

Both get their own chapter later. For this lesson: without a VPN or DX connection, hybrid DNS cannot work (an outbound endpoint can also reach DNS servers through a NAT gateway, but on-premises resolvers can reach an inbound endpoint only through a private connection).

#Inbound endpoint: the data centre asks AWS

An inbound endpoint lets DNS resolvers on your network forward queries into your VPC. It is a set of elastic network interfaces (ENIs) that Route 53 creates in subnets you choose, each with a private IP address.

1. A server in the data centre asks its usual company DNS server for app.aws.internal.
2. That DNS server has a conditional forwarder: “send aws.internal to 10.0.1.10 and 10.0.2.10”, the endpoint’s IP addresses.
3. The query crosses the VPN or DX link, reaches an endpoint ENI, and the VPC Resolver answers it from the private hosted zone, exactly as it would for an instance in that VPC.

Requirements to remember: the private hosted zone must be associated with the VPC that holds the inbound endpoint; the endpoint’s security group must allow inbound TCP and UDP port 53 from the on-premises resolvers; and the on-premises forwarder should list every endpoint IP, so it can fail over between AZs. Forwarding from on-premises straight to the VPC +2 address is not supported.

#Outbound endpoint and forwarding rules: AWS asks the data centre

An outbound endpoint lets the VPC Resolver forward selected queries out to DNS resolvers on your network. It has two parts:

• The outbound endpoint itself: ENIs in your VPC that the forwarded queries leave from. Its security group must allow outbound TCP and UDP 53 to the target resolvers, and the on-premises firewalls must accept the ENIs’ IP addresses.
• Resolver rules, which say which domains go where. A forwarding rule (conditional forwarding rule) such as “corp.internal → 10.20.0.53, 10.20.1.53 through outbound endpoint X” applies to the domain and all its subdomains. A rule works only in the VPCs you associate it with.

Rule types you should recognise:

When several rules match, the most specific one wins (the one with the most labels): for db.dev.corp.internal, a rule for dev.corp.internal beats one for corp.internal. When a forwarding rule and a private hosted zone have exactly the same name, the rule wins and the query goes on-premises. Rules match whole labels: xcorp.internal does not match a rule for corp.internal.

Try the matching yourself:

#Endpoint facts the exam and production care about

• ENIs in at least two AZs. Every endpoint needs at least two IP addresses, and you should put them in different Availability Zones. The default quota is 6 IP addresses per endpoint, and 4 endpoints per Region per account (both raisable).
• Capacity. Each IP address handles up to 10,000 UDP queries per second (much less with tracked connections, slow targets or TCP). AWS advises adding IP addresses when any one goes above 50% of that. Add IPs to an existing endpoint rather than creating more endpoints.
• Regional. Endpoints and rules belong to one Region and serve VPCs in that Region. One inbound and one outbound endpoint per Region is usually enough; both can live in the same VPC.
• Protocols. Plain DNS on port 53 (Do53), and DNS over HTTPS (DoH) for endpoints that must encrypt queries.
• Cost. About 0.125 USD per ENI per hour, plus 0.40 USD per million queries through endpoints (first billion a month). An endpoint with the minimum two ENIs costs about 2 × 0.125 × 730 ≈ 182.50 USD a month before queries.
• Sharing with AWS RAM. You can share Resolver rules with other accounts (or a whole organization) through AWS Resource Access Manager. Each account associates the shared rule with its own VPCs, and the queries leave through the one outbound endpoint named in the rule. The common pattern: a central networking account owns the endpoints and rules; every application account uses them.

#Side notes: newer Resolver features (2021–2026)

Verified in the Route 53 Developer Guide; the exam mostly asks about the first two.

• Resolver DNS Firewall filters the outbound DNS queries that instances send through the VPC Resolver. You build rule groups with domain lists (your own, or AWS managed lists of malware and botnet domains) and actions allow, block or alert, and associate them with VPCs; AWS Firewall Manager can push them across an organization. Its main job is stopping DNS exfiltration, where malware leaks data inside DNS queries to a domain the attacker controls. Exam keyword: “block instances from resolving malicious domains” → DNS Firewall.
• Resolver query logging records the queries from your VPCs, from inbound endpoints and through outbound endpoints, plus DNS Firewall actions, and sends them to CloudWatch Logs, S3 or Firehose; configurations can be shared with AWS RAM. Do not confuse it with public DNS query logging for a public hosted zone, which logs queries that reach Route 53’s name servers.
• Route 53 Profiles (2024) bundle private hosted zone associations, Resolver rules, DNS Firewall rule groups, query logging configurations and interface VPC endpoints, and apply the bundle to many VPCs and accounts at once (shared through AWS RAM; one Profile per VPC). When you would otherwise associate dozens of zones and rules with hundreds of VPCs, a Profile is simpler.
• Route 53 Global Resolver (preview November 2025, generally available March 2026) is an internet-reachable anycast resolver for your authorized clients anywhere, for example laptops and branch offices without a VPN. It resolves public names and your private hosted zones, with DNS filtering and central logging. It is new and not yet on the exam; hybrid DNS questions still mean VPC Resolver endpoints.
• Delegation inbound endpoints and rules (recent) let a subdomain be delegated between the VPC Resolver and on-premises resolvers instead of forwarded.

#Registrars and hybrid DNS in system design

• Register production domains in an account you control well, with auto-renew and the transfer lock on, and the registrant e-mail on an address that does not depend on the same domain. Losing a domain is one of the longest outages a company can have.
• Keep registrar and DNS separate when it helps: many companies register at one place and host DNS in Route 53 for Alias records, health checks and routing policies. What matters is the NS delegation, so automate checks that the registrar’s NS equals the hosted zone’s.
• Treat a hosted zone as long-lived. Never delete and recreate a production zone; if zones are created by code, use a reusable delegation set.
• Change delegation like a deployment: lower TTLs, have a rollback plan (the old name servers), monitor, then raise TTLs.
• Hybrid DNS hub: put the inbound and outbound endpoints in a central networking VPC in each Region, connected to the data centre over two VPN tunnels or Direct Connect links, share the forwarding rules with AWS RAM, and associate private hosted zones with that hub VPC. Use endpoint IPs in at least two AZs and watch the endpoint CloudWatch metrics.
• Security: turn on query logging and DNS Firewall in every VPC; they are cheap compared with the incidents they help explain.

#Try it yourself

Check a delegation from your own machine:

# Who is authoritative for the domain right now? (follows root → TLD → authoritative)
dig NS example.com +trace

# Ask the .com servers directly what they publish for the domain, and the TTL
dig NS example.com @a.gtld-servers.net +norecurse

# Ask one of the zone's own name servers (bypasses every cache)
dig www.example.com A @ns-203.awsdns-25.com

# Windows equivalent
nslookup -type=NS example.com

Route 53 side (domain commands only work in us-east-1):

# Create a public hosted zone and print its four name servers
aws route53 create-hosted-zone --name example.com --caller-reference "$(date +%s)"
aws route53 get-hosted-zone --id Z0123456789EXAMPLE --query "DelegationSet.NameServers"

# A reusable delegation set: zones created with it keep the same four name servers
aws route53 create-reusable-delegation-set --caller-reference "rds-$(date +%s)"

# Register a domain in Route 53, or point a Route 53-registered domain at other name servers
aws route53domains check-domain-availability --domain-name example.org --region us-east-1
aws route53domains update-domain-nameservers --domain-name example.org --region us-east-1 \
  --nameservers Name=ns-203.awsdns-25.com Name=ns-718.awsdns-24.net \
                Name=ns-1361.awsdns-42.org Name=ns-1820.awsdns-35.co.uk
aws route53domains enable-domain-transfer-lock --domain-name example.org --region us-east-1
aws route53domains enable-domain-auto-renew --domain-name example.org --region us-east-1

Hybrid DNS (the security groups must allow TCP and UDP 53):

# Inbound endpoint: two IPs in two AZs
aws route53resolver create-resolver-endpoint --name onprem-to-aws --direction INBOUND \
  --creator-request-id in-001 --security-group-ids sg-0dns0123456789abc \
  --ip-addresses SubnetId=subnet-0aaa1111,Ip=10.0.1.10 SubnetId=subnet-0bbb2222,Ip=10.0.2.10

# Outbound endpoint
aws route53resolver create-resolver-endpoint --name aws-to-onprem --direction OUTBOUND \
  --creator-request-id out-001 --security-group-ids sg-0dns0123456789abc \
  --ip-addresses SubnetId=subnet-0aaa1111 SubnetId=subnet-0bbb2222

# Forwarding rule for corp.internal, then associate it with a VPC
aws route53resolver create-resolver-rule --name corp --rule-type FORWARD \
  --domain-name corp.internal --resolver-endpoint-id rslvr-out-0123456789abcdef \
  --target-ips Ip=10.20.0.53,Port=53 Ip=10.20.1.53,Port=53 --creator-request-id rule-001
aws route53resolver associate-resolver-rule --resolver-rule-id rslvr-rr-0123456789abcdef \
  --vpc-id vpc-0123456789abcdef0

# Share the rule with the whole organization through AWS RAM
aws ram create-resource-share --name dns-rules \
  --resource-arns arn:aws:route53resolver:us-east-1:111122223333:resolver-rule/rslvr-rr-0123456789abcdef \
  --principals arn:aws:organizations::111122223333:organization/o-exampleorgid

# From an EC2 instance: does the forwarded name resolve?
dig web.corp.internal

#Summary

Key takeaways

• Registrar ≠ DNS service. The registrar rents you the name yearly and tells the TLD your name servers; the DNS service hosts the zone and answers queries. They can be different companies, joined only by the NS delegation.
• Registering in Route 53 creates the public hosted zone automatically and sets its name servers; you pay a yearly fee per TLD plus 0.50 USD a month for the zone. Keep auto-renew, the transfer lock and privacy protection on. Transfers need 60 days, an unlocked domain and an authorization code; move DNS first.
• Third-party registrar + Route 53: create a public hosted zone, create all records, then replace the registrar’s name servers with the zone’s four awsdns servers (spread over .com, .net, .org and .co.uk on purpose). Resolvers follow after the old NS TTL, 2 days for .com.
• Migrate safely: copy records, lower the NS TTL, remove the DNSSEC DS record, wait, switch, monitor, raise the TTL. Classic failures: records missing (NXDOMAIN), old NS cached, zone recreated with new name servers (SERVFAIL), mixed NS, old DS left behind.
• The VPC Resolver (VPC base +2, 169.254.169.253) answers EC2 names, private hosted zones and public names by itself, but knows nothing on-premises and cannot be reached from outside.
• Inbound endpoint: on-premises resolvers forward to ENIs in your VPC to resolve AWS private names. Outbound endpoint + forwarding rules: the VPC Resolver forwards chosen domains to on-premises DNS. Rules must be associated with the VPC; the most specific match wins; no match means a public lookup.
• Endpoints are ENIs in at least two AZs with security groups (TCP and UDP 53), need Direct Connect or Site-to-Site VPN, cost about 0.125 USD per ENI-hour, and rules can be shared with AWS RAM.
• Exam trick: hybrid DNS → Route 53 Resolver inbound/outbound endpoints. Extras: DNS Firewall (block malicious domains), query logging, Profiles (many VPCs and accounts), Global Resolver (new, not yet on the exam).

Self-check: registrars and hybrid DNS30 questions