Networking | Route53 - devian-al/AWS-Solutions-Architect-Prep GitHub Wiki

Amazon Route 53 is a highly available and scalable Domain Name System (DNS) service. You can use Route 53 to perform three main functions in any combination domain registration, DNS routing, and health checking.

• DNS is used to map human-readable domain names into an internet protocol address similarly to how phone books map company names with phone numbers.
• AWS has its own domain registrar.
• When you buy a domain name, every DNS address starts with an SOA (Start of Authority) record. The SOA record stores information about the name of the server that kicked off the transfer of ownership, the administrator who will now use the domain, the current metadata available, and the default number of seconds or TTL.
• NS records, or Name Server records, are used by the Top Level Domain hosts (.org, .com, .uk, etc.) to direct traffic to the Content servers. The Content DNS servers contain the authoritative DNS records.
• Browsers talk to the Top Level Domains whenever they are queried and encounter domain name that they do not recognize.
  1. Browsers will ask for the authoritative DNS records associated with the domain.
  2. Because the Top Level Domain contains NS records, the TLD can in turn queries the Name Servers for their own SOA.
  3. Within the SOA, there will be the requested information.
  4. Once this information is collected, it will then be returned all the way back to the original browser asking for it.
• In summary Browser -> TLD -> NS -> SOA -> DNS record. The pipeline reverses when the correct DNS record is found.
• Authoritative name servers store DNS record information, usually a DNS hosting provider or domain registrar like GoDaddy that offers both DNS registration and hosting.
• There are a multitude of DNS records for Route53. Here are some of the more common ones

Record Name	Description
A records	These are the fundamental type of DNS record. The “A” in A records stands for “address”. These records are used by a computer to directly pair a domain name to an IP address. IPv4 and IPv6 are both supported with "AAAA" referring to the IPv6 version. A URL -> IPv4 and AAAA URL -> IPv6.
CName records	Also referred to as the Canonical Name. These records are used to resolve one domain name to another domain name. > For example, the domain of the mobile version of a website may be a CName from the domain of the browser version of that same website rather than a separate IP address. This would allow mobile users who visit the site and to receive the mobile version. CNAME URL -> URL.
Alias records	These records are used to map your domains to AWS resources such as load balancers, CDN endpoints, and S3 buckets. Alias records function similarly to CNames in the sense that you map one domain to another. >The key difference though is that by pointing your Alias record at a service rather than a domain name, you have the ability to freely change your domain names if needed and not have to worry about what records might be mapped to it. Alias records give you dynamic functionality.
PTR record	These records are the opposite of an A record. PTR records map an IP to a domain and they are used in reverse DNS lookups as a way to obtain the domain name of an IP address. PTR IPv4 -> URL.

One other major difference between CNames and Alias records is that a CName cannot be used for the naked domain name (the apex record in your entire DNS configuration / the primary record to be used). CNames must always be secondary records that can map to another secondary record or the apex record. The primary must always be of type Alias or A Record in order to work.

• Due to the dynamic nature of Alias records, they are often recommended for most use cases and should be used when it is possible to.
• TTL is the length that a DNS record is cached on either the resolving servers or the users own cache so that a fresher mapping of IP to domain can be retrieved. Time To Live is measured in seconds and the lower the TTL the faster DNS changes propagate across the internet. Most providers, for example, have a TTL that lasts 48 hours.
• You can create health checks to send you a Simple Notification if any issues arise with your DNS setup.
• Further, Route53 health checks can be used for any AWS endpoint that can be accessed via the Internet. This makes it an ideal option for monitoring the health of your AWS endpoints.

• When you create a record, you choose a routing policy, which determines how Amazon Route 53 responds to DNS queries. The routing policies available are
  • Simple Routing
  • Weighted Routing
  • Latency-based Routing
  • Failover Routing
  • Geolocation Routing
  • Geo-proximity Routing
  • Multivalue Answer Routing
• Simple Routing
  • is used when you just need a single record in your DNS with either one or more IP addresses behind the record in case you want to balance load.
  • If you specify multiple values in a Simple Routing policy, Route53 returns a random IP from the options available.
• Weighted Routing
  • is used when you want to split your traffic based on assigned weights. For example, if you want 80% of your traffic to go to one AZ and the rest to go to another, use Weighted Routing.
  • This policy is very useful for testing feature changes and due to the traffic splitting characteristics, it can double as a means to perform blue-green deployments. When creating Weighted Routing, you need to specify a new record for each IP address.
  • You cannot group the various IPs under one record like with Simple Routing.
• Latency-based Routing
  • as the name implies, is based on setting up routing based on what would be the lowest latency for a given user.
  • To use latency-based routing, you must create a latency resource record set in the same region as the corresponding EC2 or ELB resource receiving the traffic.
  • When Route53 receives a query for your site, it selects the record set that gives the user the quickest speed.
  • When creating Latency-based Routing, you need to specify a new record for each IP.
• Failover Routing
  • is used when you want to configure an active-passive failover set up.
  • Route53 will monitor the health of your primary so that it can failover when needed.
  • You can also manually set up health checks to monitor all endpoints if you want more detailed rules.
• Geolocation Routing
  • lets you choose where traffic will be sent based on the geographic location of your users.
