Univention Bugzilla – Bug 37425
BIND as Hidden Primary: also-notify variable
Last modified: 2023-06-23 12:27:29 CEST
Hallo, im Forum unter http://forum.univention.de/viewtopic.php?f=48&t=3660 habe ich eine mögliche Konfiguration vorgestellt und getestet, die es ermöglicht einen UCS Server auch als DNS Hidden Master zu benutzen. Vorteil dieses Setups ist, sehr elegant auch externe Domains zu verwalten, und dies: * ohne einen Univention-Server direkt im Internet exponieren zu müssen * ohne direkten administrativen Zugriff auf die externen DNS-Server zu haben Beides kommt in KMU's wohl häufiger vor bzw. wird so gewünscht, daher meine ich einen möglichen Mehrwert zu erkennen, wenn ein UCS-Server das in Zukunft "out of the Box" können kann. Das Setup selbst ist überschaubar und im Forum erklärt, die gewünschten Änderungen tangieren bereits vorhandene UCS-Installationen nicht. Daher bitte ich um Übernahme der Änderungen im Template und setzen einer neuen Konfigurationsvariable in einem der nächsten UCS Updates, wenn Ihnen dies möglich ist. Im Einzelnen müssten folgende Punkte angepasst/geändert werden: * Neue ucr Variable dns/notify, Standard <unset>: dns/notify: <unset> This variable defines a list of IP addresses of name servers that are also sent NOTIFY messages whenever a fresh copy of the zone is loaded. Multiple entries need to be separated by semicolons. If this variable is changed or unset, the IP address 127.0.0.1 will always be added. This option only applies when using the LDAP-Backend (see 'dns/backend'). Categories: Network --> /etc/univention/templates/info/univention-bind.info Type: file File: etc/bind/named.conf Variables: dns/ipv6 Variables: dns/notify * Änderung eines Templates "/etc/univention/templates/files/etc/bind/named.conf": Ab Zeile 8 sieht diese Datei im Original so aus: options { directory "/var/cache/bind"; also-notify { 127.0.0.1; }; @!@ val = 'none' if configRegistry.is_true('dns/ipv6', True ): Das Template wie folgt ab Zele 8 ändern: options { directory "/var/cache/bind"; @!@ ## notify notify=configRegistry.get('dns/notify') if notify: print '\talso-notify { 127.0.0.1; %s; };' % notify else: print '\talso-notify { 127.0.0.1; };' ## ipv6 val = 'none' if configRegistry.is_true('dns/ipv6', True ): Ich habe keinen extra diff für /etc/univention/templates/files/etc/bind/named.conf gemacht, die Änderungen sind ja sehr überschaubar. Das geänderte Template erzeugt, wenn die Variable "dns/notify" nicht gesetzt ist, eine funktionell zum jetzigen Template identische Konfigurationsdatei: Damit sind vorhandene Setups nicht betroffen. mit freundlichen Grüßen Lutz Willek
Bitte alle Bind Features vollständig implementieren siehe: http://www.bind9.net/arm910.pdf
This issue has been filled against UCS 4.0. The maintenance with bug and security fixes for UCS 4.0 has ended on 31st of May 2016. Customers still on UCS 4.0 are encouraged to update to UCS 4.3. Please contact your partner or Univention for any questions. If this issue still occurs in newer UCS versions, please use "Clone this bug" or simply reopen the issue. In this case please provide detailed information on how this issue is affecting you.
* Still valid for ucs4.3 -> reopened * Easy to implement (only 2 new variables and modify 2 template files) * Allows to add an additional feature (dns hidden master) * Tested for more than three years now, without any problems
*** Bug 49529 has been marked as a duplicate of this bug. ***
Using the ACME DNS challenge in order to get wildcard SSL certificates is quite complicated and needs a lot of scripting as nearly every nameserver provider offers a proprietary API. Integrating a (hidden) primary nameserver in UCS would allow direct access to DNS zone configurations without having to implement hundreds of proprietary APIs. This would allow a tighter integration of a lot of services in UCS (e.g DNSSEC, DANE, SRV-RRs, MX-RRs, A/AAAA-RRs, CNAME-RRs, anything which needs custom DNS resource records, ...). Configuring everything in the UCS web-interface would be much more comfortable than hopping around and synchronizing records with multiple web-interfaces/APIs of multiple providers.
Requeste through a support ticket from customer.
On the one hand, the initial implementation of early 2015 is still in operation and has been working for almost 6 years straight, so a better integrated UCS template would still be desirable from our side. All the initial benefits mentioned are still valid. Yes, we have also used ACME DNS challenge in the time since and can thus confirm that it will function in this way, even if not entirely unproblematic. (YFTR the challenge we faced: DNS NOTIFY according to RFC1996 does not allow DNS updates in realtime. Means some integration work must still be conducted to ensure that the changed DNS entry for the ACME DNS challenge has really been propagated worldwide, in order to make ACME via DNS work smoothly) On the other hand, six years in IT is a true eternity, meaning there are now entirely new opportunities. I am telling this because a customer has requested this feature now. It is true, given our very specific situation, I would implement a DNS NOTIFY again - but generally speaking, this is not necessarily the best solution anymore these days for the average enterprise setups out in the wild. Nowadays, there are templating systems available for automated management of a multitude of DNS providers. These tools are much better decoupled than a DNS notify mechanism will ever be. A simple notify hook in UCS which is configured for DNS changes could pick up the changed entries directly from LDAP and the new tools available would ensure that changed data are processed and transmitted securely to the individual providers. The problem with waiting times (i.e. whether an entry has already been propagated or not) can also be solved much more neatly. To sum up: this report is imho still justified, and I would certainly appreciate it if it could be implemented because I am personally affected. Nowadays, however, if I were Univention, I would choose a different approach which has fewer dependencies and is applicable across the board.
another customer is asking for this