Can I have multiple DHCP and DNS servers in my domain?

No this will not work. First, By definition, a machine needing an IP address from DHCP ddoes not have one, therefore it acquires one via broadcast. Your statement that you can direct these machines to get their IP address from the Fortinet just can't work; you cannot dictate which DHCP server a machine uses on a machine by machine basis.

Secondly, introducing non-AD DNS servers into an AD domain is always trouble. You will break more than you fix.

SBS DHCP and DNS are perfectly capable of hosting windows and non-windows machines simultaneously. You just need the proper configuration. Stick with your other question and work that solution through to completion and you'll be fine.

-Cliff

if you had windows 2008 server R2 with clustering you could

the only thing you can do is to forward the dhcp requests of your router to your server

The answer to the question in the title is yes - you can have more than one DNS server and more than one DHCP server in your domain, and even on the same local network.  Multiple DNS servers in one network are quite common (so that name resolution will still occur if one server goes down).  Multiple DHCP servers in one network aren't as common because of one important gotcha: you can't have more than one DHCP server on the same network using the same scope, for the reason given by cgaliher above.  Putting multiple DHCP servers on the same network requires splitting the scope between them.  (The exception would be a clustered DHCP server, but that's not at all what you're looking for.)

Don't set anything in your network to use your router for DNS.  The router doesn't know anything about your domain, so machines querying the router aren't going to get the correct responses.

You CAN have multiple DHCP servers on the same LAN. But they would send the same response to the clients.
MS WIndows servers require AD for this feature (the DHCP database is then in AD.
ISC dhcpd servers (Linux, Unixes) can use "failover server".
But once again, you can't have different/overlapping sets of data for the various DHCP servers in a single LAN.

One mitigation factor though:
You can adapt the DHCP answers to the kind of DHCP request they receive.
And for what is related to the original post, it seems that filtering on the VENDOR-CLASS in the DHCP requests could do the trick.

I don't know how you could send different "DNS" values to non-Windows DHCP requests using the "Microsoft Windows"vendor-class. At least with MS DHCP server. Easier with ISC dhcpd server.

With Windows servers, one way could be to use a custom user class for Windows clients and assign them the DNS settings they require, while all the other clients would receive some DNS settings.

This is described here:
http://www.techrepublic.com/article/use-dhcp-class-to-deny-internet-access-to-unauthorized-machines/5498436

(Don't be afraid, even if this is made for Windows 2000, it should be exactly the same for more recent Windows)

23asd

Sorry for that last "cat on the keyboard" comment. Accident.

I took cgaliher's advice in 10/17/11 01:03 PM, ID: 36980775 and pursued getting SBS to see my DHCP client in DNS. The super experts at EE, especially aoakeley,  helped me resolve my initial problem: https://www.experts-exchange.com/questions/27421846/How-to-get-DCHP-entry-into-DNS.html. BUT, to the specific issue at hand ...

So, I see and understand that I cannot have multiple DHCP servers. Okey dokey.

Since the SBS server is running AD, does it *have to* be the DHCP server also? Are these services tightly coupled and have to go hand-in-hand?

Does the SBS server *have to* be the DNS server? What if some other host were the DNS server and SBS was pointed to that host for DNS name resolution (after all, it's getting domain-external DNS entries from the gateway and upstream)?

If SBS served neither DNS nor DHCP then the other DHCP server would assign IP addresses and the other DNS server (not necessarily the same as the DNS server) would stick the IP/hostnames into its DNS list without needing the complex configuration explained in my question-post above. SBS would then simply be able to pick up the IP/hostname from the other DNS server like it does for the other billion hosts on the planet. I have no plans on experiementing with this now, but I might consider this as a simpler configuration alternative in the future for mixed Windows/non-Windows enviroments.

Stringing questions is considered bad form, and your "does windows need to be the DNS server" is a new question, in comparison to your initial question here.

But the short answer is yes. More accurately, in an active directory domain, a domain controller needs to answer DNA queries for AD to work. Which means while you could technically not use SBS, you can't just prop up a 3rd party appliance or Linux box, or use your ISPs DNS servers. It'd need to be a windows DC, and therefore have the same DHCP integration requirements and setup you have with DNS on the SBS box.

-Cliff

DHCP server does not need to run on your SBS/DC server
But if you want multiple DHCP servers (YES THIS IS POSSIBLE!), the DHCP service must run on some computers that are all members of your AD domain.
You will have to authorize each DHCP server in AD.
This results in the DHCP configuration, to be stored in AD.
Then, multiple DHCP server can use it, and this will not be a problem because ALL the DHCP servers will answer the same to DHCP requests. When a DHCP request is emitted, you do not really care where the answer comes from as long as the answer is the one you expect.
Having multiple DHCP servers integrated in AD is a common way to prevent SPOF with DHCP.
(See, I am answering only the initial question... And cgaliher answered your DNS as DC question anyway)

Some of the information above is incorrect.  Authorizing a DHCP server does not result in the DHCP database being stored in AD and shared among all authorized DHCP servers in the domain.  AD-integrated DNS works this way (for the most part), but DHCP does not.  If you authorize multiple DHCP servers in the domain, each DHCP server still has its own database, stored locally; there is no replication of these databases among the servers.  The authorization process is intended solely to prevent rogue DHCP servers from running on the network (although it really only prevents rogue Windows-based DHCP servers from running, as other vendors' DHCP services won't likely use a compatible startup sequence).

The original point still stands: having multiple DHCP servers on the same network using the same scope is a Bad Idea because you can't control or predict which server will respond to a client's request.

cgaliher: I do not think I'm stringing questions. The original question was "Can I have multiple DHCP and DNS servers in my domain?" The general consensus to this question was "theoretically yes, but not a good idea." Therefore, given that resopnse, my "new" question (if you can call it that) is "does one of those servers *have to be* Win SBS?" This seems like a logical follow-up of my original question based on responses and would not make much sense in a separate post without the current thread's responses. If the rest of the commentors disagree, I will be happy to post a new question.

vivigatt: > But if you want multiple DHCP servers ..., the DHCP service must run on some computers that are all members of your AD domain.

OK, then, even if I have ONE DHCP server (which is fine), it must be a member of the domain, right?

DrDave242: > multiple DHCP servers on the same network using the same scope is a Bad Idea ...

OK, I get it. ONE DHCP server in the domain. So shall it be!

> Authorizing a DHCP server does not result in the DHCP database being stored in AD and shared among all authorized DHCP servers in the domain.

So, therefore, are you saying that the DHCP server *must* run on the AD server? vivigatt is mistaken in saying that it can run on any domain member computer?
 

No, DHCP doesn't have to run on a DC or even on a member server.  You can run it on a standalone (workgroup) server if you must, or even on a router or other device.  Only a DC or member server can be authorized in AD, but authorization is not mandatory.

The main issue DHCP-wise is that the DHCP server needs to configure its clients to use the correct DNS servers.  And speaking of DNS, at least one of the DNS servers in your domain should be a DC, so for all practical purposes, the SBS server does need to be a DNS server.

Great feedback! Sooooo .... *if* I had a non-AD DHCP server, and my DNS server is, in fact, also the AD server. Is the AD/DNS server smart enough to put DHCP clients into its DNS? For that matter, is the DNS server running on the AD server smart enough to resolve the DNS entries from another, non-AD DNS server (as vivigatt implies)?

Here's the thing: if the DHCP server is running on the AD / DNS / Domain server, then it must provide AD credentials to the DNS server (running on the same host) or it will NOT put non-Domain DHCP clients into the DNS. This I verified via the question posted in 11/02/11 04:11 PM, ID: 37072715, above. However, if I am using a non-AD DHCP server, then it knows nothing about credentials, so a) will the AD DNS server pick up non-AD DHCP client IPs? b) a 2nd, non-AD, DNS server might very well get the non-AD DHCP clients in any case; would the AD DNS server resolve from there?

What I am thinking is that, instead of having the domain controller do DHCP, AD and DNS, is to have a non-AD DHCP controller for the whole LAN servicing both AD and non-AD clients, and letting the DHCP client IPs either directly get to the AD DNS, or let the non-AD DNS get them, and let the AD DNS get them from there.

Last posting on this thread! I'll take whatever feedback I get and consider my curiosity satisfied.

Sooooo .... *if* I had a non-AD DHCP server, and my DNS server is, in fact, also the AD server. Is the AD/DNS server smart enough to put DHCP clients into its DNS?

If the clients are domain members, they will register their own records without relying on the DHCP server to do so.  This is assuming you have an AD-integrated zone configured to only allow secure dynamic updates.  If the clients are not domain members, they won't be able to register their records unless nonsecure updates are allowed (which is not the best idea from a security standpoint).

However, if I am using a non-AD DHCP server, then it knows nothing about credentials, so a) will the AD DNS server pick up non-AD DHCP client IPs? b) a 2nd, non-AD, DNS server might very well get the non-AD DHCP clients in any case; would the AD DNS server resolve from there?

a) Only if nonsecure updates are allowed.
b) If nonsecure updates are allowed, the clients can register directly with the AD server, but if not, their records will not be registered.  It is not possible to configure an AD DNS server to accept a zone transfer of an AD-integrated zone from a non-AD DNS server, because all AD-integrated zones are treated as primary zones on the AD server.  And if that non-AD DNS server is hosting the same zone, it must be configured as a secondary (non-writable) zone on the non-AD server, with zone transfers set up to occur from the AD server to it.  Records that are registered on the AD server will replicate (transfer) to the non-AD server, but it can't happen the other way.

