Route 53 - Global DNS Flashcards
R53 Hosted Zones
-A R53 Hosted Zone is a DNS DB for a domain e.g. animals4life.org
-R53 is Globally Resilient (multiple DNS Servers)
-Are created automatically when you register a domain via R53 - can be created separately
-There’s a monthly fee to host each hosted zone, and a fee for those queries made against that hosted zone
-Host DNS Records (e.g. A, AAAA, MX, NS, TXT ….)
-Hosted Zones are what the DNS system references - Authoritative for a domain e.g. Animals4life.org
R53 Public Hosted Zones
-DNS Database (zone file) hosted by R53 (Public Name Servers)
-Accessible from the public internet & VPCs
-When created, R53 allocates 4 PublicNameServers, and it’s on those names servers, that the zone file is hosted - Hosted on 4 R43 Name Servers (NS) specific for the zone
-To integrate it with the public DNS system, you change the NS records for that domain to point at those 4 R53 NS - Use “NS Records” to point at these NS (connect to global DNS)
-Resource Records (RR) created within the Hosted Zone
-Externally registered domains can point at R53 Public Zone
Architecture
-VPC instances are already configured (if enabled) with the VPC+2 address as their DNS Resolver - this allows querying of R53 public and internet hosted DNS zones
R53 Private Hosted Zones
-A Public Hosted Zone … which isn’t public
-Associated with VPCs (Only accessible within VPCs)
-Using different accounts is supported via CLI/API
-Split-view (overlapping public & private) for PUBLIC and PRIVATE (INTERNAL) use with the same zone name
-Inacessible from the public internet - Zone cannot be queried outside of associated VPCs
CNAME vs R53 Alias
CNAME
-An “A” record maps a NAME to an IP ADDRESS (catagram.io»_space;> 1.3.3.7)
-CNAME maps a NAME to another NAME (www.catagram.io»_space;> catagram.io)
-CNAME is invalid for naked/apex (catagram.io) (Problem)
-Many AWS services use a DNS Name (ELBs)
-With just CNAME - catagram.io»_space;> ELB WOULD BE INVALID
-For anything that’s not the naked domain, where you want to point a NAME to another NAME, CNAME records are fine
For the naked/apex domain, if you need to point at another name, such as ELBs, you can’t use CNAMEs
ALIAS
-ALIAS records map a NAME to an AWS resource
-Can be used both for naked/apex and normal records ***
-For non apex/naked - you could use CNAMEs or ALIAS
-There is no charge for ALIAS requests pointing at AWS resources
-For AWS Services - default to picking ALIAS ***
-Should be the same “Type” as what the record is pointing at ***
-API Gateway, CloudFront, Elastic Beanstalk, ELB, Global Accelerator & S3 Buckets
Simple Routing
-Starts with a Hosted Zone, with Simple Routing, you can create one record per name (www = A)
-Each record using Simple Routing, can have multiple values, which are part of that same record
-When a client makes a request to resolve www, all of the values are returned in the same query in a random order
-The client chooses one of the values, and then connects to that server based on the value
-Use it when you want to route requests towards one single service, such as a web server ***
-Simple to implement and manage
-The limitation is that doesn’t support health checks
R53 Health Checks
-Health check are separate from, but are used by records
-Health ckeckers located globally
-They aren’t limited to just AWS targets - You can check anything which is accessible over the public internet (it just needs an IP address)
-Checks occur every 30s (every 10s costs extra)
-The checks can be: TCP, HTTP/HTTPS, HTTP/HTTPS WITH String Matching (to check the content of the response)
-Based on these Health Checks, end-points are either, Healthy or Unhealthy
-Types of checks:
–Endpoint = These are checks which assess the health of an actual endpoint that you specify
–CloudWatch Alarm = These checks react to CW Alarms, which can be configured separately and can involve some detailed in-OS or in-app tests (if you use the CW Agent)
–Checks of Checks (calculated) = Checks of other checks, so you can create health checks, which check application wide health with lots of individual components
-If 18% of health checkers report as healthy, the health check is healthy
-In most cases an unhealthy record is NOT returned in queries
Failover Routing
-Starts with a Hosted Zone (www), with Failover Routing, we can add multiple records of the same name, a primary and a secondary.
-Each of these records points at a resource
-A common architecture is to use failover for a “out of band” failure/maintenance page for a service (e.g. EC2/S3)
-The health check generally occurs on the primary record, if the target of the health check is “Healthy” the primary record is used
-If it’s “Unhealthy”, then the secondary record of the same name is used
-Use when you want to configure active passive failover **
Multi-Value Routing
-Starts with a Hosted Zone (www), with Multi-Value Routing, you can create many records (www) all with the same name
-Each of the records can have an associated health check, and when queried, up to 8 healthy records are returned to the client. (If more exist, 8 are randomly selected)
-The client picks one of those values and uses it to connect to the resource
-Each record is independent and can have an associated health check
-Any record which fail health checks won’t be returned to the client and won’t be selected by the client, when connecting to resources
-Multi-Value Routing, aims to improve availability. It is NOT a replacement for load balancing **
-Used when you have many resources and you want them all health checked and then returned at random
-Ability to return multiple health checkable IP addresses
Weighted Routing
-Simple load balancing or testing new software versions ***
-Starts with a Hosted Zone with records (www) and they point at IP addresses
-You are able to specify a weight for each record.
-The total weight is calculated (100) = 40 + 40 + 20
-Each record then gets returned based on it’s waiting versus the total weight (40% - 40% - 20%)
-A “0” weight means a record is NEVER returned, unless all are “0” then all are considered
-Each record, it’s returned based on it’s record weight VS total weight
-If a chosen record is Unhealthy, the process of selection is repeated, until a healthy record is chosen
Latency Routing
-Use latency-based routing when optimizing for performance & user experience ***
-Starts with a Hosted Zone with records (www) of the same name and they point at IP addresses
-Each record you can specify a Record Region - www > us-east-1 > A > 1.1.1.1 // www > us-east-2 > A > 2.2.2.2
-Latency-based routing supports one record with the same name in each AWS Region
-In the background, AWS maintains a database of latency between the users general location and the Regions tagged in records. (isn’t real time)
-The record is selected and it’s returned to the user and used to connect to resources
-The record returned is the one which offers the lowest estimated latency & is healthy
-If the record is unhealthy, then the next lowest latency is returned to the client
This type of routing policy, is designed to improve performance for global applications by directing traffic towards infrastructure with the best, so lowest latency, for users accessing that application.
Geolocation Routing
-The location of customers and the location of resources, are used to influence resolution decisions
-When you create records, you tag the records with the location - Either “US state”, “country”, “continent” or “default”
-When a user is making a resolution request, an IP check verifies the location of the user (normally the resolver)
-Geolocation doesm’t return the “closest” records, only relevant (location) records
-R53 checks for records 1) in the state, 2) the country, 3) the continent and 4) (optionally) default - it returns the most specific record or “NO ANSWER”
-Can be used for regional restrictions, language specific content or load balancing across regional endpoints ***
-If you’re based in the US, but are based in a different state than a record, you won’t get that record
-If you’re based in the US and there is a record, which is tagged as the US as a country, you will get that record returned
-If there isn’t a country specific record, but there is one for the continent that you’re in, you’ll get that record returned
-The “default” is a catch-all, it’s optional, if you choose to add it, then it’s returned, if you’re user is in a location where you don’t have specific record tagged to that location
Geoproximity
-Aims to provide records, which are as close to your customers as possible
-Latency based routing provides the record, which has the lowest estimated latency between your customer and the region that the record is in
-Geoproximity aims to calculate the distance between a customer and the record, and answer with the lowest distance
-When using Geoproximity, you define rules
So you define the region that a resource is created in, if it’s an AWS (Region) resource or provide the latitude and longtitude coordinates, if it’s an external resource.
You also define a bias, so rather than just using the actual physical distance, we can adjust how R53 handles the calculation. We can define a plus (+) or minus (-) bias. “+” increases a region size and decreases neighbouring regions.
-R53 knows the location of these resources, it also knows the location of the customers making the requests and so it will direct those requests at the closest resource
-Geoproximity routing lets R53, route traffic to your resources based on the geographic location of your users and your resources, but you can optionally choose to route more traffic or less traffic to a given resource by specifying a value (bias).
A bias expands or shrinks the size of a geographic region, that is used for traffic to be routed to.
R53 Interoperability
Means using R53 to register domains or to host zone files, when the other part of that is not with R53. Generally both of these things are performed together, by R53, but it’s possible for R53 just to do one or the other.
-R53 normally has 2 jobs - Domain Registrar and Domain Hosting
-R53 can do BOTH, or either Domain Registrar or Domain Hosting
Let’s step through what happens, when you register a domain using R53:
1st. R53 accepts your money (domain registration fee)
2nd. R53 allocates 4 Name Servers (NS) (domain hosting)
3rd. R53 creates a zone file (domain hosting) on the above NS
4th. R53 communicates with the registry of the TLD (domain registrar)
5th. sets the NS records (animals4life.org) for the domain to point at the 4 NS above
The registrar registers the domain on your behalf, and then another entity provides DNS or domain hosting, which is how you add a manage records within hosted zones. (Both provided by R53)
R53 - Both Roles
R53 Registrar Role (Registered Domain) - R53 DNS Hosting Role (Public Hosted Zone)
1st. Register a domain within R53 (animals4life.org) (You pay the fee, 1 per Y/1 per 3Y)
2nd. R53 Domain Registrar liaises with R53 Domain hosting to create a Public Hosted Zone, which allocates 4 R53 NS to host that zone, which are then returned to the registrar
3rd. Once the registrar has these 4 NS, it passes all of this along through to the .org top level domain registry (TLD). The registry is the manager of the .org top level domain zone file, and it’s via this entity that records, are created in the top level domains zone for the “animals4life.org” domain.
So entries are added for our domain, which point at the 4 NS, which are created and managed by R53. That’s how the domain becomes active on the public DNS system.
-We also have to pay a monthly fee to host the domain, so the hosted zone. (also paid to R53)
Route 53 - Registrar Only
R53 Registrar Role (Registered Domain) - 3rd Party Domain Hosting
-We still pay R53 for the domain, they still liaise on our behalf with the registry for the top level domain (TLD), but this time a different entity is hosting the domain, so the zone files and the domain servers.
-Records are managed (3rd Party) and the domain is managed via R53
-So as the DNS admin, you would need to create a hosted zone (3rd Party)
-The 3rd Party provider would generally charge a monthly to host that zone on name servers that they manage
-You would need to get the details of those servers, once it’s been created, and pass those details on to R53
-Then R53 would then liaise with the .org TLD registry, and set those NS records within the domain, to point the name servers managed in this case by the 3rd Party.
(Worst way to manage domains)
