DHCP on AD or not?

Hi everyone, I need some clarification regarding the configuration of nethserver as AD. I have a neth7 configured as AD in production, and almost all machines are credited to it. During the first installation phase I enabled the dhcp not on the AD server eg nscd-myserver.ad.local.lan but on the local.lan domain. So I find myself distributing ip with suffix local.lan but not ad.local.lan. I ask if it is appropriate to entrust the dhcp server to the ip in bridge and then to the domain ad.local.lan or leave everything as it is. I hope I was clear. Thanks


This is OK, it’s what I’m using for all my clients - and it works! :slight_smile:

My 2 cents

Thanks Andy, so you too use the only dhcp managed by the neth7 server and not the AD service. But in the question in your opinion is it correct or not?

I’m using the AD in NethServer, and the DNS Server in NethServer, yes.
The AD has ad.site.domainname.ch, my DNS uses site.domainname.ch.

I don’t think even Microsoft has the competence to answer that!
Microsoft “raped” DNS to fulfil AD requirements, instead of using SLP as a resolution for AD.
In any AD, you’ll see subcontainers only visible in an AD DNS.
This is NOT official DNS!

But: DNS serves the purpose of Internet Domain Name Resolution.

AD is for Auth, and misuses DNS to inform the clients which Servers are AD relevant.
AD is NOT and has NEVER been a “name resolution service”.

As proof that MS doesn’t quite understand:

  • MS at first said use XXX.local
  • Later on they said use AD.XXX.local
  • Now they say use AD.domeinname.tld

Microsoft does not really have budget problems, yet with their 4 DNS Servers, (And several Internet Providers for redundancy) put all 4 DNS Servers (In 1999 or 2001?) behind the same gateway / subnet. Someone made a typo in the router config, and Microsoft did not exist anymore on the Internet. This lasted 3-4 days!

This proves MS do not understand the simple technologies DNS uses to mitigate from this, like mandating that DNS should be in different subnets. MS didn’t follow this.

One example: If you use ad.domainname.com and are running an Exchange server, the exchange server will have a name like exchange.ad.domainname.com.
Now, the SMTP service in Microsoft Exchange will use that (non valid Internetname) as it’s helo…
You will not be able to send most mail, until that name is resolveable on the Internet.
So you’re forced to either correct the SMTP helo, or do what most do: use ad.domainname.com also on the Internet - just to allow their Exchange to send mails. Some will use an external smarthost, also not a real solution, but a workaround.

MS does say the name ad.domain.com should not be visible on the Internet…

-> I do think I know more about DNS than MS, yes!

My 2 cents

1 Like

Thank you, Andy, as usual, very comprehensive in your explanations. It is now clear to me how best to use what is written in my post.

1 Like



In 25 years, and countless AD systems I have setup, I always used the real domainname, NEVER anything like .local or .lan.

Microsoft suggested using those, so MS Users would still be able to access their mostly external Website…

Instead of instructing their users to create in an entry in DNS like this, where is the IP of their external Web hoster:

*.domainname.com IN A
www.domainname.com IN A

The above two are and always have been valid DNS entries, as according to BIND entries.

My 2 cents

1 Like