• Geo-proximity Routing
  • lets you choose where traffic will be sent based on the geographic location of your users and your resources.
    • You can choose to route more or less traffic based on a specified weight which is referred to as a bias.
    • This bias either expands or shrinks the availability of a geographic region which makes it easy to shift traffic from resources in one location to resources in another.
    • To use this routing method, you must enable Route53 traffic flow.

      If you want to control global traffic, use Geo-proximity routing. If you want traffic to stay in a local region, use Geolocation routing.

• Multivalue Routing
  • is pretty much the same as Simple Routing
  • but Multivalue Routing allows you to put health checks on each record set.
  • This ensures then that only a healthy IP will be randomly returned rather than any IP.

• Create a health check and specify values that define how you want the health check to work, such as:
  • The IP address or domain name of the endpoint that you want Route 53 to monitor.
  • The protocol that you want Route 53 to use to perform the check: HTTP, HTTPS, or TCP.
  • The request interval you want Route 53 to send a request to the endpoint.
  • How many consecutive times the endpoint must fail to respond to requests before Route 53 considers it unhealthy. This is the failure threshold.
• You can configure a health check to check the health of one or more other health checks.
• You can configure a health check to check the status of a CloudWatch alarm so that you can be notified on the basis of a broad range of criteria.

• You use the visual editor to create a traffic policy. A traffic policy includes information about the routing configuration that you want to create:
  • the routing policies that you want to use
  • resources that you want to route DNS traffic to, such as the IP address of each EC2 instance and the domain name of each ELB load balancer.
• Create a policy record where you specify the hosted zone in which you want to create the configuration that you defined in your traffic policy. It’s also where you specify the DNS name that you want to associate the configuration with.

• Resolver answers DNS queries for VPC domain names such as domain names for EC2 instances or ELB load balancers, and performs recursive lookups against public name servers for all other domain names.
• DNS resolvers on your network can forward DNS queries to Resolver in a specified VPC. You can also configure Resolver to forward queries that it receives from EC2 instances in your VPCs to DNS resolvers on your network.
• Resolver is regional.
• An inbound endpoint specifies the VPC that queries pass through on the way from your network to Resolver.
• To forward DNS queries that originate on EC2 instances in one or more VPCs to your network, you create an outbound endpoint and one or more rules.
• Route 53 Resolver DNS Firewall is a managed firewall that lets you block DNS queries made from known malicious domains and allow queries from trusted domains. This is achieved through the use of “blocklists” and “allowlists”.

• Each health check that you create can monitor one of the following:
  • The health of a specified resource, such as a web server
  • The status of other health checks
  • The status of an Amazon CloudWatch alarm
• Each health checker evaluates the health of the endpoint based on two values:
  • Response time
  • Whether the endpoint responds to a number of consecutive health checks that you specify (the failure threshold)
• Types of health checks
  • HTTP and HTTPS health checks – Route 53 must be able to establish a TCP connection with the endpoint within four seconds.
    • In addition, the endpoint must respond with an HTTP status code of 2xx or 3xx within two seconds after connecting.
  • TCP health checks – Route 53 must be able to establish a TCP connection with the endpoint within ten seconds.
  • HTTP and HTTPS health checks with string matching – same as HTTP & HTTPS endpoints + After a Route 53 health checker receives the HTTP status code, it must receive the response body from the endpoint within the next two seconds.
• Health-checking features to route traffic only to the healthy resources:
  • Check the health of EC2 instances and other resources (non-alias records)
  • Evaluate the health of an AWS resource (alias records)
• Two types of failover configurations
  • Active-Active Failover – all the records that have the same name, the same type, and the same routing policy are active unless Route 53 considers them unhealthy. Use this failover configuration when you want all of your resources to be available the majority of the time.
  • Active-Passive Failover – use this failover configuration when you want a primary resource or group of resources to be available the majority of the time and you want a secondary resource or group of resources to be on standby in case all the primary resources become unavailable. When responding to queries, Route 53 includes only the healthy primary resources.
  • To create an active-passive failover configuration with one primary record and one secondary record, you just create the records and specify Failover for the routing policy.
  • To configure active-passive failover with multiple resources for the primary or secondary record, create records with the same name, type, and routing policy for your primary resources.
  • If you’re using AWS resources that you can create alias records for, specify Yes for Evaluate Target Health.
• You can also use weighted records for active-passive failover, with caveats.
• You can configure Amazon Route 53 to log information about the queries that Route 53 receives. Query logging is available only for public hosted zones.

• Authenticate with IAM before allowing to perform any operation on Route 53 resources.
• Every AWS resource is owned by an AWS account, and permissions to create or access a resource are governed by permissions policies. A permissions policy specifies who has access to what.

• The Route 53 dashboard provides detailed information about the status of your domain registrations, including:
  • Status of new domain registrations
  • Status of domain transfers to Route 53
  • List of domains that are approaching the expiration date
• You can use Amazon CloudWatch metrics to see the number of DNS queries served for each of your Route 53 public hosted zones. With these metrics, you can see at a glance the activity level of each hosted zone to monitor changes in traffic.
• You can monitor your resources by creating Route 53 health checks, which use CloudWatch to collect and process raw data into readable, near real-time metrics.
• Log API calls with CloudTrail