Do we need a DNS server when we use OpenDNS?

Question

I am in the process of splitting roles up from one server to 5.

The current server is running as a DNS server, among other things. The DNS server just has a forwarder to the OpenDNS IP addresses and the workstations have the IP address of the local server as their DNS.

I understand the benefit of having one role per server, but when I am dedicating an entire server to forward all requests to an external service - I wonder if it's required. Would I be better making the router go through OpenDNS and then setting each of the workstations DNS to the router IP?

I would be interested to know the 'norm' for DNS servers and if you think it's necessary for my situation. Maybe you would suggest software to run on the DNS server to mimic what OpenDNS is doing but gives me greater control? (i.e. no limitations to the number of exclusions or white list addresses.)

My Situation

~40 Workstations running Windows XP Professional SP3
4 Servers running Windows Server 2008 R2 (64-bit)
1 Server running Windows Server 2008 (32-bit)

1 PoE Managed Switch
1 Managed Switch

All workstations can access the internet but are restricted by the OpenDNS service.

---

Current Server Setup (HP ProLiant ML110 G6 Intel Xeon 2.40GHz - 1GB of RAM being upgraded to 5GB)

1 Server is running the following roles:

1. Active Directory Domain Services
2. DNS Server
3. File Services
4. Windows Deployment Services (not being used)

Planned Server Setup

HP ProLiant DL360 G4 Intel Xeon 3.0GHz - 4GB of RAM
Active Directory Domain Services

HP ProLiant DL360 G4 Intel Xeon 3.0GHz - 4GB of RAM
Active Directory Domain Services (Additional Domain Controller)

HP ProLiant DL360 G4 Intel Xeon 3.0GHz - 4GB of RAM
DNS Server?

HP ProLiant ML110 G6 Intel Xeon 2.40GHz - 1GB of RAM being upgraded to 5GB
File Server (because it's a tower and hopefully cheaper to add multiple hard drives.)

Answer 1

Are you using Active Directory ? If so you can't really use an external DNS server for internal users. Also it would be more beneficial for us if you update the question with specifics where each roles go and how you want to split it.

Basically if your environment works with AD you can't point your workstations to external dns servers as the workstations need to know how to find your AD controller, how to find each other, how to find other servers. Considering that you do have 40 workstations I presume you must be using Active Directory (otherwise it would be waste of resources not to).

Actually if you do have Active Directory on your server you can't set it up without DNS so if you're splitting roles up it should be something like (bare in mind I don't have knowledge what you have in your network):

1. Server 1 - AD/DNS
2. Server 2 - SharePoint
3. Server 3 - SQL
4. Server 4 - Exchange
5. Server 5 - 2nd AD/DNS -> if it's different physical machine, otherwise it won't matter as much as when the physical machine is down whole AD/DNS is down.

EDIT: considering your update

1. Server 1 - AD/DNS (primary)
2. Server 2 - FileServer
3. Server 3 - AD/DNS (secondary) - different physical server

Also since you seem to have some free space you could put SharePoint Foundation 2010 in your network and have nice little place for your users to share their work. It's really useful even in such small places. I do have similar setup and having Sharepoint as a central store for files is far better then simple FileServer (of course Fileserver has it's goodies - but SharePoint is good for working on documents - history of changes etc)

Answer 2

I would certainly recommend keeping DNS on an internal server; though with it's a lightweight and very stable role and with a network of your size, It's certainly not necessary to reserve an entire server for it.

The main issue here, is that you'll also need a DNS server that supports Dyanmic Updates for your internal network, since a lot of Active Directory requires it. (If you want to do this with a DNS that isn't Windows' own, then be prepared for a lot of pain.)

I suggest turning off the router DNS, enabling the AD-integrated DNS role on two of your servers (This will be full master/master, so you won't need to worry about replication) and ensuring both servers are passed to the clients by your DHCP server. You can still forward referrals to OpenDNS for the rest of the world.

This is probably the easiest configuration route and also gives your network an extra bit of resilience.

Answer 3

There is also a strong argument for having a local DNS server on the performance side. The DNS server caches lookups, and as users tend to hit the same FQDN often you can cut the connection time down significantly. As little as 50ms slower connections will start degrading the perceived performance of the network. OpenDNS is (in my experience) relatively fast, but there is little they can do about the transmission delay from their server to your network.

So, even if you use a service such as OpenDNS, having a local server to cache lookups gives you benefits.