It it a good idea for a windows server to be running DNS services?

jmroberts70

2[H]4U
Joined
Oct 15, 2002
Messages
2,953
I'm working on building a new network inside an office of about 150 clients. The server administrator has setup their server to be the DNS server for the building. It's running Server 2008 right now with plans to upgrade to 2012 shortly. My question is:

1. Is it a good idea to do this? It seems to me that this should be handled by the router in the event that the server goes down. It also seems like it would be a hassle to have to manually configure each machine for this in the network settings.

2. Are there advantages or good reasons to "roll your own" DNS server when there are so many good ones out there to chose from? Is there maybe a performance benefit or a special function of Active Directory that needs this to work?

I have a suspicion that our server admin isn't that gifted with networking principles and may be causing more trouble than its worth.
 
Active Directory uses DNS right to the core. It's dependent on it.

There's absolutely nothing wrong with using a Windows DNS server. If you are worried about DNS lookups when the server is down, push a secondary external server in your DHCP leases.

You shouldn't be manually configuring IP settings on workstations. Do everything via DHCP including printer. Use static DHCP leases if you need a "static IP" on endpoint devices like workstations and phones.
 
Active Directory uses DNS right to the core. It's dependent on it.

There's absolutely nothing wrong with using a Windows DNS server. If you are worried about DNS lookups when the server is down, push a secondary external server in your DHCP leases.

That makes sense but is it worth the hassle of manually configuring every machine in the office this way? Is there some benefit to having local hardware running DNS services that make this worth it? I just don't see why it can't be set to automatic by default on any machine on the network and let the router do the work for you.
 
I have a suspicion that our server admin isn't that gifted with networking principles and may be causing more trouble than its worth.

You say a number of things that demonstrate marginal knowledge, so I wouldn't go blaming your admin. The DHCP server hands out the address of the DNS servers, you don't manually configure every machine.
 
Last edited:
I have a suspicion that our server admin isn't that gifted with networking principles and may be causing more trouble than its worth.
I have a suspicion that the server admin knows more about it than you do.
 
You say a number of things that demonstrate marginal knowledge, so I wouldn't go blaming your admin. The DHCP server hands out the address of the DNS servers, you don't manually configure every machine.

That's what I would imagine but this admin has dictated that each machine in the building be manually configured to point to the local server for DNS. We're running a PFSense router that is handling DHCP and is fully capable of handing out DNS information.

--I just don't see the point in serving DNS from a local server. Still, no one has explained how this could possibly be of use / benefit at all.

I have a suspicion that the server admin knows more about it than you do.

Well based on many of the interactions we've had, it seems like he's a good server desktop admin but doesn't know much about the networking principles that connect them all.
 
Try pinging the internal hostname of your server at work from home - it won't resolve an internal IP.

You need to run your own DNS to access local resources properly. Especially if you're running AD.
 
Last edited:
Try pinging the internal hostname of your server at work from home - it won't resolve an internal IP.

You need to run your own DNS to access local resources properly. Especially if you're running AD.

Ok, so that MAY be the need. If he's using AD, maybe he needs to run a local DNS server?
 
It's not a maybe. You do.

It also reduces network WAN I/O and dns query response time. The server keeps a cache so doesn't have to always query out to resolve names.

What's faster - asking the guy in the cubicle next to you? Or calling a friend in another office?
 
Ok well that settles it then. I'm really up on servers and AD in general so I really appreciate the info everyone. Thanks!!
 
Chances are with 150 clients they are running AD or at least I hope they are.

To not be using DHCP on his part is idiotic.
 
Chances are with 150 clients they are running AD or at least I hope they are.

To not be using DHCP on his part is idiotic.

I'm sure we're using DHCP controlled by the router. The issue is providing DNS services from a local server.
 
He means not having the DHCP server hand out the DNS addresses is idiotic.
 
This thread is an absolute trainwreck. How can you point and blame your network/server admin, when you don't even have a clue how a domain works?

Active Directory uses DNS right to the core. It's dependent on it.

There's absolutely nothing wrong with using a Windows DNS server. If you are worried about DNS lookups when the server is down, push a secondary external server in your DHCP leases.

You shouldn't be manually configuring IP settings on workstations. Do everything via DHCP including printer. Use static DHCP leases if you need a "static IP" on endpoint devices like workstations and phones.

This pretty much is the answer to this.
 
This thread is an absolute trainwreck. How can you point and blame your network/server admin, when you don't even have a clue how a domain works?



This pretty much is the answer to this.

lmfao agree....


have the server do DNS and DHCP, done and done....

it honestly sounds like the admin doesn't know how to either, 1. setup DHCP on the windows server....

or 2. change the DHCP options of the current router giving out the DHCP leases to allow your DNS server to be the DNS on all the DHCP machines..


you guys should call a professional... this is networking basics
 
I wonder why the DHCP server is not handing out the DNS addresses of the Windows server. Are there other systems that don't connect to that specific network which connect to the router? In other words, do you have multiple zones in your setup where some users have inside access while others simply have guest access?
 
