Windows Server : Integration between DNS and DHCP

아티클
1/17/2024

Introduction

For any large organization with lots of servers, workstations, appliances, and devices, DNS and DHCP both are very fundamental and crucial components.

**The purpose of this article is to highlight some often overlooked areas, which are related to integration between DHCP and DNS. **

As DNS and DHCP both are the backbones of organization’s IT Infrastructure, changing any setting in a production environment might cause a severe impact. Due to this, the integration between DNS and DHCP should be planned well before implementation and should be part of Infrastructure Design Document.

This article assumes a few things:

You are using Active Directory Integrated DNS.
You are using Windows DHCP Server.

DHCP-DNS Integration: The Basics

Before we dive deeper, let’s jot down the basic rules of DHCP-DNS integration.

As we know, DNS records can be Static or Dynamic. Static records are created manually, either through DNS console or programmatically using some script. Dynamic records, on the other hand, are registered by DNS Client or by DHCP Server.

When DHCP is implemented, by default the PTR Records are registered to DNS by DHCP Server, whereas the Host (A) records are registered by DHCP client. This is due to the fact that client is the source of the hostname and DHCP is the source of the IP address.

From Windows Server 2008 / Vista onwards, it is DHCP who registers both A and PTR records on behalf of client, regardless of client is requesting DHCP server to perform the update or not. Of course, if the IP address is statically assigned to client, there is no role of DHCP and it is client who updates the record in this case.

As a best practice, we should ensure that it is DHCP who should update both A and PTR records for all clients which are getting IP address from DHCP.

To ensure that, please select this option: Always dynamically update DNS A and PTR records.

If this option is selected, DHCP server would update A and PTR records as soon as it assigns an IP address to a DHCP client, and it will not check whether client is asking DHCP server to register/update the DNS record. We always recommend using this option.

If the IP address is manually assigned on a system, and not assigned by DHCP, then that record is registered by the system itself. In a production environment, most of the critical servers are having an IP address assigned directly and not through DHCP. All such records would be registered to DNS by the system itself and there is no role of DHCP in this case.

DHCP-DNS Integration: Deeper Drive

Now that we know the basics, let’s take a deeper drive.

An AD Integrated DNS Zone offers three different security settings which are associated with Dynamic DNS update (DDNS) :

None: Dynamic update is not allowed and all records need to be updated/managed manually.
Nonsecure and Secure: This setting will allow all dynamic updates, without verifying the authenticity of the source from where update request is coming.
Secure Only: This setting will allow Dynamic update only if the authenticity of the source is verified by Active Directory. In other words, the source should be a member of the “Authenticated Users” security principle.

Note

**Secure only option is only available if the DNS zone is AD Integrated. **

As option 3 offers an additional layer of security and ensures that the DNS update request is coming from an authentic source, most of the organizations prefer to use this option.

When we configure option 3 (Secure Only Dynamic update), there is another important point that we need to consider, which is DNS record permission (ACL).

When the Dynamic update setting is configured as “Secure and nonsecure”, there is no record specific ACL, and all records inherit ACL from the DNS Zone. In this setting, any source can create a new record and also update an existing record.

However, things get changed when we change the settings to “Secure only”. In this setting:

Only authorized source, which has access to create a new record, can create a new record.
When a new record is created, the creator becomes the owner of that record, having special permission to the record so that it can read and modify the record.
Next time, only that owner can update/modify that record.

Let’s assume a scenario where an IP address is directly assigned by Server1, and it is not assigned by DHCP. So Server1 will register the record in the DNS Server and will become the owner of the record. Next time, only server1 can update this record if we change its IP address. There is no role of DHCP here.

Please note that as the zone accepts only secure update, Server1 must be a member of AD Domain so that it can register/update the record in DNS server.

Now, let’s assume we have a workstation named WS1. The IP address is assigned by DHCP Server A, so the DNS record will be registered and owned by DHCP server A. No other system, including WS1 or any other DHCP server, can update this record.

Introduction to DnsUpdateProxy Group

There is a major drawback in the approach, where a single DHCP server is becoming an owner of a huge number of records. What happens if the original DHCP server fails, and we deploy a new DHCP server?

Can the new DHCP server update all records which were registered (and owned) by previous DHCP server?

The answer is NO.

