Years ago, I posted a script that allowed ISC DHCPd to update a Microsoft DNS server with dynamic records for DHCP clients. I haven’t used that method in a long time and there is a much simpler method: use ISC DHCPd together with the BIND DNS server like everybody else does, and only delegate the _mscds and _sites zones from the BIND server to the Microsoft DNS servers:
_msdcs.example.com. 86400 IN NS dc01.example.com.
_msdcs.example.com. 86400 IN NS dc02.example.com.
_sites.example.com. 86400 IN NS dc01.example.com.
_sites.example.com. 86400 IN NS dc02.example.com.
Then on all your machines, use the BIND server as DNS server (typically set via DHCP option 23). For Windows Domain matters, only records below _msdcs and _sites are ever looked up.
I believe you should even be able to point your domain controllers to the BIND DNS server — they should be able to follow the NS record so that whenever they try to update their own records, they do so on the Microsoft DNS server. As it turns out, the RFC 2136 DNS UPDATE method is used when domain controllers try to register their own records, so you’ll see error messages in your logs if you point your domain controllers to the BIND DNS server (on a Microsoft DC, these would refer to NETLOGON and dynamic DNS registrations, while on a Samba DC they would be about samba_dnsupdate). If you are running Samba 4.5 or higher, you should ensure that samba_dnsupdate is called with the –use-samba-tool flag, which can probably be done by setting the option below in your /etc/samba/smb.conf. If you are running an older Samba version or any Windows Server version, you need to resort to using your domain controllers’ IP addresses as DNS servers on on all domain controllers (Samba: put them into /etc/resolv.conf, Windows: set them in the network interface properties).
dns update command = /usr/sbin/samba_dnsupdate --use-samba-tool
For compatibility with Unix clients (including Mac OS X), you’ll want to add a couple of CNAME records for the SRV records:
_ldap._tcp.example.com. 86400 IN CNAME _ldap._tcp.dc._msdcs.example.com.
_gc._tcp.example.com. 86400 IN CNAME _ldap._tcp.gc._msdcs.example.com.
_kerberos._tcp.example.com. 86400 IN CNAME _kerberos._tcp.dc._msdcs.example.com.
_kerberos._udp.example.com. 86400 IN CNAME _kerberos._tcp.dc._msdcs.example.com.
_kpasswd._tcp.example.com. 3600 IN SRV 0 100 464 dc01.example.com
_kpasswd._tcp.example.com. 3600 IN SRV 0 100 464 dc02.example.com
_kpasswd._udp.example.com. 3600 IN SRV 0 100 464 dc01.example.com
_kpasswd._udp.example.com. 3600 IN SRV 0 100 464 dc02.example.com
The _kpasswd records unfortunately can’t be CNAMEs because they don’t exist in the _msdcs branch, so you manually need to keep them up-to-date when you add and remove domain controllers.
Pingback: ISC DHCPd: Dynamic DNS updates against secure Microsoft DNS | Michael Kuron's Blog
Hi,
Great article!
I didn’t understand the part about pointing the domain controller’s resolving to use the Linux bind – where does samba come into the picture? are your domain controllers Linux/samba based?
Thanks,
Or.
Sorry, I should have made this clearer. In Samba >= 4.5 the behavior is switchable, in older versions and in Windows Server it is not. I have updated the blog post accordingly.
So with this setup, would client devices register their A and PTR records in AD DNS? Or both in BIND and AD DNS? I ask specifically because in my environment, we are not allowing client devices (workstations, laptops, tablets) to register records in BIND, only in AD DNS.
I think Windows uses nsupdate-style registration, so they would attempt to write to BIND and fail. Do you really need the registrations in AD DNS? I don‘t care about them because in my environment the DHCP server registers the clients in BIND.
Yeah, we’re looking to move to an IP manager (Infoblox or Bluecat), but in the interim, we trying to allow for dynamic registration in AD DNS for our client devices (to fix issues with managing them in SCCM). Right now, we have to manually configure the network adapter on each workstation and laptop to force the client to register against AD DNS. I’m hoping to do things the “right” way by forcing registration from DHCP. Our network team does not want client registration in BIND.