I wouldn't say this thread is a train wreck. It's actually been educational. I don't normally work around AD networks so I'm unfamiliar with their needs. The server admin usually works on network infrastructure that's already setup so we both are somewhat ignorant of each others worlds.

Take away:
1. Running DNS internally is essential for AD.
2. Manually configuring this on each machine isn't a good idea.
3. Plug in the internal DNS server to the router's list of DNS addresses as the primary source. Probably throw in a couple extra external addresses for good measure if the internal server goes down.
4. Set all the general machines in the building to "Obtain DNS Server Automatically".
5. Enjoy good coffee.
 
an addendum to 3b, which i know somebody suggested... don't do it... it can very well cause problems with your AD...

ESPECIALLY in the aftermath OF an outage... yes it will allow your boxes to resolve your internet IPs, but when the server comes back up, all your machines have busted AD... and getting the client machines to latch back on to your primary DNS can be a pain

it kind of just comes back to proper server design... there isn't much to a windows AD/DNS/DHCP server, they're all super rock solid.... with these days and the modern virtualization stuff available, you should segment out your server dutys for other applications into VMs to keep all that core stuff stable...
 
Take away:
1. Running DNS internally is essential for AD.
Clarification; running your own DNS is required, but running windows DNS, on the domain controllers, is not. The only real requirement is that the DCs are able to update their own DNS records on the server. You can use any DNS server you want, as long as the DCs can update their records.

Ideally workstations too, but in actuality it's not required.
3. Plug in the internal DNS server to the router's list of DNS addresses as the primary source. Probably throw in a couple extra external addresses for good measure if the internal server goes down.
Actually, what should be done is that a second server be brought up and slaved to the master domain, then have both DNS servers be published via dhcp.
 
Clarification; running your own DNS is required, but running windows DNS, on the domain controllers, is not. The only real requirement is that the DCs are able to update their own DNS records on the server. You can use any DNS server you want, as long as the DCs can update their records.

you positive about this? because i think there is a lot more to windows DNS with AD... there are a bunch of special records and some proprietary stuff going on...


Ideally workstations too, but in actuality it's not required. Actually, what should be done is that a second server be brought up and slaved to the master domain, then have both DNS servers be published via dhcp.

yes, this is how you do backup DNS stuff.... don't just slap 8.8.8.8 as your tertiary name server on all your workstations...
 
you positive about this? because i think there is a lot more to windows DNS with AD... there are a bunch of special records and some proprietary stuff going on...
Positive. Windows isn't really doing anything proprietary with their DNS records, they're just fully exploiting the standards more than most other applications do.

Ran my AD domain on bind for years. Just made sure the DCs had the bind server has their DNS servers, and configured bind to allow those servers to issue record updates. Golden.
 
Ah ha!! Ok, it's starting to make more sense. We can build and bring up a second server to also provide DNS services and point to the primary server. This way there is no single point of failure in providing DNS services to the network --and I can plug BOTH servers IP's into my router to pass out DNS info and there won't be a problem re-establishing connectivity if the primary server goes down and comes back up later on.
 
Ah ha!! Ok, it's starting to make more sense. We can build and bring up a second server to also provide DNS services and point to the primary server. This way there is no single point of failure in providing DNS services to the network --and I can plug BOTH servers IP's into my router to pass out DNS info and there won't be a problem re-establishing connectivity if the primary server goes down and comes back up later on.

that's the desired setup, yes
 
Yes, proper way is to have multiple DC/DNS servers and only using those addresses in the DHCP leases.

I'm pretty sure one can use BIND with AD, but I've never done it. To me it makes sense to just use MS DNS and they make it super easy to setup and configure.
 
Yes, proper way is to have multiple DC/DNS servers and only using those addresses in the DHCP leases.

I'm pretty sure one can use BIND with AD, but I've never done it. To me it makes sense to just use MS DNS and they make it super easy to setup and configure.
It is WAAAY easier to simply stick with MS DNS/DHCP when running AD, no doubts.

However, sometimes you have to deal with managers with a chip on their shoulders. I walked into a 200 user environment with no centralized authentication ( local users only, baby. Local ADMIN users only. ). It was a year long fight to get AD approved ( they wanted to go with Novell because M$ is teh evils, you see ). I finally got them to agree to AD, but only if I could separate out such critical services as DHCP and DNS on to "more secure" linux boxes. Of course, they weren't running DHCP on most of their devices....but I digress.

Anyway, the short of it is; bind works just fine. Never had an issue with it after initial setup.
 
Active Directory uses DNS right to the core. It's dependent on it.

There's absolutely nothing wrong with using a Windows DNS server. If you are worried about DNS lookups when the server is down, push a secondary external server in your DHCP leases.

You shouldn't be manually configuring IP settings on workstations. Do everything via DHCP including printer. Use static DHCP leases if you need a "static IP" on endpoint devices like workstations and phones.

