I am a big fan of DDI (DNS, DHCP and IPAM) as magical trio to manage all transactions on network infrastructures… Or to say the least: make it possible.
Basically it makes these "Core Network Services" concise, manageable and integrated. It basically makes the network infrastructures of today and the future possible.
There is however one thing that continuously seems to irritate when talking about integrating these services on networks.
Let's have a look at the Microsoft DNS and DHCP, it's the most used, and has by far the largest footprint of them all. But is it "Integrated"? Seems to be with "Active Directory", but not so with IPAM as there is no real administration of "content" on Microsoft DNS/DHCP (just config and "records"). And Excel really doesn't count! :-).
If we look at Non-Microsoft DNS and DHCP, it seems to be more network/unix territory, and administering and configuring IP-Addresses seems to be more embedded due to historical reasons (maybe). IPAM is more of a common cause here.
So it would be logical, if one wants to apply the magical trio, to replace Microsoft DNS/DHCP, de-integrated it from Active Directory and put it closer to the network, right? (well, I would say yes, but lots of peoples are not convinced).
Actually there are a couple of scenario's that seems to appeal, but get little to no attention, let alone implemented.
Scenario 1: Let's replace the lot
Disable Microsoft DNS/DHCP and let Active Directory use the company wide DDI solution. This is actually no problem at all, and give lots of benefits. In most cases it actually gives Active Directory a boost in performance and all kinds of extra logging and statistical information. And of course integrated IPAM, which is key for any IP based network infrastructure and it's services nowadays.
Scenario 2: Delegate a Domain
Have a company wide DDI solution, but just delegate a domain to the Active Directory domain which will run on Microsoft DNS/DHCP services. So the "connection" is just DNS. You will loose some oversight (feedback) from the services. As long as there are procedures from the DDI team on handing out IP's and Names, it is a workable situation. Not perfect in my opinion.
Scenario 3: Integrate with the MS Services
Have a company wide DDI solution, have an Active Directory with their own Microsoft DNS/DHCP services, but manage both with the same DDI solution. This is very flexible and best of both worlds. It will have an added bonus: IPAM.
Scenario 4: No integration
Let everyone have their own island. Prone to lots of political and technical discussions. The biggest question here will be "Reverse Zones", who will own them… Good luck!
And there are many more, but I keep it by these 4 which seems to be most common.
There seems to be two camps revolving around this:
Camp 1: The Network / System Guys
They want an integral DDI solution, providing DHCP and DNS to the whole world, including Active Directory. Strong users of IPAM want all kind of neat features for failover, redundancy and disaster-recover. DNS and DHCP is a "Network Component".
Camp 2: The Microsoft Guys
They just want to do their own DNS and DHCP for Active Directory and really don't want to do anything else. Redundancy is fine (multiple servers, multi-master, etc). DNS and DHCP is an "Application".
There seems to be a lot at stake for both camps. Both will touch the core of networks. One from the bottom-up and the other top-down and can "boss around" when needed. It's a responsibility with power!
Both camps are also guilty (mostly because of knowledge shortage) by not understanding each other requirements and forgetting about the complete picture, trying to cover their own requirements. Making no decision seems to be more common in these cases. "Let it be" is mostly the outcome.
I think either scenario works, at least if integrated IPAM is part of it. IPAM is in most cases a missing part, out-of-date and disciplinary. Integrating all three components (DNS, DHCP and IPAM), respecting the infrastructure and requirements is the way forward and the way to build future proof networks.
And I have not even thrown in IPv6 and DNSSEC for added complexity! :-)
As said… An observation…
|Data Center||Policy & Regulation|
|DNS Security||Regional Registries|
|Domain Names||Registry Services|
|Intellectual Property||Top-Level Domains|
|Internet of Things||Web|
|Internet Protocol||White Space|
Afilias - Mobile & Web Services
.eco launches globally at 16:00 UTC on April 25, 2017, when domains will be available on a first-come, first-serve basis. .eco is for businesses, non-profits and people committed to positive change for the planet. See list of registrars offering .eco more»