This is the last post in the series and will cover off DNS and Route53. I reckon I understand DNS well and thought I’d be able to answer most, if not all, questions without too much stress. Now while I thought I did, the questions were pretty detailed with complex scenarios about name resolution requirements from on-premises to your VPCs in AWS and the other way around, think of being able to resolve names in private zones up in the cloud from on-premises machines, from VPC to another VPC sort of thing too. Don’t tell me I didn’t warn you about the complexity of questions!
The other parts in this series are:
- If customer specified DNS names are required for EC2 instances, then Route53 will provide the names.
- EC2 instances can give name to themselves of the enableDNShostname attribute is set.
- DNS res works over VPC peering too. Both sides need to be enabled for DNS resolutions and DNS names.
- Domain name mappings will need to readjusted if the IPs of instances change, which will happen as public IP addresses are released when instances are restarted.
- Public to private VPC peering DNS res works too – enable DNS resolution from Accepter VPC to Private IP.
- Simple DNS will forward DNS requests to the IP addresses of the AWS provided DNS used for the VPC. This allows resolution of names hosted in VPC’s Route53 private zones.
- Route53 has 3 main functions:
- DNS name registration.
- DNS services.
- Health check to confirm reachability, availability and functionality.
- Route53 health checks work for non-AWS endpoints too. Does this via HTTP/HTTPS/TCP.
- Gotta enable both enableDNShostname and enableDNSSupport for a VPC for instances within the VPC to obtain DNS names from Amazon DNS (not sure what level of functionality, probably wouldn’t check if an application is up?).
- Private hosted zones: These store names that don’t need to be shown to the world.
- Public hosted zones: These store names that are meant to be shown to the world.
- Several routing policies to determine how Route53 responds to various queries:
- Simple (default, use when single resource performs given function).
- Weighted (as name implies, allows for weighted traffic to resources).
- Latency based (as name implies, allows for routing traffic to resources based on latency to the end user. This thing’s automatic and resolution may occur to different instances depending on latency at the time).
- Failover (served by primary first, then by secondary when health checks fail). This works for PUBLIC HOSTED ZONES only. CloudWatch metrics can be used to check the health of an instance and failover based on the health.
- Geo-location (pretty handy to use when distribution is to be done based on the geo location of users).
- Multianswer (sort of like a load balancer with multiple names provided back after resolution and an instance gets chosen at random.
- Geo-proximity (routing based on the geo location of the resources).
- CloudWatch alarms are what are used for keeping an eye on the health checks.
- Don’t use a NAT gateway/instance for AD, this may result in replication issues.
This post rounds off the series. There are topics around automating and t-shooting scenarios in the blueprint, they can be answered if you’ve played around with the AWS console enough.