12

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
  • 197
  • 9
Vishal Naidu
  • 227
  • 2
  • 5
  • 1
    I worked for Akamai a few years ago, and one of our customers reported that a certain router had a problem with 5 levels of nesting. I think the router firmware was eventually fixed. – Barmar Aug 23 '16 at 18:30

3 Answers3

16

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
  • 72,524
  • 21
  • 127
  • 192
12

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
  • 31,858
  • 12
  • 90
  • 128
  • My client software sits on a bunch of machines making remote http calls. Will it be fair then to retry all CNAMEs from the client reducing the recursion depth \ load on the resolver? Does this sound a good approach or am i missing something ? I know that the CNAMEs won't change across geographies. – Vishal Naidu Aug 24 '16 at 00:00
  • Not a good approach. Typically the server that failed to look up the data is going to temporarily cache the failure. The query might succeed again in the future (say, 5 minutes from now), but it is unlikely to succeed on an immediate retry. If you provide the name of your DNS record, I can let you know whether this is really a recursion depth issue or something less obvious. I'd hate for us to be going down the wrong rabbit hole. – Andrew B Aug 24 '16 at 00:05
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,639
  • 10
  • 26
  • 36
  • 2
    I'm not sure I understand the monitoring recommendation. Not only do recursion depth limits vary from product to product, how do you propose to monitor for them? You can't easily identify root cause for someone else's recursive infra. – Andrew B Aug 24 '16 at 00:07