Please enable JavaScript.
Coggle requires JavaScript to display documents.
Route 53 - Coggle Diagram
Route 53
Routing Policies
more here
Geolocation Routing
- Lets you choose where traffic will be sent based on the geographic location of your users
- Many A Records with IP Address associated to a Location (Continent or Country) with optional Health Check
- You can define a default location for users from locations not listed in other records
- Use this for regulatory, language, currency etc. but not for performance (Latency Routing is better for performance)
-
Failover Routing Policy
- (1 or many) Primary A Record with Active IP Address and Health Check
- (1 or many) Secondary A Address with Passive IP Address and optional Health Check
- When Primary Health Check fails Route 53 automatically fails over to Secondary
Latency Routing Policy
- Many A Records with IP Address associated with AWS Region and optional Health Check
- Each user is routed to the IP/Region with the lowest Latency
- Latency is based on traffic between users and AWS data centers
Weighted Routing Policy
- Many A Records with single IP Address, a Weight and an optional Health Check
- The weight (0 to 255) is used to assign priority when routing request
- It compute percentage dividing the weight by the sum of all weights
- If a health check fails the related record is removed until it passes
- Destinations can be in different regions
- Record ID is a value that uniquely identifies each record that has the same name and type (when you create records that have a routing policy other than simple)
-
Simple Routing Policy
- 1 A Record with one or multiple IP Address(es)
- If you have multiple values in the A Record, Route 53 returns a random selected value
- you typically route traffic to a single resource (e.g. web server)
- you can't create multiple records with same name and type, but you can specify multiple values in the same record, such as multiple IP addresses
IP-based Routing Policy
- Route traffic based on the IP of your users, and have the IP addresses that the traffic originates from
- map CIDRs to endpoints/locations
- Example: route end users from a particular ISP to a specific endpoint
Basics
Top-Level Domain
Look at common domain name: google.com, bbc.co.uk:
- The last word in a domain name represent the Top-Level Domain
- The second word in a domain name is known as a Second-Level Domain (optional)
Example:
- google.com -> com is Top-Level Domain, no Second-Level Domain
- bbc.co.uk -> uk is Top-Level Domain, co is Second-Level Domain
Controlled by the IANA (Internet Assigned Numbers Authority) in a root zone database (a DB with al top-level domains) site here
Domain Registrars
An authority that can assign domain names directly under one or more Top-Level Domains. These domains are registered with InterNIC, a service of ICANN, which enforces uniqueness of domain names across internet
- domain.com
- GoDaddy
- Hoover
- AWS
- Namecheap
- domains.google
Common DNS Record Types
CNAME Record Canonical Name
- A CNAME record maps DNS queries for the name of the current record, such as acme.example.com to another domain (my.example.com or zenith.example.org) never directly to an IP address
- The CNAME record can only be used for subdomain.
- In addition, if you create a CNAME record for a subdomain, you cannot create any other records for that subdomain
- A CNAME can point to another CNAME but it is not recommended for performance reasons
- Route 53 charges for CNAME queries
For example, if you create a CNAME for www.website.com, you cannot create any other records for which the value of the Name field is www.website.com.A Record: website.com -> IP Address
CNAME Record: www.website.com -> website.com
CNAME Record: m.website.com -> mobile.website.com
-
SOA Record Start Of Authority
Provides information about a domain and the corresponding Amazon Route 53 hosted zone:
- The name of the server that supplied the data for the zone
- The admin of the zone
- The current version of the data file
- The default number of seconds for the TTL (Time-To-Live) file on resource records
- The email address of the administrator
NS Record Name Server Record
Is used by top-level domain servers to direct traffic to the content DNS server that contain authoritative DNS records
Es.
website.com -> .com TLD server -> ns.awsdns.com NS Records -> SOA (this will contains all DNS records such as A Record, CNAME Records, ...)
ALIAS Record
- Provide a Route 53–specific extension to DNS functionality
- Allows to map one DNS name (example.com) to an AWS resource (elb1234.elb.amazonaws.com)
- Let you route traffic to selected AWS resources, such as CloudFront distributions, Amazon S3 buckets, ELBs, etc.
- They also let you route traffic from one record in a hosted zone to another record
- Route 53 does not charge for alias queries to AWS resources
- Cannot set TTL, it defaults to 60 sec
- Cannot set an ALIAS record for an EC2 DNS name
Unlike a CNAME record, you can create an ALIAS record at the top node of a DNS namespace, also known as the zone apex. For example, if you register the DNS name website.com, the zone apex is website.com. You can't create a CNAME record for website.com, but you can create an ALIAS Record for website.com that routes traffic to www.website.com (as long as www.website.com doesn't already have a CNAME record).ALIAS works like a CNAME in that you can map one DNS name (www.website.com) to another "target" DNS name (elb123.elb.amazonaws.com). The ALIAS record is similar to a CNAME record, which is used to point subdomains to a hostname. The CNAME record only can be used for subdomains, so the ALIAS record fills this gap.You can have Aliased Record A and Record AAAA pointing respectively to IPv4 and IPv4 based AWS resources
-
DNS Key Terms
NameServer NS is a DNS server which host 1 or more Zone with related ZoneFiles. The NS or NS's for *website.com Zone that answer queries for www.website.com
-
-
-
DNS Zone = *.website.com, this contains DNS records for www.website.com, www.m.website.com etc. Think about is as a database
Hosted Zones
It is a container for records, and records contain information about how you want to route traffic for a specific domain, such as example.com, and its subdomains (acme.example.com, zenith.example.com). A hosted zone and the corresponding domain have the same name
Types of Hosted Zones:
- Public hosted zones contain records that specify how you want to route traffic on the internet
- Private hosted zones contain records that specify how you want to route traffic in an Amazon VPC
-
TTL
Time To Live is the amount of time, in seconds, you want the DNS resolvers to cache information about a particular Route 53 DNS record
-
Longer TTL reduces the number of calls DNS resolvers must make to Route 53, which can reduce your bill for the Route 53 service
Health Checks
If a record set fails a health check it will be removed from Route 53 until it passes the health check
-
You can set health checks on individual record sets (.e.g individual EC2, ELB)
(from here) If you're routing traffic to any AWS resources that you can create alias records for, don't create health checks for those resources. When you create the alias records, you set Evaluate Target Health to Yes instead
- CloudFront distribution endpoint: you can't set Evaluate target health to Yes
-
Route 53 is a global service, so you don't specify the region that you want to create health checks in.
Route 53 Resolver
Basics
- It is available by default in all VPC and it has a regional scope
- You can integrate Route 53 Resolver with another DNS resolver on any network that is reachable from your VPC, e.g. another peered VPC or an on-premises network
- Responds recursively to DNS queries from AWS resources for:
- Amazon VPC-specific DNS names (e.g. ec2-192-0-0-24.compute-1.amazonaws.com)
- Amazon Route 53 private hosted zones (PHZ)
- Public records
- Route 53 Resolver only supports recursive DNS queries
Hybrid DNS
Resolver Rules
- Conditional Forwarding Rules (Forwarding Rules) - Forward DNS queries for a specified domain and all its subdomains to target IP address
- example.com -> 172.16.0.10
- acme.example.com -> 172.16.0.10
- my.example.com -> 172.16.0.10
- System Rules - Selectively overriding the behavior defined in Forwarding Rules
- acme.example.com (overrides the above)
- Auto-defined System Rules - Defines how DNS queries for selected domains are resolved, e.g. AWS internal domain names, Privated Hosted Zones)
- compute.amazonaws.com
- ec2.internal
- Resolver Rules enable you to have forwarding rules for each domain name and specify the name of the domain for which you want to forward DNS queries
- Forward rules can be shared using RAM with other VPCs (queries that match the rule pass through to the owner VPC and then forward out)
- Forwarding private DNS queries to VPC CIDR + 2 address from your on-premises DNS servers is not supported. Instead use a Resolver inbound endpoint
- If multiple rules matched, Route 53 Resolver chooses the most specific match (my.example.com vs example.com, the first is selected)
- Resolver endpoints and (conditional) forwarding rules resolve DNS queries between your network and VPCs
- Create in two AZs for high availability (you get ENIs with private IPs)
- Associated with one or more VPCs in the same AWS Region
- Endpoints cannot be used across Regions
- Each Endpoint supports 10,000 queries per second per IP address
- Inbound Resolver endpoints
- allow DNS queries to your VPC from your DNS Resolver network or another VPC
- Allows your DNS Resolvers to resolve domain names for AWS resources and records in Private Hosted Zones
- queries forwarded to these endpoints have the DNS view of the VPC to which the endpoints are attached
- Outbound Resolver endpoints
- allow DNS queries from your VPC to your network or another VPC
- Route 53 Resolver conditionally forwards DNS queries to your DNS Resolvers
- use Resolver Rules to forward DNS queries to your DNS Resolvers
- directly attached to the owner VPC and indirectly associated with other VPCs by rules
- If you have workloads that leverage both VPCs and on-premises resources:
- you also need to resolve DNS hosted on-premises (or in another VPC)
- on-premises resources may need to resolve names hosted on AWS
Private Hosted Zone
- You must enable the VPC settings enableDnsSupport and enableDnsHostnames
- Enable DNS resolution - (default true) DNS resolution with Amazon DNS is supported for the VPC
- Enable DNS hostnames - (default false) instances launched in the VPC receive public DNS hostnames that correspond to their public IP addresses
- Create PHZ and specify the VPC that you want to associate (must be in the same account)
- After creation you can associate more VPCs also in different accounts
- To associate VPCs in different account with a PHZ, you must authorize the association and then make the association programmatically
- Submit one authorization request for each VPC (even if they are in the same account)
- Delete the authorization to associate the VPC with the hosted zone after the association is in place
- Create records in PHZ for Route 53 responds to DNS queries for domain/subdomains
- To query PHZ you need a running EC2 instance in one of the associated VPCs or have an Inbound Endpoint from a hybrid setup
- If you query PHZ from outside the VPCs or your hybrid setup, it will be recursively resolved on the internet
- Split-view DNS, you use the same domain name (example.com) for internal uses - private hosted zone - (accounting.example.com) and external uses, such as your public website (www.example.com) - public hosted zone
- Overlapping namespaces for both private & public hosted zones and private & private hosted zones that have, such as example.com and accounting.example.com, Resolver routes traffic based on the most specific match
- If you have a private hosted zone (example.com) and a Resolver rule that routes traffic to your network for the same domain name, the Resolver rule takes precedence
-
Route 53 Traffic Flow
Used to build a routing system that uses a combination of the followings to route traffic from your users to your cloud or on-premise endpoints:
- geographic location
- latency
- availability
You can build your traffic routing policies:
- from scratch
- from a template from a library and customise it
-
Failover
Active-Active
- use any routing policy (or combination of routing policies) other than failover
- all the records that have the same name the same type (such as A or AAAA) the same routing policy (such as weighted or latency) are active, unless Route 53 considers them unhealthy
- Route 53 can respond to a DNS query using any healthy record
Active-Passive
- Configuring active-passive failover with one primary and one secondary resource
- Use Failover Routing Policy
- Configuring active-passive failover with multiple primary and secondary resources
- Use Failover Routing Policy
- Multiple resources with the primary record, the secondary record, or both
- Primary is healthy as long as at least one of the associated resources is healthy
-
DNSSEC
- Protocol for securing DNS traffic, verifies DNS data integrity and origin
- Protects against Man in the Middle (MITM) attacks
- Route 53 supports
- DNSSEC for Domain Registration (Route53 Domain) - sign each record in the public hosted zone using KMS
- DNSSEC Verification (Route53 Resolver in your VPC) - ensures DNS responses have not been tampered
- Only for Public Hosted Zones