Bug 16270 - Löschen und neu anlegen einer DNS Forward-Zone funktioniert nicht
Löschen und neu anlegen einer DNS Forward-Zone funktioniert nicht
Product: UCS
Classification: Unclassified
Component: DNS
UCS 2.2
Other Linux
: P5 normal (vote)
: UCS 3.2
Assigned To: Erik Damrose
Philipp Hahn
: interim-1
Depends on:
  Show dependency treegraph
Reported: 2009-11-05 14:59 CET by Janis Meybohm
Modified: 2013-11-19 06:41 CET (History)
1 user (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:

Patch zu löschen der alten Zonencachedatei (723 bytes, patch)
2012-12-17 09:28 CET, Erik Damrose
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Janis Meybohm univentionstaff 2009-11-05 14:59:56 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.

$ rm /var/cache/bind/ZONE.zone
$ univention-directory-listener-ctrl resync bind
Comment 1 Stefan Gohmann univentionstaff 2012-12-12 21:29:04 CET
Erik, bitte einmal testen ob das Problem mit UCS 3.1 noch auftritt, einmal mit Samba 4 und einmal ohne.
Comment 2 Erik Damrose univentionstaff 2012-12-13 12:13:05 CET
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.
Comment 3 Erik Damrose univentionstaff 2012-12-13 16:12:07 CET
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.
Comment 4 Erik Damrose univentionstaff 2012-12-17 09:28:47 CET
Created attachment 4921 [details]
Patch zu löschen der alten Zonencachedatei
Comment 5 Moritz Muehlenhoff univentionstaff 2013-05-31 10:44:51 CEST
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.
Comment 6 Erik Damrose univentionstaff 2013-06-28 14:08:42 CEST
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
Comment 7 Philipp Hahn univentionstaff 2013-08-13 16:47:32 CEST
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
Comment 8 Stefan Gohmann univentionstaff 2013-11-19 06:41:44 CET
UCS 3.2 has been released:

If this error occurs again, please use "Clone This Bug".