Dynamic DNS updates from external DHCP


I have an external DHCP server (i.e. not on UCS) and am trying to configure it to push DNS updates from clients to the bind service on UCS. I have found information on how to integrate DNS and DHCP but the config files mentioned are not in UCS. Obviously UCS obfuscates the DNS setup somehow. Anyone know how to integrate external DHCP with UCS DNS?



I haven’t done this myself yet and I don’t know of a UCS-specific guide to achieve this. But maybe we can figure it out together. Which documentation are you referring to? I’d like to take a look at it and see if I can map it to UCS.

Kind regards,


I think my issue is that the configured TSIG key for updates is buried in the LDAP config rather than via named.conf for BIND. I did see that the updates from DHCP to BIND cannot be done right now in UCS, however its unclear on which direction is indicated (UCS out to external DNS or external DHCP into UCS). I found a TSIG key hidden within the LDAP config, but i still get errors that the TSIG key is incorrect.



Note that a Bind on Univention can use either the OpenLDAP as its backend for queries or the Samba 4 LDAP. Which one is used is determined by the UCR variable “dns/backend”. On most systems nowadays this is probably the Samba 4 backend so that automatic updates by Windows computers joined into the domain work.

I’m not aware that UCS creates TSIG keys for either of the two LDAPs. The aforementioned automatic update by Windows clients is authenticated via their computer accounts and Kerberos instead of TSIG keys.

Kind regards,


I would like to try another tact here now. For a number of reasons, I would like to break my DNS functions off to another server. Anyone know how to accomplish this? Do I keep UCS as primary DNS and setup a slave DNS (and not worry about updates via DHCP) or do I stop using DNS on UCS altogether and utilize a dedicated DNS server for the domain? If the latter, how do I do this? You are not able to install UCS without the DNS module, so how to tell it to look somewhere else for DNS and still function correctly with LDAP?



using a different DNS server than the one coming with UCS is not supported. DNS is much too central a component to mess around with.

What you can do, of course, is to use different DNS servers for zones other than the one managed by UCS.

However, you haven’t given nearly enough information about what your requirements are in order for me to give you any kind of good advice how to implement it. Therefore my answer must remain just as generic.

Kind regards,


Thanks for pointing that out. Here is the situation…

My UCS server performs DNS/LDAP functionality. The DNS config has forwarders that offload the “real world” lookups and clients get the IP for the UCS server for DNS via DHCP. Whenever I take down the UCS server for maintenance, my users loose internet access because the UCS server is the only DNS they have. I would like to remove the dependency on the UCS server so that when it is offline the only thing not available is LDAP and file storage.

What is the best way to accomplish this? I had tried setting up a slave DNS server and giving both DNS IPs to the clients, but it seemed to create weird lookup issues. Possibly something was misconfigured in that.

Hope that helps.



ah! That’s rather easy to achieve, and we actually do it all the time. There are (at least) two ways you can achieve this:

[ol][li]Set up a caching, recusrively resolving nameserver somewhere on your network (for us it’s our central router/firewall/security appliance that comes with said nameserver). In that nameserver instance set up request routing so that requests to your UCS domain are forwarded to the UCS DC Master. Then configure DHCP (and IPv6 SLAAC if you’re using IPV6) to distribute that other nameserver as the nameserver to use.[/li]
[li]Similar to 1: set up a recusrively resolving nameserver somewhere on your network. Then configure that nameserver to be a slave for your UCS domain. Here you obviously need to configure the DC Master to allow transfers to that server. Again distribute the other nameserver via DHCP.[/li][/ol]

I’m using method 1 all the time including in our production network. The drawback during outages of the DC Master is that entries for the local UCS domain are only resolvable as long as they’re cached.

About method 2: I haven’t used that method myself yet, but it should be easy enough to set up. The DC Master’s zone is already configured as “type master;”. Now all you have to do is to add appropriate “allow-transfer” stanzas in “/etc/bind/named.conf.local” (which isn’t managed by UCS’ templating mechanism). The advantage is that obvioulsy that a DNS slave will allow for much longer outages of the DNS master (hours or days) before it starts to consider its data to be stale.

An easy way to achieve method 2 should be to use a UCS DC Slave server for that job. It contains a copy of the whole LDAP (and it is synchronized with the DC Master automatically), its DNS server uses its local LDAP, and it should therefore work without the DC Master just fine.


Sorry to resurrect this topic…but I am forced to make some changes to my configuration and need to get more information about request routing. What I really hope to achieve is to have an appliance that provides my DHCP and DNS but I don’t understand how to integrate UCS into the DNS piece. I am already using something other than UCS for my DHCP.

Basically what I want to achieve is to have UCS function as the DC Master providing LDAP and file share services but have DNS and DHCP served from my HA appliance.



Bumping this a bit. Not sure where To turn



Your UCS system has to be the primary DNS for its own domain. Anything else simply won’t work properly. If you need to add additional entries to the same domain, do so on the UCS system. If you need to configure your clients to use a different DNS server, make sure that other DNS server routes all requests for that UCS domain to the UCS DNS server.

Kind regards


That could work, but how do you tell dns to route one way for domain X and another for everything else


That fully depends on the software/appliance in question.