DNS resolution is the first thing that happens when a request is made to a remote server. It is a process of finding the computer-friendly address of the remote server using a human-friendly domain name.

There are few performance improvement possibilities like perfect cache invalidation time. Preferring A record over CNAME. But before all these let's understand how DNS resolution actually works.

1. A network request is made to the server using its domain name.
2. The browser first checks its DNS cache, if present use the IP address else asks Operating System.
3. Operating System checks its cache (and few more things like host file) if present return it else asks resolver.
4. Resolvers are ISP(Internet Service Provider) servers but 5. can be configured to any other DNS service provider.
5. Resolvers check if the domain is in its cache return it else look for root servers.
6. Root servers are top in the DNS hierarchy and know the address of TLDs(top-level domain like .com, .net, .org, etc.) servers.
7. Based on the type of domain, Root servers direct resolver to corresponding TLD servers. For a .com domain, root servers direct to .com TLD servers.
8. TLD servers know the address of name servers.
9. Name servers know the real IP address of the requested domain. The browser receives the resolved IP address.

Ahh too confusing and too much to remember. Let's keep it simple and know what is in our control and find the scope of performance improvements.

DNS Management Tools

A registrar is a place where one buys a domain. The registrar provides name servers and a few other DNS management tools.

Example Registrars and DNS management tools

1. Amazon Web Service(AWS) — Route 53
2. Google Cloud — domains.google.com

The main job of DNS management tools.

1. Provide name servers details to TLDs.
2. Add domain validation and authorization config for third parties.
3. Define cache invalidation time or Time To Live(TTL). It’s a duration for which resolvers, browsers, etc can cache IP addresses in their cache.
4. Define how to resolve a particular request. For mails check MX record. For HTTP/HTTPS check A, AAAA, or CNAME record.

DNS Performance Optimization Opportunities

1. Increase cache invalidation time

Increasing cache invalidation time will ensure that the domain IP addresses will be served from the nearest cache. This will result in low latency DNS resolution.

This will be a problem in cases where domain to IP mapping is frequently changed.

To handle such cases follow these steps.

1. Set TTL to 0 to avoid the cache of any new request.
2. Wait for the previous TTL value time to ensure the previous cache is invalidated.
3. Make the new changes.

This will fix any downtime possibilities from any known changes. But what if the server crashed or something unexpected happened. For such cases keeping a static IP and assigning it to a new server will help.

Let's look at the TTL value of some popular domains.

• apple.com — 60 min
• microsoft.com — 60 min
• Booking.com — 24 hrs
• google.com — 5 min
• indiatimes.com — 20 min
• godaddy.com — 10 min
• azure.microsoft.com — 60 min

Increasing TTL is a tradeoff between availability and performance. Controlling availability with high TTL is possible but needs extra effort and care.

2. Use A or AAAA record wherever possible in place of CNAME

CNAME or Canonical Name is like recursion where one domain resolves to another domain. The DNS resolution algorithm keeps looking until it finds the real IP address.

In most cases replacing CNAME will not be possible because of no control over the resolved IP address. This rule is only applicable for cases where IP address is known but still, CNAME is preferable due to unmanageable DNS records. DNS records if not maintained properly becomes unmanageable in most mid to large-scale organizations.

Some CDN and DNS service providers use the concept of CNAME Flattening to resolve IP directly without going through the whole chain of DNS resolution. Opt for it if your CDN or DNS service provider has support for it.

3. Use CDN which uses their own name servers.

CDN works in two ways.

1. Ask to replace registrar name servers with their name servers.
2. Ask to add CNAME for domain resolution.

Both approaches have their own Pros and Cons. The first one is good for fast DNS resolution. The second one gives more flexibility and control to the maintainer.

CDN has other limitations they are yet not equipped to serve dynamic content. There is some development in this area like using lambda on the edge(AWS) but still, there is a long path to cover.

4. Use custom name servers (only for large scale applications

The purpose of name servers is to provide a real IP address that corresponds to a domain. Using custom logic a domain can be resolved to a different IP each time it receives a request.

CDN uses this approach to serve content from the nearest host to the user but they can’t be used for dynamic content.

Using custom name servers to resolve IP addresses based on the region can significantly reduce latency.

• In California for users in North America
• In Paris for users in Europe
• In Mumbai for users in Asia
• In Sydney for users in Australia

Now people in North America can get their content directly from servers in California and people in India get content from Mumbai. Data belongs to a region can be stored along with the region and fallbacks to other regions.

This gives a lot of flexibility for dynamic logic without any compromising on performance.

There are lots of complexities in this approach. One problem is database sharding keeping a region's data close to it but still able to serve content from other shards.

Many large scale organizations use this approach to distribute traffic and serve the request quickly.

Conclusion

Improving DNS resolution can have a huge impact on the performance of a site. But every possible optimization has some cost.

1. Increasing Time to Live(TTL) reduces latency but impact availability.
2. CNAME is not always replaceable with the corresponding A record.
3. CDN’s are not yet ready for dynamic content. Custom name servers are hard to put in place.
4. Figure out appetite for performance at your org and accordingly tune DNS settings.

Previously published at https://ashu.online/blogs/optimize-dns-resolution-for-fast-website