Univention Bugzilla – Bug 56183
Hardcoded TTL & SOA in DNS Zones and RRs
Last modified: 2023-06-22 16:32:53 CEST
Customer is in need to change the default TTL in UCS managed bind9 zone. In a scenario with zone delegation of sub-zone in public facing nameserver setup, the customer is required to use different TTLs for zone and RRs in zone, but in UCS components there is a hardcoded TTL configured, e.g. in /usr/lib/univention-directory-listener/system/bind.py: def _new_zone(ucr: Dict[str, str], zonename: str, dn: str) -> None: ... named_zone = open(zonefile, 'w+') named_zone.write('zone "%s" {\n' % (_quote_config_parameter(zonename),)) named_zone.write('\ttype master;\n') named_zone.write('\tnotify yes;\n') named_zone.write('\tdatabase "ldap %s 172800";\n' % (_quote_config_parameter(ldap_uri),)) named_zone.write('};\n') named_zone.close() ... It would be better to have this configurable with an UCRV instead. In fact, the whole SOA itself seems to be hardcoded when a zone is added, as can be found in /usr/lib/univention-install/10univention-ldap-server.inst and/or /usr/lib/univention-install/05univention-bind.inst: /usr/lib/univention-install/10univention-ldap-server.inst: --reverse "$reverse" add zone "root@$domainname." 1 28800 10800 604800 108001 "$hostname.$domainname." || die /usr/lib/univention-install/05univention-bind.inst: exec_log_failure /usr/share/univention-admin-tools/univention-dnsedit "$@" --ignore-exists "$domainname" add zone "root@$domainname." 1 28800 7200 604800 10800 "$hostname.$domainname." /usr/lib/univention-install/05univention-bind.inst: exec_log_failure /usr/share/univention-admin-tools/univention-dnsedit "$@" --ignore-exists --reverse "$reversezone" add zone "root@$domainname." 1 28800 7200 604800 10800 "$hostname.$domainname." || die Especially the hostmaster mail address would be good to be customizable. The listed SOA values are reasonable good defaults, but they also should be made configurable by UCRVs so that new zones would be using the correct (for the customer environment) values. When using UCRV for TTL and SOA, creating new RRs should use these UCRVs as well. Hardcoded values should avaoided whenever possible, especially for such things as DNS settings which are intended to be adoptable to specific needs.
(In reply to Ingo Jürgensmann from comment #0) > /usr/lib/univention-directory-listener/system/bind.py: ... > It would be better to have this configurable with an UCRV instead. The code quoted by you just add the zone, but does not hard-code any TTL. > In fact, the whole SOA itself seems to be hardcoded when a zone is added, as > can be found in /usr/lib/univention-install/10univention-ldap-server.inst > and/or /usr/lib/univention-install/05univention-bind.inst: That's the sensible initial default values, which can be changed if needed. > Especially the hostmaster mail address would be good to be customizable. The > listed SOA values are reasonable good defaults, but they also should be made > configurable by UCRVs so that new zones would be using the correct (for the > customer environment) values. > > When using UCRV for TTL and SOA, creating new RRs should use these UCRVs as > well. > > Hardcoded values should avaoided whenever possible, especially for such > things as DNS settings which are intended to be adoptable to specific needs. # udm dns/forward_zone # udm dns/reverse_zone ... Start of authority: Start of authority contact (c) Contact person serial (c) Serial number refresh (c) Refresh interval retry (c) Retry interval expire (c) Expiry interval ttl (c) Negative time to live It is also documented in our mannual: https://docs.software-univention.de/manual/5.0/en/ip-config/dns.html#forward-lookup-zone
In the line with named_zone.write('\tdatabase "ldap %s 172800";\n' % (_quote_config_parameter(ldap_uri),)) the TTL is set to 172800. It think that is pretty much hardcoded there. The upstream nameserver has a max-zone-ttl set to 7100 and therefor refuses to update/load the zone with a TTL of 172800: Jun 20 20:42:43 dnssec named[928]: dns_master_load: TTL 172800 exceeds configured max-zone-ttl 7100 It is mandatory for the customer to have this zone loaded on that nameserver, otherwise the delegation from main domain to UCS will be removed and the customer will fall off the net and is not reachable anymore for its users. Being able to manually edit each and every zone entry is not an option as there might be dozens of new entries each day. And every time a new entry is added or changed, the TTL is reset to its default of 172800 resulting in refusal of the upstream nameserver.
The Listener code mentioned in comment 1 creates the zone files to connect BIND with LDAP. All created "database" lines end with "172800" (2 days) - that value is in plain sight in the code and not configurable. By my definition, that is "hard-coded". It's used as the default TTL of LDAP resource records without an explicit TTL - such as host records implicitly created by adding a computer object. Those do NOT get a "dNSTTL" attribte set for whatever reason. And then there are reverse (pointer) records in UCS... they do not even have an UDM attribute to set a TTL! So they will always default to "172800" from the zone files created by the Listener. This is unfortunately bad news for implementing DNSSEC, which we will be required to do in the very near future for our public forward and reverse zones.