14

We have our DNS domain with 5 level CNAMEs for historical reasons. Some of the things got outsourced for high availability etc. but that's not the point here. My question is having 5 CNAMEs an overkill for the DNS resolver? I was not able to find out any famous website with more than 2-3 level nested CNAMEs pointing to Different DNS domains.

Our CNAME hops look as follows : (I am using xyz just as an example)

www.xyz.com -> xyz.akadns.net -> xyz.worldwide.akadns.net -> xyz.cedexis.net -> xyz.msedge.net -> host1.msedge.net (final A\AAAA record)

I am seeing many clients complain about DNS resolution issues to our website when other sites work fine for them, although when I use http://check-host.net/check-dns?host=www.xyz.com to test our DNS resolution.

It seems always working fine world wide. My conclusion is that mostly is that the Local ISP providers DNS resolver screwing up when one of the above Hops fails to resolve. nslookup fails on these client computers only for our website and that too sporadically.

Is this kind of multi level CNAME a bad design in general ?

Jatin
  • 217
Vishal Naidu
  • 247

3 Answers3

17

Is this kind of multi level CNAME a bad design in general ?

CNAME to CNAME chains are not forbidden but as you already experience it is not a very robust solution.

Each additional CNAME increases the recursion depth for the resolver, and that depth is not always unlimited. Also you run the risk of creating loops, or triggering the loop detection algorithm.

To get an impression of how many and which queries a your users name server needs to do, run a DNS trace:

dig +trace www.example.com

or on Windows

nslookup -debug www.example.com
Community
  • 1
HBruijn
  • 84,206
  • 24
  • 145
  • 224
14

HBrujin is correct, but in truth recursion depth is a lot worse than anything dig +trace is going to show you. Recursion depth is something that often gets sneered at and over-trivialized, but those people forget that you aren't just resolving ~5 CNAME records. This is because resolving the target of a CNAME record creates a need to look up every nameserver in the path, which is frequently many more than are apparent at first glance.

Does the CNAME target live in another domain? You'll need to recurse into its nameservers, which requires not only NS record lookups but also A(AAA) lookups where glue isn't present. Do the nameservers for those nameservers live in a different top level domain? If those TLDs don't share nameservers, chances are the glue records won't be included and you have to recurse through the other TLD's nameservers as well. And so on.

Every CNAME record added to the chain can add exponentially to the number of lookups required depending on the number of nameservers that need to be recursed through. These chains of CNAME+NS+A(AAA) record lookups can in turn get insanely convoluted, reaching well over 150 levels deep on an emtpy cache. This is where recursion depth limits can get extremely nasty, resulting in temporary failures to look up your domain on an empty cache, and for reasons that are often not immediately apparent.

In short, you can do this, but proceed with caution, and take feedback of this nature seriously. You have no control over how frequently recursive DNS servers on the internet are restarted or purged.

Andrew B
  • 33,868
0

Multi-level CNAMEs are often handy in practice. Each level of redirection provides a level of control in a potentially distinct administrative zone or an entirely different organization. While this is hardly every technically necessary it can work around organizational problems.

As other folks have noted this can cause difficulties, but these can be addressed:

  • monitor all of the DNS servers. Maybe one is malfunctioning. Monitor external servers as well as your own. You may need to report an issue to Akamai or other vendors.

  • TTLs should be set high enough to allow caching but low enough that you can shift traffic fast enough for your application

chicks
  • 3,915
  • 10
  • 29
  • 37