DNS Terms
DNS Root Servers:
Trust starts somewhere. The DNS root servers are that trust — a group of servers that are authoritative to give answers about the root zone. TLDs are controlled by the root zone.
Top-Level Domain (TLD):
The top tier in the DNS hierarchy. Generally structured into geographic codes — such as .au, .us, .uk — and generic TLDs — such as .com, .org, and .edu. Large orgs or country orgs are delegated control of these by the root servers to be authoritative.
Subdomain:
Anything between a host and a TLD is a subdomain. example.com is a .com subdomain..co.uk is a subdomain of .uk — an organization is delegated control of subdomains and is authoritative.
Zone and Zone File:
A zone or zone file is a mapping of IPs and hosts for a given subdomain. The zone file for example.com would contain a record for www.
Records:
DNS has lots of record types — A, MX, AAM, CNAME, TXT, NS (explained later) — and each does different things.
Name Server:
A name server is a server that runs a DNS service and can either store or cache information for the DNS platform. Whether a name server caches or acts as an authority depends on if it’s referenced from a higher level. (See authoritative below.)
Authoritative:
The root servers are authoritative for the root zone — they are trusted by every operating system and networking stack globally. The root servers delegate ownership of a part of the hierarchy, such as .com, to an organization. That organization runs name servers that become authoritative —they can answer queries with authority. Because the root points at these servers, they are authoritative. These .com name servers can point at servers for sub domains (e.g., example.com) that then become authoritative.
Hosts:
A record in a zone file: www, mail, catgifserver, doggowebserver.
FQDN:
Fully qualified domain name — the host and domains: www.example.com.
Registering a domain within DNS consists of a few steps and components. With many services — such as Route 53, Hover.com, and even GoDaddy — these steps appear to happen together.
STEP 1: Check the domain is available: This step is usually done during registration, but for a given domain, a check needs to occur against the database of the TLD or subdomain operator. Registering bestcatpicsintheworldevercom requires a check with Verisign who operate .com, and registering amazingcats.co.uk would need a check against .co.uk.
STEP 2: Purchase the domain via a registrar The domain operator allows companies to sell domains within the domain it manages. Buying a something.com domain via Route 53 means Route 53 taking payment and then contacting Verisign (.com operator) and adding a record into the .com zone that represents your domain.
STEP 3: Hosting the domain: Registering a .com domain gives you the rights to specify name servers (NS) to be authoritative for that domain. You need to manage or pay for DNS hosting or name servers that are configured for your domain, and inform the .com operator to link those servers with your domain record. Route 53 allows you to register a domain and host it, or just host it, or just register it.
STEP 4: Records in the zone file: On the Name Servers that are authoritative/host the domain, you need to add records into the zone file — www, mail, ftp, etc. This completes the chain, and these are accessible from the Internet.
A zone or hosted zone is a container for DNS records relating to a particular domain (e.g., example.com). Route 53 supports public hosted zones, which influence the domain that is visible from the Internet and VPCs. Private hosted zones are similar but accessible only from the VPCs they are associated with.
Public Zones:
- A public hosted zone is created when you register a domain with Route 53, when you transfer a domain into Route 53, or if you create one manually.
- A hosted zone (zone) has the same name as the domain it relates to — e.g., example.com will have a hosted zone called example.corn.
- A public zone is accessible either from internet-based DNS clients (e.g., your laptop) or from within any AWS VPCs.
- A hosted zone will have “name servers” — these are the IP addresses you can give to a domain operator, so Route 53 becomes “authoritative” for a domain.
Private Zones:
- Private zones are created manually and associated with one or more VPCs — they are only accessible from those VPCs.
- Private zones need enableDnsHostnames and enableDnsSupport enabled on a VPC.
- Not all Route 53 features supported — limits on heath checks
- Split-view DNS is supported, using the same zone name for public and private zones — providing VPC resources with different records (e.g., testing, internal versions of websites). With split view, private is preferred — if no matches, public is used.
DNS supports different types of records, each providing different functionality. At an associate level, the important ones are:
A Record (and AAAA): For a given host (www), an A record provides an IPv4 address (e.g., 10.0.0.1) and an AAAA provides an IPv6 address.
CNAME Record: Allows aliases to be created (not the same as an alias record). A machine such as allthethings.linuxocadetny.com might have CNAMES for www, ftp, and images. Each of these CNAMEs points at an existing record in the domain. www -> alltherhings.example.com. CNAMEs cannot be used at the APEX of a domain (e.g., example.corn).
MX Record: MX records provide the mail servers for a given domain. Each MX record has a priority. Remote mail servers use this to locate the server to use when sending to someuser@example.com.
NS Record: Used to set the authoritative servers for a subdomain.com would have NS servers for example.corn.
TXT Record: Used for descriptive text in a domain — often used to verify domain ownership (Gmail/Office365).
Alias Records: An extension of CNAME — can be used like an A record, with the functionality of a CNAME and none of the limitations. Can refer to AWS logical services (load balancers, S3 buckets), and AWS doesn’t charge for queries of alias records against AWS resources.
Health checks can be created within Route 53 and are used to influence Route 53 routing decisions. There are three type of health checks:
- Health checks that monitor the health of an endpoint — e.g., IP address or hostname
- Health checks that monitor the health of another health check (these are referred to as calculated health checks)
- Health checks that monitor CloudWatch alarms — you might want to consider something unhealthy if your DynamoDB table is experiencing performance issues
Route 53 Health Checkers:
- Global health check system that checks an endpoint in an agreed way with an agreed frequency.
- >18% of checks report healthy = healthy, <18% healthy = unhealthy
Types of Health Check:
- HTTP and HTTPS: tcp/80 or tcp/443 connection check in less than four seconds. Reporting 2XX or 3XX code within two seconds.
- TCP health check: tcp connection within 10 seconds
- HTTP/S with string match: All the checks as with HTTS/HTTPS but the body is checked for a string match
Route 53 and Health Checks:
- Records can be linked to health checks. If the check is unhealthy, the record isn’t used.
- Can be used to do failover and other routing architectures (more in the next topic)
Routing policiies:
- Simple routing policy is a single record within a hosted zone that contains one or more values. When queried, a simple routing policy record returns all the values in a randomized order.
The DNS client (the laptop) receives a randomized list of IPs as a result. The client can select the appropriate one and, in this example, initiate an HTTP session with a resource.
Pros: Simple, the default, even spread of requests
Cons: No performance control, no granular health checks, for alias type — only a single AWS resource
- Failover routing allows you to create two records with the same name. One is designated as the primary and another as secondary. Queries will resolve to the primary — unless it is unhealthy, in which case Route 53 will respond with the secondary.
Failover can be combined with other types to allow multiple primary and secondary records. Generally, failover is used to provide emergency resources during failures.
- Weighted routing can be used to control the amount of traffic that reaches specific resources. It can be useful when testing new software or when resources are being added or removed from a configuration that doesn’t use a load balancer.
Records are returned based on a ratio of their weight to the total weight, assuming records are healthy.
- Latency-based routing, Route 53 consults a latency database each time a request occurs to a given latency-based host in DNS from a resolver server. Record sets with the same name are considered part of the same latency-based set. Each is allocated to a region. The record set returned is the one with the lowest latency to the resolver server.
- Geolocation routing lets you choose the resources that serve your traffic based on the geographic region from which queries originate. A record set is configured for a continent or country. That record set is used for queries in that same region, with more specific matches taking priority.
A record set can be set as the default that gets returned if the IP matching process fails or if no record set is configured for the originating query region.
Weighted routing