Let’s assume DHCP Server A registered 5000 records in DNS Server, and then for some reason, it crashed. We have commissioned a new DHCP Server, which is DHCP Server B. But DHCP Server B will NOT be able to update those 5000 records which were registered and owned by DHCP Server A. Even if we rename DHCP Server B to DHCP Server A, the issue will not be resolved as ACL works through SID, and not by hostname. The computer account SID of DHCP Server A and DHCP Server B will never be same.

Microsoft offers a solution to this problem. There is a built-in group called DnsUpdateProxy, which can be (and should be) used in this scenario.

How to use DnsUpdateProxy Group

Step 1: The first thing that we need to do is to put DHCP servers within the DnsUpdateProxy group. Please note that this is a Global Security Group, so it will not allow adding any DHCP server which is not in current domain.

Step 2: Now create a user (service) account in Active Directory which would be used by all DHCP servers during a secure dynamic update. Please name the account something like <dhcp_update> so that we can understand later the purpose of this account.

This account should be created in the same AD Domain, where we have added the DHCP servers in the DnsUpdateProxy group in step 1. However, Microsoft confirms that it is possible to create the account in a different forest if forest trust is configured.

Step 3: The next step is to configure this user account and credential, which we have created in step 2. This credential would be used by all DHCP servers to securely register the record in the DNS Server. This needs to be configured in each DHCP server, which we have added in the DnsUpdateProxy group.

To configure this, right click on IPv4 > Advanced > Credentials .

Type the username and password of the user account. We have to make sure that we are using the same user account for all DHCP servers.

Please repeat step 3 for all DHCP servers which we have added in the DnsUpdateProxy group.

With this, the dynamic update configuration is complete.

Note

Configuring a credential is not a mandatory step if Domain Controller and DHCP server roles are installed in different servers. But it is a best practice recommended by Microsoft.

The advantages of this approach are :

When we configure credential in DHCP server, then all the records which are updated by that DHCP server will have that user account as owner and not the DHCP server. So even if someone adds a rouge DHCP server in the DnsUpdateProxy group accidentally / intentionally, still that new DHCP server would not be able to update existing records registered by other DHCP servers, as those records are owned by the user account.

If one DHCP Server crashes, another DHCP server in the pool will be able to update those records registered by the previous server. This is because both servers are using the same user account to register DNS record, so ACL will not cause any problem.

To illustrate the scenario, let’s assume that we have configured a user account “dhcp_update” in DHCP Server A. This DHCP server is a member of the DnsUpdateProxy group. Now, when DHCP server A will register records in DNS, those records would be owned by “dhcp_update” and not by DHCP Server A.

Now, let’s assume that DHCP Server A crashes, and we have deployed a new DHCP Server B. We have added DHCP server B in DnsUpdateProxy group and configured same credential which was configured in DHCP server A. Now, DHCP server B can update all records which were registered by DHCP server A, as those records are owned by the account “dhcp_update” and not by DHCP Server A.

Please note that if we deploy Domain Controller and DHCP Server roles in the same server, then using dynamic update credential is not optional but mandatory. If DC and DHCP are on the same server, dynamic update would not work properly without configuring credential.

As Microsoft confirmed, we must configure a dedicated user account and configure the DHCP server with the account credentials under the following circumstances:

A domain controller is configured to function as a DHCP server
The DHCP server is configured to perform DNS dynamic updates on behalf of DHCP clients.
The DNS zones to be updated by the DHCP server are configured to allow only secure dynamic updates.

Changing zone settings from non-secure to secure

Now let’s assume a scenario, where an organization is having an AD integrated DNS zone, where dynamic update settings is configured as “Nonsecure and secure”. After a recent security audit, they have identified this security flaw and decided to change it to “Secure only”. What are the things that we need to consider before changing the zone security type? Let’s consider these points:

As this is an existing zone already in production, there are thousands of live records.

This activity will not cause any impact on those records which are statically created. Generally, those are non-windows devices which do not support DDNS, like storage, network devices. Also, since Windows Server 2008, all Domain Controllers register static DNS records during DC promotion. However, if we delete the Domain Controller static record, next time the same record would be registered as dynamic.

At least 80% of those records are dynamic, means they are updated/refreshed after a certain interval, either by the system itself or by DHCP server.

