Something that's never made much sense to me is when environments have DNS servers which are publicly accessible (on the internet). This more often than not seems to leave them vulnerable to Cache Poisoning/Snooping/Amplified DoS attacks.

The only types of clients I could think of that use DNS servers externally for any good reason would be ISP's and the like What's the reasoning behind wanting to expose your DNS server publicly?


3 Answers 3


When talking about DNS servers, it is important to distinguish between recursive resolvers (those servers providing clients with name resolution services) and authoritative nameservers (those servers answering final queries from local zone files).

If you are talking about recursive resolvers (DNS caching servers), then, by all means, if an organization has an intranet, the recursive resolvers should be there, not on the Internet. And if the organization does not have a segregated Intranet or internal network, recursive resolvers that permit queries from a restricted set of sources are certainly a good idea. As you say, an ISP might have a case for a wide open resolver, partly because queries for non-public names aren't expected to be handled by such a server, partly because of the trouble of listing very large amounts of permitted IP addresses, and partly for historical reasons (it's the way it was always done in the past).

If you are talking about authoritative nameservers, then one good reason to have those servers out on the Internet is for excellent response time. Every single client who wants to reach your website, your email server, your SIP server, or pretty much anything else you can think of to offer by name under your domain name is sooner or later going to generate a query against your authoritative nameserver (except if the answer has already been cached). The response time of this server is going to impact the response time of every service you offer. You want that query to go to a responsive server in a well-connected hosting centre, if possible. If you don't have servers of your own in such places, outsourcing authoritative nameservice to a DNS provider is probably a good idea. These days, almost every domain registrar also offers outsourced authoritative nameservice if you want it. I exaggerate a little bit the importance of a very responsive authoritative nameserver, but you get the message.

Still on the topic of authoritative nameservers, I should note that at least one of the threats you mention, cache poisoning, is not applicable: an authoritative nameserver is configure to not answer queries from cache. As for amplification attacks (where spoofed packets are sent with a question, the answer is larger than the question, and this answer gets directed at a victim), the location of the nameserver (behind a firewall or not) isn't going to make a difference. To some extent the nameserver has to answer those queries no matter what or else client's aren't going to find the services under your domain.

A common configuration for organizations with intranets is split DNS: there are two sets of authoritative DNS servers. One set has the public version of the zone, and it belongs out on the Internet. The other set has the internal version (which probably has a superset of the contents of the public version) and belongs on the intranet. This case is pretty simple. The public authoritative servers are unable to accidentally leak any private DNS information because they don't have a copy of the internal zone file and they can't get one since they are out on the Internet. (Obviously this assumes your zone file deployment process won't ship an unsanitized zone file out to the public version of the server during an update!)


If you have publicly accessible IP addresses on your internal network, and you want people on the public network to be able to access those resources, they need access to your DNS server. Obviously, most things should be in the DMZ, but there might be partner connection or extranet inside the network that is allowed through the firewall to an isolated internal network. It would be a matter of wanting that information to be public; it's also possible its a misconfiguration.


In addition to Celada's answer, email servers that use DNS to perform AntiSpam operations (SPF, etc) should not use the same set of servers that the internal recursive resolver uses.

Many people who use outsource email, such as Postini, Microsoft Office 365, Proofpoint hosted PoD, etc are isolated by virtue of the outsourcing.

If you host email in-house, you should consider pointing edge SMTP relays (any anything that does an SPF or DKIM check) to any DNS server other than the internal recursive resolver.

  • 2
    Why not use the same set of DNS servers?
    – Matrix
    Feb 27, 2013 at 9:41
  • @Matrix If there is a vulnerability with the internal server, a malicious dns query could expose that via a email... enabling cache attacks, etc Feb 16, 2017 at 3:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .