Windows DNS: Is there a way to partition a domain based on subnets

Question

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.

Answer 1

I may be mis-reading this, but it seems like a scheduled task to run once or twice a day would work.

• Read in the DNS records
• If the record IP address matches the criteria
• examine the security ACL for the ACE of a security group that manages the address
• Add the ACE if it does not exist.

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.

Answer 2

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:

• ask the AD DNS team for creation rights for new records in the zone for your group
• ask the AD DNS team to delegate the modification rights for resource records belonging to your group
• start creating and modifying resource records for your group in the AD DNS by yourself
• propose the creation of a frequently-run management script which would check that records created by your group comply with the delegation policy (i.e. point to hosts in your domains)
• re-configure your Linux DNS server to either simply forward queries to the AD DNS servers or to act as a secondary by pulling the zone's data off one of the AD DNS primaries (if the DNS zone is AD-integrated, all AD DNS servers will act as primaries)

Answer 3

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 static A or CNAME records for data that your team does not manage.

Imagine you have the following in Active Directory:

example.com. SOA dc1.example.com. hostmaster.example.com. 2015022400 28800 7200 604800 300
     IN NS dc1.example.com.
     IN NS dc2.example.com.
     IN MX 10 mail.example.com.
www  IN NS ns1
ftp  IN NS ns1
mail IN  A 198.18.0.10

dc1  IN  A 198.18.0.150
ns1  IN  A 198.18.0.250

• mail, ns1, and dc1 are statically defined records.
• www and ftp have been delegated to ns1.example.com., which we'll say is an authoritative Linux DNS server.
• Because the DC is typically acting in a mixed DNS server role (both recursive and authoritative), requests for www and ftp will trigger recursion and cause ns1.example.com to be consulted for the answer. This will succeed, provided that there is a firewall allowing traffic from the DCs to hit ns1.

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. Since ftp has been delegated, sub.ftp has also been delegated and there is no way to manage it locally.