Back when google first released their 8.8.8.8 and 8.8.4.4 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 8.8.8.8 DNS.
This is just split-horizon DNS service at a proxy DNS server, which is fairly simple in the straightforward case.
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 fortoggle.www.ms.akadns.net.
which is an alias forg.www.ms.akadns.net.
which is an alias forlb1.www.ms.akadns.net.
which maps to the IP address65.55.12.249
. You could do the prune-and-graft atmicrosoft.com.
,g.www.ms.akadns.net.
,www.ms.akadns.net.
,ms.akadns.net.
, orakadns.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.
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?
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.