5

I'm attempting to replace Windows Server DHCP with ISC DHCP. In order to do so, I need to be able to facilitate updating DNS records from clients that do and do not support dynamic DNS record registration.

Active Directory/DNS is running on Server 2012 R2 in 2012 R2 forest/domain functional levels. DNS forward and reverse lookup zones accept secure dynamic updates only.

I've been unsuccessful at finding a guide on how to integrate just ISC DHCP into an AD DNS environment. The configuration file is below, but what I've noted when using ISC DHCP is that non-domain joined clients will not have an A record registered for them in forward/reverse lookup zones. For domain-joined clients, they will have an A record registered in the forward lookup zone, but not the reverse lookup zone. The forward lookup zone is using DNSSEC.

ddns-updates on;
ddns-update-style standard;
default-lease-time 600;
max-lease-time 7200;
log-facility local7;

group {
  option routers 10.10.20.1;
  option subnet-mask 255.255.255.0;
  option domain-search "example.local";
  option domain-name-servers 10.10.20.2, 10.10.20.3;
  option broadcast-address 10.10.20.255;
  ddns-domainname "example.local";
  ddns-rev-domainname "in-addr.arpa.";
  authoritative;
  allow unknown-clients;
  authoritative;

  subnet 10.10.20.0 netmask 255.255.255.0 {
    range 10.10.20.30 10.10.20.150;
  }

  ... certain IP reservations for hosts ...
}

With the above configuration in place, DHCPD, as expected, is being refused by DNS to update/create records:

Unable to add forward map from device.example.local to 10.10.20.56: REFUSED
4

This can be completed through triggers for ISC DHCP. The IPv4-only script and setup information is available from ISC DHCPd: Dynamic DNS updates against secure Microsoft DNS

There is an alternative script that supports IPv4 and IPv6, but using the same premise as the above script is available at dns-krbnsupdate.sh.

The basic crux of the issue is that MS DNS uses Kerberos for authentication to update DNS records, while ISC DHCP, out of the box, supports TSIG [for BIND].

The scripts above are rather lengthy, so I won't post them here, but the basic steps are:

Generate a keytab using ktutil. This is for an Domain User who is a member of the "DnsUpdateProxy" in Active Directory. You should be able to do this on Windows or Linux (but the keytab must be copied to the server running ISC DHCP).

Configure the above script for your domain/DNS servers.

Add the parameters necessary to execute the script on the 'on commit', 'on release', 'on expiry' triggers in your dhcpd.conf. If using the IPv4/IPv6 script, the 'execute' lines will need to be adjusted:

on commit:

execute("/etc/dhcp/ddnsupdate6.sh", "add", ClientIP, "-h", ClientName, "-m", ClientMac);

on release:

execute("/etc/dhcp/ddnsupdate6.sh", "delete", ClientIP, "-m", ClientMac);

on expiry:

execute("/etc/dhcp/ddnsupdate6.sh", "delete", ClientIP);

Lastly, notate if you're using MIT Kerberos or Heimdal. With Debian Jesse, I'm using Kerberos and uncommented the KRB5MIT line.

Once completed, you can start isc-dhcp-server and monitor the (default logging) /var/log/syslog.

You should see log entries similar to:

Mar 23 23:19:34 localhost dhcpd: execute_statement argv[0] = /etc/dhcp/ddnsupdate6.sh
Mar 23 23:19:34 localhost dhcpd: execute_statement argv[1] = add
Mar 23 23:19:34 localhost dhcpd: execute_statement argv[2] = 10.10.20.56
Mar 23 23:19:34 localhost dhcpd: execute_statement argv[3] = -h
Mar 23 23:19:34 localhost dhcpd: execute_statement argv[4] = HostName
Mar 23 23:19:34 localhost dhcpd: execute_statement argv[5] = -m
Mar 23 23:19:34 localhost dhcpd: execute_statement argv[6] = <MAC_Addr>
Mar 23 23:19:34 localhost dhcpd: DHCPREQUEST for 10.10.20.56 from <MAC_Addr> (HostName) via eth0
Mar 23 23:19:34 localhost dhcpd: IPv4!
Mar 23 23:19:34 localhost dhcpd: DHCPACK on 10.10.20.56 to <MAC_Addr> (HostName) via eth0
Mar 23 23:19:34 localhost dhcpd: DDNS: adding records for 10.10.20.56 (hostname.nauplius.local) succeeded

If you see lines similar to:

DDNS: adding records for 10.10.20.51 (hostname.nauplius.local) FAILED: nsupdate status 2

This likely means the user specified in the keytab does not have rights to the DNS record, which can happen if that user did not create the record originally (e.g. you didn't use a proxy user to update DNS on behalf of DHCP). This should go away over time as DNS records expire, unless domain-joined Windows clients are automatically updating their own records.

You can validate this via the DNS MMC on Windows and checking the Security tab of the A/AAAA record in question. If you see HOSTNAME$, then the Windows client registered itself in DNS, and ISC DHCP won't be able to (I don't personally see an issue with this). Otherwise, you should see the user specified in the keytab have Read/Write permissions over the A/AAAA record.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.