DDNS Update Security

This post came to my attention recently, although the title can be misleading: “Spoofing DNS Records by Abusing DHCP DNS Dynamic Updates“. Here is my very condensed summary of this long and technical blog post:

1. In Microsoft Active Directory, DHCP clients (such as laptops) typically update their own DNS entries using Dynamic Update (DDNS Update).

2. It is possible to configure to have the DHCP server perform the Dynamic Update on behalf of the clients. However, certain authentication mechanisms can be bypassed.

3. The blog talks about how this bypass can be abused by malicious actors to overwrite certain DNS entries. Essentially, my laptop could create “josh.corp.local -> 10.1.1.1”, and someone else could change it to “josh.corp.local -> 10.2.2.2”.

In my opinion, this is not so much spoofing, but overwriting without authorization. I will attempt to explain what DDNS is, how it works, and why I don’t think this is an exploit or vulnerability, and can be solved by proper DNS architecture.

What is Dynamic DNS?

When I utter the phrase “Dynamic DNS”, many people automatically think that I am referring to the (non-standard) technology where one can update an Internet DNS name to reflect the current home IP address assigned by the ISP. While that is one interpretation of Dynamic DNS, the one we are discussing here is most often used for internal or private networks, and is documented in the standards document RFC 2136. You can roughly think of DDNS as a built-in feature in standard DNS that allows anyone to send a message over the network to add, update, or remove DNS data. At the time of its invention, DDNS was meant to reduce administrator’s manual work of editing DNS zone files and restarting DNS services, by allowing devices or applications send the update message directly to the DNS server to update their own entries.

What could possibly go wrong?

Well, surprisingly, not a lot. This honor system held up fairly well over the decades, and is the cornerstone of modern networks such as Active Directory.

How does Dynamic DNS Work?

If DDNS is enabled on a device, when it detects that it has an IP address address and a FQDN (fully qualified domain name), it reaches out to the correct DNS server and sends a DDNS update message to either add itself into DNS, or to update an existing entry. The device or application find the correct DNS server by querying for the SOA record of the zone. The MNAME listed in the SOA record contains the name of the primary DNS server. When the DDNS message arrives at the primary DNS server, it decides whether to accept or reject based on its own configurations.

What Doesn’t Work?

Like I mentioned earlier, this system, like the rest of the global DNS, held up surprisingly well over the decades. Where it doesn’t work as well, is the removal process. In the context of Active Directory, when a client signs in to AD, it sends the DDNS update message to one of the domain controllers (DC), which acts as the primary DNS server to update the zone data. This portion for the most part, works (there are some issues with AD replications that I won’t get into here). The part that does not work well is when the client leaves the network. There is no way for the client to send a message to the DNS server to signal: “Hey! I am about to leave! Please remove the following DNS entries before I disconnect!” I can say with confidence that 99.99% of the time, devices simply disconnect (either by removing the network cable or by moving out of range of the wireless network), leaving a few DNS records dangling behind. (The only exception I can think of is when the user has issued a proper shutdown of the device, and the DNS records were removed during the shutdown).

Over time, these dangling DNS records build up, causing your DNS data to become inaccurate. The duct tape solution for this: DNS Scavenging, which has its own issues. Again, that will be a story for another time.

An Alternative to Client DDNS Update

An alternative is to allow the DHCP server to perform the DDNS update. As the DHCP server gives away IP address leases, it has the same information as the client device or application: the IP address and the fully qualified domain name of the client. The DHCP server has 2 advantages to the client:

1. The DHCP server stays on line

2. The DHCP server knows when the client has disconnected when the lease expires

By allowing DHCP server to update DNS on behalf of the client, we solve the problem of leaving dangling DNS records behind, and it is more accurate than relying on DNS Scavenging to figure out which clients have truly disconnected, and which ones have not.

… But What About Overwriting DNS Records Created by Clients?

What the original Akamai post calls “DNS Spoofing”, is really someone else (such as DHCP server) overwriting the DNS entries originally created by the client device or application. Now you may call this DNS Spoofing, but for me that’s a poorly defined (but sensational sounding) term. If we want to be more technically accurate, we should call it Overwriting without Authorization.

I don’t want to make this into a full chapter of a book (which is what the topic really deserves), so I’ll skip to the solution proposed decades ago: https://datatracker.ietf.org/doc/html/draft-ietf-dhc-dhcp-dns-12. Sadly, this was never adopted as standards, but it was implemented by ISC BIND and many other DNS servers.

This feature, in short, creates a little “marker” in the form of TXT records for the DNS entries that are created by dynamic updates (i.e. clients). This way, when looking at the DNS zone data, you can see quickly which entries were created manually (i.e. someone editing the zone file), and which ones were added by clients (i.e. the ones with matching TXT records). The TXT records contain the DHCID of the clients. You can think of the TXT records as the fingerprints of the client in this context.

ISC TXT Records for Dynamic Update Protection

Below is a flow chart I have created that explains how the DNS server processes the DDNS update request from DHCP server. It starts on the left with the DHCP server wanting to add A/AAAA, PTR, and TXT records.

ISC DDNS TXT Record Handling

Let me briefly describe the 4 possible outcomes with this TXT record feature (left to right):

1. Client is trying to add entries that don’t currently exist: this is the first outcome: The A or AAAA records do not currently exist, so there is no risk of overwriting. In the chart, this update is accepted.

2. Client is trying to add or update entries that appear to have been manually created: The name exists, and there is no associated TXT record (fingerprint), suggesting manual creation by an administrator. In the chart, this update request is denied to protect the non-DHCP created records.

3. Client is trying to update dynamic entries owned by others: The name exists, and there is an associated TXT record (fingerprint). However, the incoming TXT record does not match the current one in the zone file. This is to say that the incoming request TXT record does not match the current TXT record in the zone file. This typically indicates that the name was dynamically created by another client. In the chart, this update request is denied to safeguard records created by other clients.

4. Client is trying to update dynamic entries owned by itself: The name exists and the two TXT records match. This indicates the client is trying to update entries that itself created earlier. In the chart this update request is accepted.

As you can see, when configured, this feature limits who can overwrite or update DNS records. There are other "modes" in which you can run this, such as ignoring TXT matching (essentially allowing all dynamic entries to overwrite others).

Conclusion

The original Akamai blog post notes authentication flaws that could lead to (un)intentional record overwriting. Can this flaw be leveraged by malicious actors? Perhaps. However, the bigger question you might want to ask yourself is: why are you allowing clients to add/delete/modify DNS entries on the fly? You can design an internal DNS system that permits only DHCP servers to update. This way, you can enforce update policies, ensuring a cleaner DNS zone data with minimal dangling entries. In other words, you can ban clients from performing their own DNS updates, but still have the dynamic information show up in DNS by allowing DHCP server to update.

In other words, I don’t agree with the common AD architecture of trusting clients to manage their own DNS entries. I strongly urge you, the reader, to explore the alternative architecture of only allowing DHCP servers to update DNS.

What about the clients that are not using DHCP in the first place, you say? Many people express a desire for the flexibility of setting up a server with a static IP address, and having the DNS entries appear magically (or in Microsoft terms, "automatically registered"). My usual response when I am training someone on this topic is: “How do you know you can use those static IP addresses? And please answer without using the term ping.”

Setting aside snarky remarks, in this day and age, it's advisable to use an IPAM system to track address usage and assignments. Additionally, the IPAM system should update (register) DNS entries for you.