Should engineering have its own DNS zone, delegate, or subdomain?
We have our organization's primary domain (with AD) example.com. In the past, previous admins have created several other zones - such as dmn.com, lab.example.com, dmn-geo.com etc - as well as subdomains and delegates all of which are for different engineering groups. Our DNS right now is a bit of a mess. And of course this causes problems when someone at a workstation in example.com needs to connect to a system in any of these other zones/subdomains, or vice versa (partially because zone transfer and delegation aren't properly configured for most of them).
Our production DNS is integrated with Active Directory, but engineering systems should be isolated from AD.
We're discussing ways of reorganizing DNS and consolidating all of these different entries. I see three different avenues we can take:
- Create a new zone i.e. 'dmn.eng'. This could either be managed by IT, using our DNS servers or engineering using their nameservers.
- Create a new delegate eng.example.com, consolidate engineering DNS into that subdomain, and let the engineers manage the nameserver for the delegate.
- Create a new subdomain eng.example.com with no delegation and manage DNS for the subdomain ourselves.
I favor creating a delegate subdomain and letting the engineers have full control over their own DNS structure within that subdomain. The advantage is that if their DNS doesn't work, it's most likely not my fault ;). However, there is still some ambiguity about responsibility when something doesn't work and it will require coordination with engineering to set up, configure, and administer.
If we do not delegate the subdomain, that means a lot more work for production IT handling non-production DNS (which we've essentially been doing a lot of already). The advantage is that we have full control over all DNS and when something doesn't work there is no doubt about whose responsibility it is to fix it. We can also add delegates, such as geo.eng.example.com, to give engineering more flexibility and control when they need it.
I am really uncertain about the necessity or benefits of creating a new zone, dmn.eng.
So what are the industry best practices and recommendations for situations like this? What solution would be the simplest to implement and provide seamless name resolution between engineering and production? What are some potential benefits or pitfalls to each solution that I may be missing?
To add a little more information, we're a fairly large manufacturing company. These engineers work in R&D, Development, and QA. Labs frequently have their own subnets or whole networks, DHCP, etc. In regards to organization and technology, they are kind of their own little world.
We want to maintain some level of network isolation for engineering labs and networks in order to protect our production environment (reference an earlier question regarding engineers who added engineering DHCP servers as authoritative AD DHCP servers - that should not be able to happen). However, a user at a workstation in a lab will need to access a resource in our production network, or a user at a workstation on our production network will need to connect to a lab system, and this happens with enough frequency to justify a sort-of unified DNS.
The existing delegates already have DNS servers managed by engineering, but there is no communication between the engineers in the different labs where these servers are set up, so the most common problem is failed name resolution between subdomains. Since the engineers own those delegate servers, I can't correct the NS entries to get them talking to each other - hence the advantage of non-delegated DNS wholly owned by IT. But managing DNS for production and engineering is a headache, especially as engineering can make DNS changes on a daily basis. But as BigHomie mentioned in his answer, this probably means engineering will have to hire (or designate) a real DNS admin; and that person and I will have to become fairly well acquainted.
I don't necessarily like the idea of creating a new zone with arbitrary an top level domain name or suffix either, but we already have 5 other zones with arbitrary names so consolidating into a single one is still an improvement. I do know that other companies exist that do have separate top level zones for different groups in their organization, so I'm curious about when that is appropriate and what the advantages/disadvantages of that approach are.
FYI, I've only been at this company for a few months and the previous AD/DNS admin left the company, so I have nothing to reference as to why any of the existing DNS structure exists.
In today's world, I do not recommend creating new zones with arbitrary top level domains, as these might make it into "official dns" at any point in time.
I personally would favor the subdomain delegation scenario, as it seems to be fitting what you try to do. (Consolidate but give control to engineering)
Maybe you can even find a web-front-end for MS DNS where engineering could add/remove records, so that the server itself is still owned by production IT, and the only thing "they" manage is DNS entries.
First and foremost, make sure you own the domain.tld you plan on using (mit.edu). Even if this never connects to the internet, that's not the point.
There are huge benefits to having a hierarchy of dns that at least somewhat matches the org. I've only seen this done when there is someone/people to manage that department in terms of IT support. This is in regards to having separate zones for the purposes of AD. Web addresses and etc are a separate topic and this won't apply to that. I don't have or know any hard and fast rules for dns hierarchy, I believe your org's needs will dictate that. Some zones may require a subdomain (eng.mit.edu) and some won't (hr.mit.edu, for example). Of course, there should be only one top level domain for consistency.
That being said, what determines whether or not an dept needs a subdomain or not? If this is for workstations, do they have their own IT support, or people capable of managing such a system? If not, there's really no point in using a dns zone to specify that a machine is in a certain dept, there are numerous other methods that will do the job just fine. These are just questions you'll just have to ask yourself.
I would re-evaluate each zone and determine
If it is still even relevant. Are there servers or workstations still pointing to anything in that zone?
Who will be managing the new zone. It goes without saying the zone will have to be migrated to your new hierarchy, but do you just implement a forwarding address/nameserver information for the zone, or will you actively managing the zone?
What systems are 'isolated' from AD? Will these not require network authentication and/or management? What's the reason for separating them from a DNS perspective? To confirm your suspicions, it's all about ease of management. If engineering needs that much dns administration, they should get themselves a DNS admin.
To add info based on your update, then I personally would give them their own subdomain, eng.spacelysprockets.com, and subnet as well. It should be firewalled from the rest of the network with the appropriate traffic allowed through. If they want to go off and create eng.eng.local or eng.bikes you can't stop them, nor should you be forced to support that*.
If they play nice use the subzone and decide they want to break off lab.eng.spacelysprockets.com and a portion of the subnet, that's on them. It should probably be professional courtesy to let you know so you can segment that traffic as well, but everyone doesn't think like that.
A real domain name for your infrastructure would seriously give you an advantage on management, you should consider it.
*Should you and will you are two different things, but I digress.