Confusion with DNS on Windows server and Sonicwall

Can anyone verify this? I am confused. If the Sonicwall looks to the Server for Internet DNS wont my clients A) bog the Server down and B) have no Internet when the Server is off?

If this isn't best practice, then what is? Am I already doing it right? Should the client DNS look to the Server AND the ISP?

Christopher Moran asked May 15, 2015 at 3:08 Christopher Moran Christopher Moran 39 1 1 gold badge 2 2 silver badges 5 5 bronze badges Side note, you shouldn't be using Google DNS as your upstream resolvers. Use root hints. Commented May 15, 2015 at 18:06

Is your DNS server public facing? For example, do you allow users on the internet to make requests to your DNS server? Do you have a domain name managed from that DNS server that needs to be available to the public?

Commented May 24, 2015 at 6:49

No on all accounts. The DNS server is for internal LAN only. Nothing is hosted for the public to see.

Commented May 25, 2015 at 10:36

4 Answers 4

Since the server is running Active Directory/DNS, the clients MUST have their DNS set to the server for proper domain resolution/connectivity to internal resources.

The key is to have the server's DNS service configured to forward all non-local queries to an external resolver (like Google [8.8.8.8; 8.8.4.4]). DNS traffic is so small that it shouldn't have any discernible effect on your server unless you have the cache set too low.

The server's network stack should be configured to look to 127.0.0.1 (or its local address) for DNS resolution, and the service configured with forwarders.

Insofar as the Sonicwall relates, you can set it either way. If you would like the Sonicwall to be able to resolve both internal and external FQDNs, then it will need to use your local server for resolution. If you only require external, then set it to your ISPs resolvers, or Google's.

answered May 15, 2015 at 12:17 106 4 4 bronze badges It's always nice to see a new user post a good reply. +1 :) Commented May 15, 2015 at 12:29

As JuxVP has already stated, any domain-joined Windows clients must have their DNS set to the AD server, otherwise many services will fail, especially authentication. All other internal clients should have their DNS set to the AD server if you want them to resolve internal names.

Additionally, the domain-joined Windows clients must not have any other DNS servers listed that can't resolve AD queries b/c Windows doesn't guarantee the lookup order. Ex: if you have the following configuration on a client:

DNS1: 192.168.10.10 (AD server) DNS2: 8.8.8.8 (Google DNS) 

then you will likely have authentication problems, unusual hanging, or other communication problems. This is b/c the client may query Google's DNS for adserver.domain.local and Google's server will respond with does not exist instead of a timeout. The client will only try the other server if the first one doesn't respond. If the client receives a does not exist response, it will give up and the lookup will fail.

answered May 25, 2015 at 19:01 Jens Ehrich Jens Ehrich 398 2 2 silver badges 7 7 bronze badges answered May 15, 2015 at 11:11 argentwolf argentwolf 101 2 2 bronze badges Can/should I have the Windows AD server DNS listed in the Sonicwall for name resolution? Commented Jun 5, 2015 at 16:22 No, name resolution in the Sonicwall should be configured with your ISP's suggested DNS server(s). Commented Jun 5, 2015 at 21:54

Since you work in the education sector, I recommend configuring your internal DNS server to forward all requests to OpenDNS. They offer special plans just for K-12 to adhere to CIPA compliance [0]. They also offer malware protection where requests for nefarious resources will be blocked.

With the above configured, set every host/device/etc. on your network to use your internal DNS server. Doing so will ensure your clients will successfully connect to each other internally and is especially important when running Microsoft Active Directory.

Next, configure all router ACLs and firewall rules to only allow outbound DNS queries from your internal DNS server to OpenDNS servers. The benefit of this is that some malware will attempt to perform DNS queries directly to public nameservers. This configuration ensures the request will go through your servers and ultimately OpenDNS where it will hopefully be caught. Any host found not utilizing the internal DNS server (firewall drop logs) should be investigated for misconfiguration or malware as this could be an indicator of compromise.

Finally, implement router ACLs and/or firewall rules to block access to your DNS server from the public internet.