Is there any downside to using a public DNS service like Google's 8.8.8.8/8.8.4.4 for corporate network DNS service, as in making it the network connection's DNS server for an AD DC? It seems like if there was not a downside everyone would prefer an easy-to-remember and Googlific service instead of the hodgepodge of ISP specific ones.
-
If a record is already cached at your ISP, it's going to be a much shorter round trip in most cases... – ceejayoz Dec 14 '11 at 20:32
-
2Are you sure you want Google knowing every single DNS lookup you do? Don't think for a second they don't collect that information and datamine it. Food for thought. – Chris S Dec 14 '11 at 20:40
-
@ceejayoz however, the expectation is that google has much more stuff cached than your ISPs nameservers. You might expect that the ISP is often faster, but much slower when it has to do the recursive query. google will probably have to recurse much less frequently. so its not going to be cut and dried as "local is faster" – stew Dec 14 '11 at 20:44
-
1@ChrisS What makes you think his ISP isn't also collecting that data (and using it for that oh-so-helpful "domain finder" they send you to rather than returning NXDOMAIN as God and Mockapetris intended) – voretaq7 Dec 14 '11 at 20:45
-
3For a Windows AD domain? Yes, there is a down side. – joeqwerty Dec 14 '11 at 21:40
-
1Active Directory requires lots of internal DNS records to function. Are you referring to just using public DNS as forwarders on your AD DNS server, or do you mean actually using public DNS instead of an AD-integrated DNS server? – Paul Kroon Dec 17 '11 at 21:47
-
I meant forwarders. – tacos_tacos_tacos Dec 17 '11 at 21:51
3 Answers
The big downside is that a lot of corporations run DNS zones that aren't publicly visible.
A big one for this are AD DNS domains. Such domains are frequently based in TLDs that don't exist (yet) such as .company, the .local DNS domain, and non-public sub-domains like ad.us.example.com. If you have a domained machine, it'll need the ability to resolve these domains in order to work.
Comapnies also tend to run split-DNS systems, where the inside servers have a different view of example.com than the public DNS servers. Some companies may have all of 9 externally resolvable addresses in a single domain but hundreds internally, which makes it feasable to hand-edit the few external-viewable resources in the internal-only DNS servers. peoplesoft-ha2.example.com
may resolve internally, but not externally.
And finally, many take advantage of sub-domains that aren't published to the Internet at large. Sub-domains like it.us.example.com, where the public example.com would have no glue records for the us. domain, but the internal DNS servers would have it.
![](../../users/profiles/3038.webp)
- 131,083
- 18
- 173
- 296
-
I understand, and I have only worked in a split-domain type of scenario before because most places do not want to expose AD domain tree to the Internet. But if your company owns domain.com, and your AD root is business.domain.com, does it really matter? – tacos_tacos_tacos Dec 14 '11 at 22:30
-
2Yes, You may open your entire domain to the Internet. Well behaved DNS servers will recognize you are returning private IP addresses when you shouldn't, but people trying to crack your network will work around that. And external DSN server is unlikely to return responses that resolve to private addresses, you may hide big chunks of your network from yourself. – BillThor Dec 15 '11 at 01:52
Personally I like to run my own DNS servers. Mostly this is because of the reasons sysadmin1138 pointed out (we run split-horizon DNS, with lots of internal zones), but also because I like knowing that I'm not subject to any strange behavior that materializes on the internet (Think about your home ISP -- I bet when you go to http:/www.this.domain.doesnt.exist.com/ they try to give you a "helpful" page, which means their DNS is returning something other than NXDOMAIN
for non-existent domains).
If you don't have any cause to run your own DNS server it's really a matter of personal preference:
Theoretically using the local DNS will offer a shorter round-trip time for queries, and be faster.
Practically the difference is maybe 1-200msec, and sometimes Google will be faster (like if they already have a record cached and don't have to go asking up the chain).
This is all personal opinion though -- it comes down to "Do what makes sense for you and your customers".
![](../../users/profiles/32986.webp)
- 79,345
- 17
- 128
- 213
-
Can't your upstream DNS still return something other than `NXDOMAIN` if you're running internal DNS, though? – ceejayoz Dec 14 '11 at 20:55
-
@ceejayoz Yes, *if* you configure your upstream DNS as forwarders. (I pretty much never do, maybe occasionally in datacenter environments. Commercial and residential ISPs here all do the "domain helper" BS.) – voretaq7 Dec 14 '11 at 21:00
Since you did clarify that you mean using public DNS as the forwarders, and I assume you currently use your ISPs for this, then there are only 2 downsides I can see.
First, as was mentioned, you may not receive NXDOMAIN records properly for non-existant domains, and instead be directly to helper sites. I don't believe Google does this, and I know OpenDNS does this, but has an option to turn it off, but it's worth a test for whoever you're looking into.
The other concern is having your search queries logged or otherwise seen externally, which is up to the business to determine if this is an issue or not.
That said, ISP DNS servers could also have these downsides. The only way around them is to run your own separate DNS server(s), which will be more servers to support, or just leave your AD DNS servers with no forwarders and have them use the root hints. The latter will almost certainly not perform as well, so it's probably not your best option.
I suspect it will come down to speed for you, in which case you should run some tests with a bunch of DNS lookups against several different options you're looking into to determine what seems fastest from your location.
![](../../users/profiles/34100.webp)
- 2,220
- 16
- 20