Back when google first released their and dns servers I did some profiling, and they are way faster for our location. A more recent test confirms this is still the case. However, after careful consideration I declined to make the switch away from our ISP DNS, because looking at a few snapshots of our traffic, so many of our requests were for cdn addresses. Using a central DNS for lookups to CDN sites can produce results that work (and produce the results quickly), but make things slower because they might return less-optimal nodes.

My question, then, was if it was possible to use somehow distinguish CDN network and point those look-ups to my ISP DNS, but point normal look-ups Google's DNS.


When you profiled, did you profile through your existing AD DNS server - comparing with the AD DNS forwarders being set differently between your ISP and Google? Or did you just directly profile your ISP and Google's DNS?

What I'm getting at, is that if you already have a local DNS server in place (AD, BIND, or otherwise), and if all your clients are using that local, forwarding DNS server - as long as the local DNS server is configured properly, it will cache upstream results. So only the first DNS query for a given resource name within a reasonable TTL time will need to be forwarded outside of your network for resolution. With this in mind, can't you just use your ISP's DNS as the configured forwarded server to resolve external results while benefiting from localized results - understanding that everything will be cached?

  • I profiled directly, as going through the AD server would have returned cached responses, throwing off my results. The trick here is that cdn's seem to move nodes around to different IPs a lot, and thus you can still have quite a few lookups. But since I'm wanting to use my (slower) ISP dns for those cdns anyway, I guess I really have nothing to gain here. It would be slow in the cdn cases anyway, and my local cache will make up for it elsewhere. – Joel Coel Jan 26 '12 at 15:51

This is just split-horizon DNS service at a proxy DNS server, which is fairly simple in the straightforward case.

  • For a forwarding proxy DNS server one simply uses conditional forwarding. Consult your DNS server software's manual for how to do conditional forwarding. djbdns, Microsoft's DNS server, ISC's BIND, my DNSFCPD, and several others can all do conditional forwarding.
  • For a resolving proxy DNS server one uses whatever delegation override mechanisms the server software supplies. For djbdns, one adds a file to the servers/ directory. For ISC's BIND and Microsoft's DNS server, one uses stub zones.

The problem is that CDNs are not straightforward cases and you are preparing a perpetual maintenance headache for yourself.

Sometimes CDNs use rather lengthy alias chains. There's no way for you to know where in the chain the CDNs distribution information is encoded, because every CDN is free do to this in its own way.

For example: www.microsoft.com. is an alias for toggle.www.ms.akadns.net. which is an alias for g.www.ms.akadns.net. which is an alias for lb1.www.ms.akadns.net. which maps to the IP address You could do the prune-and-graft at microsoft.com., g.www.ms.akadns.net., www.ms.akadns.net., ms.akadns.net., or akadns.net.. But you don't know which is the appropriate place without knowledge that is both specific to that one CDN and not even necessarily known to you in the first place. Get it wrong, and you're back with the problem of the back-end queries coming from a third party's IP address, and the DNS data being appropriate for that address not for yours.

Moreover, Akamai is free to change all of those intermediate domain names, ten minutes from now, without any requirement to inform you about it so that you can reconfigure your split-horizon overrides. And it's free to do it all over again tomorrow. Multiply that by all of the different CDNs that you intend to use split-horizon DNS service for, and you have a huge Red Queen's Race ahead of you.

In any case, as others have pointed out, it's not really a good idea to use third-party, contractless, external, advertiser-funded, promiscuous proxy DNS servers in the first place. People wouldn't dream of handing over to advertiser-funded, contractless, external third-parties for proxy HTTP service, or SMTP Submission service. Proxy DNS service is little different, and the same rationales apply. What you are wanting to do is actually a fairly bad idea.

If you want to make your LAN's DNS lookups perform better, work on that, instead.


This is one of those cases where the act of composing the question made the answer clear to me. I did not expect any dns server to be able to make this distinction automatically. I simply wanted to manually direct some of our network's most commonly requested cdn to the right place. To do that, I'd have to hand-enter the values somewhere anyway, and at that point I can also just do the lookups and place those records directly into our AD DNS server. Conditional forwarders would be better, but I haven't seen a way in AD to do that.

I'm gonna sit on this for a while, though, as there implications to doing this (ie, needing to frequently check that things haven't changed, check if it's still worthwhile to keep certain records, etc), and there may yet be a better way. In our case, we're a small college and so it's really mainly two cdn's that would matter: netflix and facebook. Those two each account for about 40% of our traffic by size and hits respectively, and having faster look-ups generally, with correct results for those two specifically, would likely be a noticeable improvement.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.