+++ This bug was initially created as a clone of Bug #47176 +++ For Bug 32626 I checked if delegation of a DNS subdomain to a different DNS server actually works. Unfortunately our global "forwarders" configuration in /etc/bind/named.conf.samba4 and /etc/bind/named.conf.proxy causes bond9 to contact the forwarders for all DNS zones except for the ones he is authoritative himself. The usual workaround is to explicitly specify an empty list of forwarders for the hosted zones, see: https://deepthought.isc.org/article/AA-00538/0/How-can-I-disable-global-forwarding-for-delegated-subdomains.html I have tasted this with the named.conf.proxy and it works. We could adjust univention-bind/bind.py to add this line to the zones and I'll attach a patch below. Things look more complicated for the Samba/AD case, where a DLZ module is used. In our current named.conf.samba4 we don't explicitly configure individual zones but use the default "search yes" feature of Bind9 DLZ. I think we would have to switch to the "search no" configuration as documented here: https://kb.isc.org/article/AA-00995/0/Using-DLZ-in-BIND-9.8.html My first tests with this where unsuccessful though and the nameserver didn't resolve his own FQDN any more (Host master10.ar41i1.qa not found: 2(SERVFAIL)). After digging a bit in the bind9 dlz.c and the dlz_dlopen driver I think that the Samba dlz_bind9.c module needs to be adjusted to initialize its zone_partition_relation in the dlz_create function already, instead of later in dlz_configure. In my tests it looked like dlz_configure didn't get called at all when the "search no" DLZ option is active.
Clients might be required to confiure external nameservers for a sub-zone (e.g. UCS domain -> univention.de, external domain sub.univention.de). In this document I want to give a short overview about the noticed behaviour: First of all, the NS record is added using the UMC: ``` dn: relativeDomainName=dns-test,zoneName=dns-testerino.de,cn=dns,dc=univention,dc=intranet zoneName: dns-testerino.de dNSTTL: 79200 objectClass: top objectClass: univentionObject objectClass: dNSZone univentionObjectType: dns/ns_record relativeDomainName: dns-test nSRecord: ucs-1589.dns-test.dns-testerino.de. ``` 1. If no Forwarders are defined: The Nameserver will return a SERVFAIL. This is caused by error messages like: > adb: fetch of 'ucs-1589.dns-test.dns-testerino.de' A failed: timed out -> if the target nameserver is also lying in the same zone, the nameserver will not be able to resolve the target nameserver. You have to add the target nameserver in the ucs zone as well. root@ucs-7794:~# univention-ldapsearch relativeDomainName=ucs-1589.dns-test -LLL dn: relativeDomainName=ucs-1589.dns-test,zoneName=dns-testerino.de,cn=dns,dc=univention,dc=intranet zoneName: dns-testerino.de dNSTTL: 10800 aRecord: 10.201.2.61 objectClass: dNSZone objectClass: univentionObject objectClass: top univentionObjectType: dns/host_record relativeDomainName: ucs-1589.dns-test -> if the target nameserver is not known to UCS, you cannot perform that setup without forwarders as the nameserver will not be able to resolve the target nameserver. 2. If forwarders are defined: -> requests for the subzone are forwarded to root nameservers and the nameserver will possibly not be able to resolve the target nameserver. This can be mitigated by adding `forwarders {};` to the proxy configuration, e.g. /etc/bind/univention.conf.d/dns-testerino.de.proxy Then the nameserver will be able to resolve the target nameserver and forward the request to the target nameserver. As this is currently not statically configurable, the issue has been reopened.