Since current dynamic update settings are: Allow Nonsecure and Secure update, there is no ACL associated with any of these dynamic records and all records have inherited ACL (permission) from the parent DNS zone.

The moment we will change the zone type from non-secure to secure, ACL will come into the picture and it will NOT allow updating any of these dynamic records because there will be no matching entry (ACE) found with appropriate permission to modify the record.

Changing the zone type may not cause an immediate outage, as all records will not be updated at the same time. However, over the time, as and when system will get new IP addresses and will try to update corresponding DNS records, those attempts would not be successful which will cause a big issue and would make the entire environment unstable.

Now that we have identified the potential risk, let’s proceed towards the solution.

Case 1: For those systems where IP addresses are manually assigned

In this case, the system itself will try to update DNS record if there is any change in the IP address. So far, it was not a problem as the zone was not secured and there was no custom ACL. But before securing the zone, we need to ensure that such entries have corresponding system account as the owner.

What we are trying to achieve would be something like this:

DNS Record Name	Entry to be added in Record ACL
Server1	Computer account of Server 1
Server2	Computer account of Server 2
Server3	Computer account of Server 3

But how can we achieve this? How can we do this for a huge number of records?

I have created two PowerShell scripts which would help here:

Script 1: Get Owner of Multiple DNS Records

Script 2: Set and Remove DNS Records ACL

Using the second script, we can change ACL of bulk DNS records. The above links would tell us how to use these scripts.

Case 2: For those systems where IP addresses are assigned through DHCP

In this case, the DHCP server would try to register IP addresses on behalf of DHCP client. Let’s assume we have configured DnsUpdateProxy, and also configured credential on each DHCP server with the username “DHCP_Update”. Now, before securing the zone, we have to ensure that this account will get sufficient privilege to update all existing records. How to ensure that?

Again, we have to run the same script to update the ACL of existing records, and to add “DHCP_Update” account in the ACL with full control.

How to segregate between Case 1 and Case 2 ?

Let's assume there are 5000 existing dynamic records, some of which are updated by the system itself (Case 1) and some of which are updated by the DHCP server (Case 2).

How to segregate this?

One way is to use the first script and get the owner of the record. If the owner is the system itself, the record is registered and will be updated by the system. If the owner is DHCP server, the record is registered and will be updated by DHCP server.

However, if there is confusion, and to avoid any possible outage after securing the zone, the best approach is to configure both permissions.

So in this approach, each dynamic record will have two entries added with full control permission:

The system computer account.
The DHCP user (service) account: “DHCP_Update” in this case.

This is the safest approach, as it will ensure that after securing the zone the record would be updated, no matter who requests the update, system itself or DHCP server. So in this way, we can avoid/minimize any possible outage after changing an existing DNS Zone from non-secure to secure.

If we have to change the security settings for multiple DNS zones which are already in production, the best approach is to change it in one zone, observe the result for few weeks and then proceed for others one by one. In case of any critical issue, the backout plan is to change back the settings from “Secure Only” to “Nonsecure and secure”.

However, the best approach is to secure the zone before going to production, to avoid all these future complexities.

DHCP in a Multi-Domain AD Forest

Let’s now discuss a common scenario, where DHCP server is authorized in an AD forest and serving DHCP clients from multiple domains within that forest. Now, when DHCP server will register a DNS record, which DNS domain it will choose to register the record?

Consider below scenario:

We have a forest root domain subhro.com.
We have deployed DHCP server in the forest root domain subhro.com.
We have configured DHCP credential and put the DHCP server in the subhro.com\DnsUpdateProxy group so that it can update records in a secure only zone.
We have also selected the option: Always dynamically update DNS records.

There is a child domain: abc.subhro.com.
A server EXMB01 is a member of abc.subhro.com domain.
We have created a new scope for abc.subhro.com computers.
Reverse lookup zone is setup both in parent domain as well as in child domain. This is for testing purpose.

Now, when DHCP will allocate IP addresses to abc.subhro.com computers, in which DNS server it will update the record:

DNS server of subhro.com domain? (DHCP server is a member of this domain), Or
DNS server of abc.subhro.com domain? (DHCP client is a member of this domain)

