Cloud DNS Architecture

The VPC resolver

Every VPC has a built-in DNS resolver at a known address. Instances in the VPC use it by default. The resolver handles three kinds of queries:

1. Cloud-internal names — service endpoints, instance private DNS names, region-specific service hostnames.
2. Private hosted zones associated with this VPC.
3. Public internet names — recursed out to authoritative DNS via the cloud's resolver infrastructure.

The resolver does its lookups in that order; the first match wins. A name in a private hosted zone shadows any public DNS record for the same name.

Private hosted zones

A private zone is a DNS zone that resolves only inside VPCs you associate with it. Use cases:

• Internal service discovery. db.internal resolves to the database's private IP. Replicate the zone across multiple VPCs to share names.
• Naming private endpoints. The cloud auto-creates a private zone when you create a VPC endpoint, overriding the service's public hostname.
• Environment-specific overrides. Production VPC resolves config.example.com to one IP; staging VPC resolves the same name to a different IP — without any application changes.

Split-horizon DNS

The same domain name resolves to different values depending on the resolver consulted. Common pattern:

• Public DNS authoritative for example.com returns the load balancer's public IP for api.example.com.
• Private hosted zone for example.com associated with internal VPCs returns the internal load balancer's private IP for the same api.example.com.

Inside the VPC, API calls stay private. Outside, the same name reaches the public endpoint. Applications use the same hostname everywhere and don't need to know which side of the split they're on.

Hybrid DNS: cloud + on-prem

Most enterprises run DNS in both their cloud and on-prem environments. They need bidirectional resolution: cloud can resolve printer.corp.internal; on-prem can resolve api.aws.internal. The mechanism is conditional forwarding:

1. Inbound resolver endpoint in the VPC. A set of ENIs in your subnets that on-prem DNS can query for cloud-internal names.
2. Outbound resolver endpoint in the VPC. A set of ENIs that the VPC resolver can use to forward queries for on-prem domains.
3. Resolver rules: "for queries ending in corp.internal, forward to these on-prem DNS server IPs via the outbound endpoint."
4. On-prem side: "for queries ending in aws.internal, forward to the inbound endpoint IPs."

The two networks meet at the resolver endpoints; each forwards what it doesn't know to the other.

The DNS path for a typical query

An application on an EC2 instance resolves api.partner.com:

1. Instance's stub resolver queries the VPC resolver at 10.0.0.2 (or equivalent).
2. VPC resolver checks the cache. If hit, return.
3. VPC resolver checks private hosted zones associated with the VPC. If api.partner.com is in a private zone, return that.
4. VPC resolver checks resolver rules. If a rule matches (e.g., forward .partner.com to a specific on-prem DNS), forward via outbound endpoint.
5. Otherwise, recurse out to public DNS via the cloud's recursive resolver infrastructure.
6. Return the answer to the instance.

Common DNS bugs in cloud

• Instances using a non-VPC DNS server. Some images hardcode 8.8.8.8 in /etc/resolv.conf, bypassing the VPC resolver. Private hosted zones and resolver rules are ignored. Private endpoints don't work.
• Forgetting to associate the private zone with the VPC. The zone exists but VPCs don't consult it. Common when a zone is created in one account and used in another.
• Resolver-rule precedence. Multiple resolver rules may match the same query; the most specific wins. Easy to misconfigure.
• VPC DNS resolution disabled. The VPC's enableDnsSupport flag must be on, and enableDnsHostnames for many features.
• Cross-account DNS. Sharing private zones across accounts requires explicit zone-association authorization.

DNSSEC in cloud

Major cloud DNS services support DNSSEC for public zones. Internal queries (within VPC, against private zones) are typically not DNSSEC-validated — the trust model is "you control the resolver and the zones, so signatures add complexity without security gain." For public-facing zones with high security requirements, enable DNSSEC at the authoritative server.

DNS over HTTPS in the cloud

Some cloud providers' resolvers support DoH for client queries. Mostly relevant when the resolver is used outside the VPC or for cross-VPC queries. Inside a VPC the traffic stays on the cloud's internal network and doesn't traverse the public internet, so the encryption value is lower.

Logging DNS queries

Cloud DNS services support query logging — every query against your zones is logged with the source, query name, query type, and answer. Useful for:

• Debugging "DNS isn't working" issues by seeing what was queried.
• Security: detecting suspicious lookups (data exfiltration via DNS, malware C2 hostnames).
• Compliance: audit trail of internal name resolution.

Query logs can be high-volume; budget storage accordingly.

Frequently Asked Questions

What is a VPC resolver?

The DNS server every VPC provides at a known address (typically .2 in the VPC CIDR for AWS). Instances are configured to use it by default. The resolver answers queries for public domains (recursing out to the internet), private hosted zones associated with the VPC, and cloud-provider-specific names (like service endpoints).

What is a private hosted zone?

A DNS zone that resolves only inside specific VPCs you associate with it. A name like internal.example.com can have one set of A records visible to VPCs, completely different from (or absent from) the public DNS for the same domain. Used for internal service discovery, naming private endpoints, and split-horizon patterns.

What is split-horizon DNS?

A single domain resolves to different values depending on who is asking. Inside the VPC, api.example.com might resolve to a private IP; from the public internet, the same name resolves to a load balancer's public IP. The split lets the same domain serve internal and external clients with different routing.

How do I resolve on-prem DNS names from cloud and vice versa?

Conditional forwarding. Configure the VPC resolver to forward queries for on-prem domains (e.g., corp.internal) to on-prem DNS servers via VPN or Direct Connect. Configure on-prem DNS to forward queries for cloud domains to outbound resolver endpoints in the VPC. Each side keeps its own authoritative DNS but can resolve the other.

Why does the VPC resolver matter for private endpoints?

When you create a private endpoint, the cloud creates a private DNS zone that resolves the service's public hostname to the endpoint's private IP. This works only because the VPC resolver consults that private zone before recursing publicly. If you bypass the VPC resolver (point instances at 8.8.8.8 directly, for example), the private zone is ignored and queries return the public IPs — the endpoint is never used.