This blog post outlines a little trick we use to get Linux-based hosts on a network to show up in Microsoft-based DNS… automagically. This self-registration with DNS usually “just works” in a homogeneous Windows network (famous last words!)– so many folks take it for granted until they need something from the Linux ecosystem. Without setting this up, your options are either A) refer to said machines by IP address only, or B) manually add their hostnames and IPs into DNS, and manually keep those records updated.

We use it for our monitoring servers, and for dev boxes. In these situations, we want those machines to self-register their interfaces with DNS– so that they begin working without any special attention after you hook them up. It might also be handy for things like Linux domU Xen guests for your big data test environment, or various workstation OSs in a bring-your-own-device (BYOD) workplace, or for extracurriculars like that Bitcoin mining proxy the guy in the next cube over has been tinkering around with.

NOTE REGARDING MISSION-CRITICAL SERVERS: If you have a mission-critical Linux-based server, the best practice is to have a static IP address, NOT a DHCP one. In those cases, use a static IP address for the Linux-based server’s network interface, and input a record into Microsoft’s DNS manually. DHCP reservation, although it might get you a simulacrum of a static IP assignment, could leave the door open for unwelcome surprises.

Basic gist

Simply put, we can set Microsoft DHCP to register in Mirosoft DNS any IPs it hands out. This allows other machines to refer to those hosts by their hostname, and bypasses the admin overhead you’d be stuck with otherwise. It is the closest thing we can get to when you check “Register this connection’s address in DNS” under “Advanced TCP/IP Settings” for your network adapter (or NIC) on a Windows machine living in a Microsoft domain.

From a security perspective, I don’t see any significant increased risk (other than the fact that names of DHCP clients would become visible on your network), assuming you do everything as shown below. If we do learn of additional issues with this configuration, security or otherwise, we will update this article.

Prerequisites

The first prerequisite is that the machine will get an IP from a Microsoft DHCP service. You might have multiple DHCP servers working in symphony on your network, such as on WiFi routers and whatnot, so you’ll need to confirm this. (You can usually specify which DHCP servers your host uses in Linux, if you need to, but that is not covered in this post.) The person doing this work also needs rights to manage that Microsoft DHCP server’s settings. You can also add in a DHCP reservation to tie the IP address to a particular host on a more-permanent basis, which can be very practical, but it isn’t covered here.

The next prerequisite is that you are using Microsoft-based DNS for the hosts in question. If you are using Active Directory, chances are that you have it. Nonetheless, there are a lot of possible scenarios out there, and the Microsoft flavor of DNS is required for this configuration.

Setup instructions

These instructions show the steps in Windows Server 2012, for IPv4.

First, in Active Directory, you’re going to create a plain-vanilla User for this.

DHCP_DNS4

I would recommend the settings “User cannot change password” and “Password never expires”, but these may or may not be options in your environment.

DHCP_DNS5

Next, go to the host from which you can manage Microsoft DHCP. It should be listed in Administrative Tools, or on the metro Start Menu, you can just start typing “DHCP”. If no servers are listed, right-click DHCP, and select “Add server”, and point it to the DHCP server. Once you get it to show up, expand it, and expand “IPv4”. Right-click the Scope for which you would like to make this change, and select “Properties” (a Scope is basically a unique range of IPs with a subnet, combined with other configurable options like DNS server and address reservations). Select the “DNS” tab. Configure it as shown below by selecting “Dynamically update DNS A and PTR records for DHCP clients that do not request updates (for example, clients running Windows NT 4.0)”. Other examples might include Ubuntu and Mac OSX– but we knew that already!

It is also possible to enable this for the entirety of IPv4, under the DNS tab for its Properties window– but keeping it limited to a particular Scope is probably not a bad idea.

DHCP_DNS1

Also, to prevent security issues based on hostname impersonation in DHCP, you could click the “Configure” button, and select the checkbox for “Enable Name Protection”. However, this might give you problems in a situation where you are reusing hostnames, like in a development environment. In that scenario, you might instead choose to lock down DHCP in some other way to reduce your risk exposure. (On the other hand, when your MAC address doesn’t change, and you use the same IP address and hostname when you rebuild a box, it might work fine for a sandbox environment)

Next, right-click “IPv4” and select “Properties”. Then click the “Credentials” button. Fill in the info for the user you created.
DHCP_DNS2

And that is about it!

Leave a Reply

Your email address will not be published. Required fields are marked *