In our organization, we have two separate groups which share network address space and a domain. A couple of slices of /24 are allocated to my group, while the rest is allocated to our internal IT team.
We do not wish to be able to manage DNS for their slice of the pie, but we need to be able to manage it for our slice.
The problem is that for political/historical reasons, which preceeded my tenure, we have set up a Linux based DNS server and maintained our own records and pointed all of our servers and equipment at this server. Meanwhile users and developers across the organization are pointed at the IT teams DNS server.
In order to make sure that everything works in all situations, we have to enter DNS records in our server and then put in tickets with our IT team to have records created in the Active Directory environment. This has come out of parity and is a management nightmare.
Furthermore, we have hundreds of servers and applications which use the shared domain.com
and having to create a subdomain.domain.com
and update hundreds of servers and applications is not preferred.
As such, is there a way to grant trust and permission to update records in domain.com
for only a handful of /24s inside of a /16? Third party solutions that bolt onto Active Directory are acceptable.
You surely have already noticed that DNS does not care about the subnets when it comes to management. The typical management unit in a DNS infrastructure is a "zone" which would correspond to at least one domain. So if you wanted to delegate management tasks, you would delegate administration over a complete zone, thus at least the complete domain.
Windows AD DNS servers do offer some additional access control and delegation abilities for single record entries - i.e. you would be able to set up "modify" rights for a given user or group for every single record within a zone without delegating the entire zone management. But none of the delegation and ACL features do include something like a "subnet" as a management unit, if you need to reflect this in ACEs, you would need to fix them externally.
This being said, it probably is not as bad as it sounds as Windows DNS ACLs also do have the concept of the "creator" of a record along with the ability to delegate only creation of new records in a zone without the need for permissions to change other zone-specific data or other records. The "creator" becomes the owner of the record and implicitly gets the right to change its permissions, thus it indirectly gains "full control". Additionally, the ACE for "CREATOR-OWNER" to be inherited upon creation of a new record can be explicitly defined on the container, if desired (but the implicit right to change permissions cannot be revoked). So the basic project outline might look like this:
I may be mis-reading this, but it seems like a scheduled task to run once or twice a day would work.
One example of code of how to access the zone and perform updates is here:
http://www.adamtheautomator.com/fix-dynamic-dns-record-permissions-automagically/
That code is to fixup orphaned dynamic DNS records, but it should point you in the right direction.
I can't speak to how Active Directory would be configured to allow you to remotely manage and automate the domain using
nsupdate
.What I can tell you is that you can reduce the headache somewhat by using
NS
delegations to each other for the individual records, and never defining staticA
orCNAME
records for data that your team does not manage.Imagine you have the following in Active Directory:
mail
,ns1
, anddc1
are statically defined records.www
andftp
have been delegated tons1.example.com.
, which we'll say is an authoritative Linux DNS server.www
andftp
will trigger recursion and causens1.example.com
to be consulted for the answer. This will succeed, provided that there is a firewall allowing traffic from the DCs to hitns1
.This is still a pain: you're not escaping the need to define records on the remote server. What you are accomplishing is ownership of individual records. If the IP address for one of those records needs to change, this change does not have to be made on both sides of the fence. This will work, at least until someone wants to define
sub.ftp.example.com
on the DC. Sinceftp
has been delegated,sub.ftp
has also been delegated and there is no way to manage it locally.