DrDave242: Excellent info! I'm sorry, I said that would be my last question, but your response has prompted another: hosts outside the local domain, yahoo.com for example, can be resolved by the AD DNS yet they are not AD integrated. If non-secure updates are not allowed, how does the AD DNS distinguish between hosts outside the building and non-AD DNS's on the local LAN? Why isn't a DNS a DNS? Is is because the non-AD DNS host entries would have the AD domain name, e.g.  hprs.local?

Ah, so the fact that my non-AD hosts are wanting to use the hprs.local domain name, which is the Windows AD domain, is the issue! If these were some other domain, such as other.things, and I had another DNS controller on the LAN that which resolved these, and the AD-DNS also pointed to this other DNS, then it would be able resolve the non-AD hosts as e.g. thishost,other.things ... as long as they are not part of the AD-DNS zone, right?

This would work only if the DNS for other.things accepts non secure dynamic updates.
And the non-AD computers must also use the DNS for other.things and not AD-DNS.

You can also configure your AD-based DNS to accept non secure updates, then the non-AD computer can "add" their entries into the DNS (and actually, any computer can, as long as they get a, IP configuration within your subnet and with the AD-DNS).

Yes, you are correct.  If your non-AD hosts are using the same DNS suffix as your AD domain, those machines won't be able to register their host records in DNS because they can't authenticate on the domain; therefore, other machines that query the AD-integrated DNS server for those hosts won't be able to resolve them, because the server won't forward the query (since it's authoritative for the zone) and will simply return an NXDOMAIN response.

As vivigatt says, allowing nonsecure updates will allow the non-AD hosts to register their records, thereby allowing other machines to resolve them.  This is a less secure configuration, of course, and it's up to you to decide whether it's worth it.

Thanks for all the feedback. This question will make a great reference for me in the future.