Amazon Route 53 | Dynamic Authoritative DNS Server
Amazon Route 53, essentially is a DNS Server and a Domain registrar. At a bare minimum level it can answer to authoritative DNS queries. Resolve an IP address for a given domain name. What makes it stand out from any regular authoritative DNS servers, is that the authoritative answer it gives can be made dynamic through set of configurable policies.
To understand, will first have to understand how DNS works. Lets say you type any url in your web browser.
At a very high level, your browser will have to perform following tasks, to delivery you the content of the site you are trying to access.
- Find the IP address of the remote server — that’s where the DNS Server comes.
- Decide the port of the remote host — since port is not explicitly specified, browser will use the default port for the schema https, which is port 443.
- Since schema is https browser would have initiate tcp connection with the remote host.
- Since schema is https browser would have establish a TLS connection session with the remote server.
- Send the request according to http protocol message, encrypted using keys agreed in step 4.
Let’s have a closer look at the mechanics of step 1, where the browser finds the IP address of the remote host it wants to connect.

Flow 1, 2, 3 and 4 are all successful DNS retrievals performed by browser.
- Browser will first check in its local domain name mapping file. In UNIX like systems, usually there is a file called /etc/hosts which stores the local domain name mapping.
- If step 1 is unsuccessful, browser will check in its local cached DNS results.
- Browser will then request the Resolving DNS server configured in the connection profile. Resolving DNS server is typically provided by your ISP. Resolving DNS server will provide a final result for the query, hiding the different stages of DNS resolving.
Resolving DNS server is allowed to cache DNS results specified by TTL (Time to Live) parameter. If the DNS result is already cached, the resolving DNS server will return it to the browser.
4. If DNS result is not found in the cache, then Resolving DNS server will perform a hierarchical DNS retrieval procedure.
First it will ask from root level domain servers, to provide the top level domain (TLD) servers responsible for .io
Once the TLD is found it will send a request to TLD to find the Domain level name server responsible for .apptizer.io
When Domain Level name server is found, it will request to resolve the merchant.apptizer.io domain. And domain level name server will respond with the IP address for the domain name.
Resolving name server will cache the result and same time respond to the browser with the result it received.
Results provided by domain level name servers are called as authoritative results. Where as the resolving DNS servers which provided cached results are providing non-authoritative results.
Route 53 is an authoritative DNS Server. But the authoritative answer for DNS queries can be made dynamic by using set of policies provided.
Following are the set of policies
- Simple Policy
Simple rule is not allowing you to provide dynamic results for DNS queries. For every DNS query comes to the Route 53 DNS server, it will always provide the same result. For an example simple rule will result in the IP address of Amazon elastic load balancer’s or Amazon EC2 instance’s public IP address.

2. Weighted Policy
If a weighted rule is configured, Amazon Route 53 will make sure that DNS queries will be resolved proportionally as specified by the weights.
There are many use cases where we want a smaller portion of our website traffic to be handle by a new version of our software.
Lets say you are running an eCommerce website. And you are rolling out a new payment gateway integration, where the customer can use use to pay at checkout. But you don’t want all the customers to see this new feature, as you have not done a test on how much payments new integration can handle during the peak load.
Solution would be to run a bleeding edge feature server, and handle portion of your customer request through that. You can configure Route 53 weighted policy so that, 95% of DNS queries will result in Production server and 5% of the queries will result in bleeding edge feature server.

3. Fail Over Policy
Amazon Route 53 can be configured with a Fail Over Policy. Which involves configuring health checks to a target host or the load balancer. And once the entity is detected as failed, then all DNS queries to will be resolved to the configured fail over node. Health check will continue to check if main node came active. And once its success, Route 53 will switch back to Production Server.

4. Latency Based Policy
One of the requirement for your website deployment is to make sure that end users been able to load your site with minimum latency. One approach would be to deploy your website across multiple regions in AWS global infrastructure. And make sure customer is routed to lowest latency node. Amazon Route 53 is using its latency related data, customer’s location and AWS regions where your system is deployed, to derive the lowest latency node.

5. Geo Location Policy
Amazon Route 53’s Geo Location Policy can make DNS to be resolved based on Geo Location of the requesting client. Your eCommerce site might have different themes, cookie and authentication policies or different payment integrations, tax calculation logic based on the region of the consumer. If you decide to host multiple version of your site and then route your customers based on their location, then you can configure a Geo Location Policy.

Amazon Route 53 use the abstraction of its role to resolve Domain Names to an IP addresses and make it dynamic using it configurable policies. These policies provide the means for elasticity for your system in a whole new level.
