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.