We know that in this scenario when DHCP server will allocate an IP address, it will register the A and PTR records in the DNS, but in which DNS zone The DNS zone where DHCP server belongs or the DNS zone where the DHCP client belongs?

In other words, how DHCP registration works in a multi-domain environment? Let’s try to find out the answer. As we can see in below diagram, we have configured a scope in the DHCP server which is at the root domain subhro.com. But, we have not configured any scope option.

The DHCP server has assigned an IP address from its pool.

Now, let’s check whether the DNS record is updated, and if yes, where.

As we can see, the Host (A) record is updated in abc.subhro.com DNS zone, which is correct, as this server is a member of abc.subhro.com domain.

However, the PTR record is registered in the reverse lookup zone which is hosted on subhro.com AD Domain, not the reverse lookup zone which is in the child domain.

Now, to do some further testing, let’s disjoin this server from abc.subhro.com domain and join it in subhro.com domain, and see the result.

Before that, please delete the current lease, DNS Host record, and PTR record.

When we disjoin this server from domain and reboot in the workgroup, still DHCP will provide an IP address. The host record will not be updated in DNS, but the reverse lookup will still be updated in parent DNS zone without FQDN.

Delete this record before joining this server to subhro.com domain.

Once the server is joined to subhro.com domain, please reboot it.

We will now see that both Host and PTR records are registered in subhro.com domain.

We should also validate the record ACL, to ensure that it is updated by DHCP server using the credential.

Conclusion

When updating the host record, DHCP server searches for a DNS server which is authoritative for the zone matching the domain name of DHCP client.

So if DHCP client is a member of abc.subhro.com domain, DHCP server will look for a DNS server which is authoritative for the zone abc.subhro.com.

If DHCP client is a member of subhro.com domain, DHCP server will look for a DNS server which is authoritative for the zone subhro.com.

Even if we specify a different domain name in DHCP scope option 15 (DNS Domain Name), this behavior would not change. We have tested this point.

However, it has been observed that for updating PTR record it always looks for the parent domain DNS server.

So, we can conclude that in a multi-domain forest, we can deploy DHCP server in parent domain which would serve clients from parent domain as well as child domain, and would register DNS records in the correct DNS server based on the domain membership of DHCP client. In order to do so, we have to configure below things:

Configured all AD Integrated zones to allow Secure Only Dynamic update.
Put all DHCP servers in the DnsUpdateProxy group.
Configure one single DHCP credential in all DHCP servers to perform a secure update.

Managing Stale Records

Another key area to maintain a healthy DNS database is to identify and delete stale records. Stale records in the DNS database would lead to incorrect/duplicate DNS records for crucial servers, devices, and databases causing major disruption in service.

There is a setting in the DHCP server: Discard A and PTR records when a lease is deleted.

When this setting is enabled, the A and PTR record would be deleted from DNS, as soon as the lease is deleted from DHCP server.

We have tested this scenario in our test lab, keeping DHCP server and client in two different domains, and it worked every time. Enabling scavenging is not required for this to work. In our test lab, we did not enable scavenging in forward or reverse zone, but still, it worked immediately.

To manage other stale records in DNS server, scavenging needs to be enabled. However, scavenging is beyond the scope of this article as we are only covering integration between DNS and DHCP. Please keep in mind to set the scavenging NOREFRESH and REFRESH values combined to be equal to or greater than the DHCP lease period.

Name Protection

DHCP Name Protection is a feature, which has been introduced to prevent something called Name Squatting. This feature was first introduced in Windows Server R2.

Name squatting happens when the DHCP server registers an FQDN in DNS, which is already registered by another client. In this case, the first machine will no longer become accessible.

In a secure only zone, this generally does not happen for Windows clients as those are protected using ACL. However, there is no ACL for non-windows systems so they can be overwritten easily by another entry.

When Name Protection is enabled, it uses a resource record known as DHCID. This DHCID records is initiated by DHCP, and it is stored in DNS Server. When another client will try to register a record with the same FQDN, it will be prevented to do so, thus keeping the record intact for the first client.

If there are too many non-windows systems, devices present in the environment which use DHCP and DNS, then it is recommended to enable Name Protection feature to prevent Name Squatting.

Name Protection can be enabled from the DHCP server level, as well as scope level. The scope level settings take precedence over the server level.

다음을 통해 공유