Is that really best practice not to give printers static ips? What you're saying is let them dhcp then set that lease as static? If you do it that way you will end up with printer ips all over the place. If you set them static you can keep them within a certain range.
 
Is that really best practice not to give printers static ips? What you're saying is let them dhcp then set that lease as static? If you do it that way you will end up with printer ips all over the place. If you set them static you can keep them within a certain range.
Static lease means you can define the IP address for the device.

You maintain control of it's address, but you gain the convenience of DHCP
 
Is that really best practice not to give printers static ips? What you're saying is let them dhcp then set that lease as static? If you do it that way you will end up with printer ips all over the place. If you set them static you can keep them within a certain range.

You give them a static lease outsie of your pool. You still control what IP they get.

IMO it is best practice. If you need to change DNS servers or gateway or subnet then it's super easy to change it only once on the DHCP server. Also useful for when the device resets itself magically (Looking at you HP printers) and goes back to DHCP from a static address.

I still set static IPs on switches, routers, servers, etc. I only use DHCP on endpoint devices like workstations, printers, phones, etc. If they need a specific IP like a printer, I add static leases for them.
 
That's what I would imagine but this admin has dictated that each machine in the building be manually configured to point to the local server for DNS. We're running a PFSense router that is handling DHCP and is fully capable of handing out DNS information.

--I just don't see the point in serving DNS from a local server. Still, no one has explained how this could possibly be of use / benefit at all.



Well based on many of the interactions we've had, it seems like he's a good server desktop admin but doesn't know much about the networking principles that connect them all.

Your comments demonstrate you have estimated your own knowledge beyond it's actual capacity.

http://www.psmag.com/navigation/health-and-behavior/confident-idiots-92793/

Go get some training, talk to that old guy and figure out why he has done the things he has, then come back when you know what you are doing.
 
You give them a static lease outsie of your pool. You still control what IP they get.

IMO it is best practice. If you need to change DNS servers or gateway or subnet then it's super easy to change it only once on the DHCP server. Also useful for when the device resets itself magically (Looking at you HP printers) and goes back to DHCP from a static address.

I still set static IPs on switches, routers, servers, etc. I only use DHCP on endpoint devices like workstations, printers, phones, etc. If they need a specific IP like a printer, I add static leases for them.

Yes, and deploy printers through AD/GPO.
 
Yes, and deploy printers through AD/GPO.
GPPs to be specific.

What did we do before Group Policy Preferences*?

* - Don't answer that. It involves custom vbscripts that polled group memberships then installed associated printers. It worked, but it hurt my brain maintaining it.
 
GPPs to be specific.

What did we do before Group Policy Preferences*?

* - Don't answer that. It involves custom vbscripts that polled group memberships then installed associated printers. It worked, but it hurt my brain maintaining it.

lol

Many terrible, tear filled hours in dark rooms.

I still get cold sweats over NT4.
 
Yes, and deploy printers through AD/GPO.

1000x this. We have roughly 200 printers deployed via GP. Adding a printer is as easy as adding them to the group. We even have it set to not install their printers if they log onto a computer in a different OU than their "home computer. "
 
1000x this. We have roughly 200 printers deployed via GP. Adding a printer is as easy as adding them to the group. We even have it set to not install their printers if they log onto a computer in a different OU than their "home computer. "
On that note, my users don't get printers. The workstations do.

Actually, the workstations are members of groups which get the printers installed ( in the user context though ).

When I tell new admins what life was like before GPPs, I feel like I'm regailing them with stories of walking to school, 10 miles uphill each way. In the snow. IN JUNE.
 
On that note, my users don't get printers. The workstations do.

Actually, the workstations are members of groups which get the printers installed ( in the user context though ).

When I tell new admins what life was like before GPPs, I feel like I'm regailing them with stories of walking to school, 10 miles uphill each way. In the snow. IN JUNE.

Lots of alcohol.
9/11x91100000

Making changes was like reinventing the damn wheel. Reboot, reboot, reboot, reboot...
 
Although I would go a different route than most of the replies provided on this thread, I would really advise to go with the technologies the OP and his/her team can support, research, and ask for assistance if something goes over their heads.

I tend to use Active Directory-Integrated DNS. I set the DNS forwarders on each DC to point the ISP's DNS (or whatever the preferred public DNS server happens to be that day...). DHCP is also on the DC(s). I sometimes use DHCP on more than one server, and use split-scope, depending on the request (I don't want to overcomplicate administration..) I use DHCP reservations (the other static ip address meat...) on peripherals such as printers. I separate DHCP scopes for different ranges (e.g., wireless devices for NPS, wired devices). I would not use static IP addresses on more than 10 network devices...that becomes annoying and hard to manage.

Also, GPP with item level targeting is quite awesome for mapped drives and printers. It makes it very easy to manage these annoying things. It's "usually" easier to support group policies than scripting languages, particularly if your techs don't have experience with such things.

Anyway, these are my "preferences," and use them as you see fit. Use whatever helps YOUR network.
 
Back
Top