Univention Bugzilla – Bug 16270
Löschen und neu anlegen einer DNS Forward-Zone funktioniert nicht
Last modified: 2013-11-19 06:41:44 CET
Ticket#: 2009110510000168 Löscht man eine DNS Forward-Zone und legt die gleiche wieder an, wird die Zonen-Datei unter /etc/bind/univention.conf.d erst nach einem "univention-directory-listener-ctrl resync bind" wieder erzeugt. Außerdem wird die Cache-Datei unter "/var/cache/bind/" nicht entfernt sodass sie nach dem erneuten Anlegen der Zone u.U. falsch ist. Workaround: $ rm /var/cache/bind/ZONE.zone $ univention-directory-listener-ctrl resync bind
Erik, bitte einmal testen ob das Problem mit UCS 3.1 noch auftritt, einmal mit Samba 4 und einmal ohne.
Mit 3.1 wird die Zonendatei in /etc/bind/univention.d/ nach dem neuanlegen der Zone korrekt erstellt. Die Cachedatei wird aber weiterhin nicht entfernt und ist damit nicht aktuell. Ich habe die Zone nochmal mit einer höheren Startseriennummer erstellt um zu sehen ob das die gecachte Datei beeinflusst, tut es aber nicht. Wenn ich einen neuen hosteintrag in dieser Zone erstelle wird dieser per host <name> auch gefunden, die Cachedatei ist aber immernoch unverändert. Vermutlich ist es sauberer wenn die Cachedatei entfernt wird.
Mit 3.1 ohne Samba 4 wird die Zonendatei unter /etc/bind/univention.conf.d korrekt entfernt und wieder angelegt, die Cachedateien unter /var/cache/bind werden wieder nicht angefasst.
Created attachment 4921 [details] Patch zu löschen der alten Zonencachedatei
We will not ship a UCS 3.1-2 release; the next UCS release will be UCS 3.2. As such, this bug is moved to the new target milestone.
Zonendateien wird ohne/mit samba4 korrekt erzeugt -> WORKSFORME Löschen der gecachten Zonendatei: rev 41794; univention-bind 8.0.0-1.190.201306281402 gebaut in 3.2
OK: svn41794 OK: Samba4 does not use the cache files OK: OpenLDAP+bind9 removes the cache file FAIL→OK: CL svn43138 changed to: > The file containing the cached DNS zone is now also deleted upon zone deletion There's still an inherent bug with deleting zones: upon deletion the SOA serial number is lost, so it gets reset to 1 for the new zone. A downstream DNS server interprets a backward-jump as the master being out-of-date and then does not download the new zone. This would be fixed by using "YYYYMMDDnn" as the SOA serial as recommended by RIPE: <http://www.ripe.net/ripe/docs/ripe-203> Please notice <http://www.zytrax.com/books/dns/ch9/serial.html>: The SOA serial number is an unsigned 32-bit field with a maximum value of ((2**32) -1), which gives a range of 0 to 4294967295
UCS 3.2 has been released: http://docs.univention.de/release-notes-3.2-en.html http://docs.univention.de/release-notes-3.2-de.html If this error occurs again, please use "Clone This Bug".