DNS

DNS separates a resource's name from its network location. When a user opens https://www.example.com, the client typically asks a recursive DNS resolver for the address associated with www.example.com. The resolver returns a cached answer or follows the DNS hierarchy through root, top-level domain, and authoritative name servers. The client then connects to the returned address. DNS resolves the hostname, not the entire URL: it does not interpret the HTTPS scheme, path, or query string.

Authoritative DNS servers publish records for zones, which are administratively managed portions of the DNS namespace. A records contain IPv4 addresses, AAAA records contain IPv6 addresses, and CNAME records point one name to another name. MX records identify mail servers, while TXT records hold text commonly used for domain verification and email authentication. NS records identify authoritative name servers and support delegation. Registering a domain, hosting its DNS records, and hosting its website are separate functions that can use different providers.

Cloud environments use DNS to keep names stable while infrastructure changes. For example, app.example.com can point to a managed load balancer rather than directly to a virtual machine. The load balancer can distribute requests across instances that are replaced or scaled independently. Provider-specific alias records can map a custom name to supported cloud resources; these are not the same as standard CNAME records. A standard CNAME cannot normally coexist with other records at the same name, which prevents its use at a zone apex where required records already exist.

Public DNS publishes information intended to be resolvable through the public DNS hierarchy. Private DNS serves names within designated networks, such as application and database names inside a virtual private cloud. Hybrid environments can forward selected queries between cloud networks and on-premises resolvers. Resolving a private name does not itself provide connectivity: routing, firewall rules, and application permissions must still allow access.

Caching makes DNS efficient and resilient, but it complicates changes. A record's time to live, or TTL, tells caches how long they may retain an answer before refreshing it. Longer TTLs reduce query traffic and dependence on authoritative servers; shorter TTLs allow cached answers to expire sooner but can increase query volume and cost. Before a planned endpoint migration, lower the TTL early enough for previously cached answers to expire. Changing a record does not instantly update every client, and existing connections can continue using the old destination.

DNS can also influence endpoint selection through weighted, latency-based, geographic, or health-aware responses. These policies select DNS answers rather than forwarding application traffic. DNS-based failover is therefore not instantaneous, and weighted answers do not guarantee an exact percentage of application requests because resolvers cache responses and many users can share a resolver.

For AWS Cloud Practitioner questions, recognize Amazon Route 53 as the AWS service for authoritative DNS, domain registration for supported top-level domains, and health checks that can inform DNS failover. It is not a web server, content delivery network, or application load balancer. For example, Route 53 can resolve a custom domain to a CloudFront distribution or an Elastic Load Balancing endpoint, while those services handle the subsequent application traffic.

DNS is also a security dependency. Protect registrar and DNS administration access because unauthorized record changes can redirect users. DNSSEC can authenticate signed DNS data when validation is performed, but it does not encrypt DNS queries or replace HTTPS. When troubleshooting, check delegation, record type, cached answers, resolver behavior, and network reachability as separate concerns.