DNS SOA - Seriennummerformat ändern
Guten Abend liebe Kolleginnen und Kollegen,
da es in der Nachtschicht etwas ruhiger zu geht als sonst, gehe ich einem Projekt nach.
In einer Umgebung gibt es zwei Netzwerke (LAN1 und LAN2), die physikalische voneinander getrennt sind. Der ein- bzw. ausgehende Datenverkehr wird über eine Firewall erlaubt/geblockt.
Im LAN1 gibt es mehrere Server, welche unter Windows Server 2012R2 laufen. Diese sind alle als Domain Controller (DC), DNS und Global Catalog (GC) eingerichtet. Im DNS-Server gibt es mehrere Forward -und Reverse-Zonen. Bestimmte Forward- und die dazugehörigen Reserve-Zonen sollen auf einem DNS-Server im LAN2 repliziert werden. Dazu nutzen wir Zonenübertragungen und Zonen vom Typ Slave.
Mir geht es um die Seriennummer der jeweiligen Zone, welche repliziert werden. Der DNS unter Windows Server fängt bei 1 an und zählt bei jeder Änderung automatisch um 1 hoch. Soweit so gut. Nun haben wir im LAN2 eine Anwendung/Skript welche mit dieser Art von Seriennummer nicht klar kommt und einen Fehler ausgibt. Was meiner Meinung nach logisch ist. Denn in allen mir bekannten Fällen ist die Seriennummer so aufgebaut: YYYYMMDDss.
Ich habe bereits in den letzten Wochen recherchiert und habe folgende, brauchbare Beiträge gefunden:
https://jeffpar.github.io/kbarchive/kb/196/Q196432/
https://support.microsoft.com/en-us/help/282826/active-directory-integra ...
https://social.technet.microsoft.com/Forums/lync/en-US/f142b98e-1a0d-4f7 ...
Ist aber leider nicht das Gelbe vom Ei. Sieht so aus, als hätte sich noch nie jemand Gedanken dazu gemacht.
Hat jemand sich jemand von euch mit der Thematik beschäftigt und eine praktikable, supportete Lösung gefunden?
Gruß,
Dani
da es in der Nachtschicht etwas ruhiger zu geht als sonst, gehe ich einem Projekt nach.
In einer Umgebung gibt es zwei Netzwerke (LAN1 und LAN2), die physikalische voneinander getrennt sind. Der ein- bzw. ausgehende Datenverkehr wird über eine Firewall erlaubt/geblockt.
Im LAN1 gibt es mehrere Server, welche unter Windows Server 2012R2 laufen. Diese sind alle als Domain Controller (DC), DNS und Global Catalog (GC) eingerichtet. Im DNS-Server gibt es mehrere Forward -und Reverse-Zonen. Bestimmte Forward- und die dazugehörigen Reserve-Zonen sollen auf einem DNS-Server im LAN2 repliziert werden. Dazu nutzen wir Zonenübertragungen und Zonen vom Typ Slave.
Mir geht es um die Seriennummer der jeweiligen Zone, welche repliziert werden. Der DNS unter Windows Server fängt bei 1 an und zählt bei jeder Änderung automatisch um 1 hoch. Soweit so gut. Nun haben wir im LAN2 eine Anwendung/Skript welche mit dieser Art von Seriennummer nicht klar kommt und einen Fehler ausgibt. Was meiner Meinung nach logisch ist. Denn in allen mir bekannten Fällen ist die Seriennummer so aufgebaut: YYYYMMDDss.
Ich habe bereits in den letzten Wochen recherchiert und habe folgende, brauchbare Beiträge gefunden:
https://jeffpar.github.io/kbarchive/kb/196/Q196432/
https://support.microsoft.com/en-us/help/282826/active-directory-integra ...
https://social.technet.microsoft.com/Forums/lync/en-US/f142b98e-1a0d-4f7 ...
Ist aber leider nicht das Gelbe vom Ei. Sieht so aus, als hätte sich noch nie jemand Gedanken dazu gemacht.
Hat jemand sich jemand von euch mit der Thematik beschäftigt und eine praktikable, supportete Lösung gefunden?
Gruß,
Dani
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 391601
Url: https://administrator.de/forum/dns-soa-seriennummerformat-aendern-391601.html
Ausgedruckt am: 01.04.2025 um 22:04 Uhr
27 Kommentare
Neuester Kommentar
Hi Dani,
so ganz will sich mir die dahinterstehende Frage noch nicht erschliessen, folgend:
Da ich nunmal davon ausgehe, dass du die Seriennummern mit Software (welche, warum?) überwachen? Auswerten? handlen? möchtest, müsstest du das Skript (s.o Zweck?) doch im Prinzip nur anpassen.
Außerdem ist mir auch nicht klar, durch wen die Lösung supported sein soll und in wie weit die Lösung praktikabel ist, da noch nichts über den praktischen Zweck der Seriennummer überwachung geschrieben wurde.
Also wäre das wohl der/die erste(n) Schritt(e), damit man überhaupt weiss, in welche Richtung man denken muss...
Viele Grüße und weiterhin eine ruhige Nachtschicht
so ganz will sich mir die dahinterstehende Frage noch nicht erschliessen, folgend:
Da ich nunmal davon ausgehe, dass du die Seriennummern mit Software (welche, warum?) überwachen? Auswerten? handlen? möchtest, müsstest du das Skript (s.o Zweck?) doch im Prinzip nur anpassen.
Außerdem ist mir auch nicht klar, durch wen die Lösung supported sein soll und in wie weit die Lösung praktikabel ist, da noch nichts über den praktischen Zweck der Seriennummer überwachung geschrieben wurde.
Also wäre das wohl der/die erste(n) Schritt(e), damit man überhaupt weiss, in welche Richtung man denken muss...
Viele Grüße und weiterhin eine ruhige Nachtschicht
Guten Morgen,
was hindert dich die Seriennummer hoch zu setzen?
ich sehe jetzt kein probelm darin:
Achte nur darauf, das deine Slave-Server Zonen eine Seriennummer unter dem neuen wert haben, weil so keine synchronisierung möglich ist!
am besten wäre es die TTL zeiten runter zu stellen, bis alle den zonentransfer abgeschlossen haben.
ach ja... die netzlast könnte etwas höher ausfallen... also besser abends oder am we machen...
Frank
was hindert dich die Seriennummer hoch zu setzen?
ich sehe jetzt kein probelm darin:
2018110409 ; Serial
Achte nur darauf, das deine Slave-Server Zonen eine Seriennummer unter dem neuen wert haben, weil so keine synchronisierung möglich ist!
am besten wäre es die TTL zeiten runter zu stellen, bis alle den zonentransfer abgeschlossen haben.
ach ja... die netzlast könnte etwas höher ausfallen... also besser abends oder am we machen...
Frank

Moin,
dann machst du dir halt auf dem Master ein Skript das die Seriennummer um 00:00 Uhr per Taskplaner auf das entsprechende Datum mit Zähler 01 setzt. Der dadurch zusätzlich ausgelöste Sync sollte den Braten ja heutzutage nicht mehr fett machen.
Gruß l.
dann machst du dir halt auf dem Master ein Skript das die Seriennummer um 00:00 Uhr per Taskplaner auf das entsprechende Datum mit Zähler 01 setzt. Der dadurch zusätzlich ausgelöste Sync sollte den Braten ja heutzutage nicht mehr fett machen.
Gruß l.
moin Dani,
in der rfc1912 wird nur empfohlen, das aktuelle Datum mit einem zweistelligen zähler zu nutzen!
den Zeitstempel in der SR jede nacht zu ändern, würde in meinen augen nur unötige zonentransfers und netzwerk last erzeugen!
deine anwendung/skript wird mit der änderung klarkommen, es geht wohl nur um das format.
Gruß,
Dani
Frank
Somit müsste die Serial Number 2018110501 heißen.
nein, wie kommst du zu dieser annahme? die SR hat nix mit dem Zeitstempel zu tun!in der rfc1912 wird nur empfohlen, das aktuelle Datum mit einem zweistelligen zähler zu nutzen!
den Zeitstempel in der SR jede nacht zu ändern, würde in meinen augen nur unötige zonentransfers und netzwerk last erzeugen!
In diesem Fall wird es aber 2018110402 sein.
2018110402 wäre ja auch richtig!deine anwendung/skript wird mit der änderung klarkommen, es geht wohl nur um das format.
Gruß,
Dani
Zitat von @137443:
Moin,
dann machst du dir halt auf dem Master ein Skript das die Seriennummer um 00:00 Uhr per Taskplaner auf das entsprechende Datum mit Zähler 00 setzt. Der dadurch zusätzlich ausgelöste Sync sollte den Braten ja heutzutage nicht mehr fett machen.
du scheinst nur kleine netze zu verwalten... Moin,
dann machst du dir halt auf dem Master ein Skript das die Seriennummer um 00:00 Uhr per Taskplaner auf das entsprechende Datum mit Zähler 00 setzt. Der dadurch zusätzlich ausgelöste Sync sollte den Braten ja heutzutage nicht mehr fett machen.
nun ja.. wenn du nur 2-3 zonen hast nicht... wenn du einiges mehr hast, erzeugst du schon last!
unötige zonentransfers machen einfach keinen sinn...
Gruß l.
@Frank
also 20181104 + 1D (so lese ich es, deswegen der Verweis auf das Zeitproblem...)
Es erfolgt im Laufe des Tages wieder eine Änderung in der besagten DNS-Zone
also 20181104 + 1D (so lese ich es, deswegen der Verweis auf das Zeitproblem...)
Das ist korrekt, auf der anderen Seite über etwas philosophieren, worüber wir auf einer Seite nur einen weissen Flecken haben (Sinn, Software, Version) ist das leider ähnlich...
Vielleicht ist die Anwendung auch einfach nicht kompatibel mit MS-Servern?
Moin...
ich denke das script braucht mindestens 10 digits um zu arbeiten...
Frank
Zitat von @certifiedit.net:
Das ist korrekt, auf der anderen Seite über etwas philosophieren, worüber wir auf einer Seite nur einen weissen Flecken haben (Sinn, Software, Version) ist das leider ähnlich...
Vielleicht ist die Anwendung auch einfach nicht kompatibel mit MS-Servern?
Bind macht es aber auch nicht anders....Das ist korrekt, auf der anderen Seite über etwas philosophieren, worüber wir auf einer Seite nur einen weissen Flecken haben (Sinn, Software, Version) ist das leider ähnlich...
Vielleicht ist die Anwendung auch einfach nicht kompatibel mit MS-Servern?
ich denke das script braucht mindestens 10 digits um zu arbeiten...
Frank
Hi Dani
und wenn du dir eine "Krücke" baust und dir einen passenden DNS Server dazwischen setzt der das Format korrekt anlegt?
Ich meine jetzt nicht die DNS Zone zu replizieren, sondern die Daten via Script auslesen und auf den anderen DNS Server setzen, dann würde der (BIND) DNS Server der die DNS Daten alle erstellt bekommen und diese im korrekten Format vorliegen haben (weil er sich selbst die SN setzt und diese nicht vorgegeben bekommt) oder benötigt deine Software explizit MS DNS mit AD Integration?
Gruß
@clSchak
und wenn du dir eine "Krücke" baust und dir einen passenden DNS Server dazwischen setzt der das Format korrekt anlegt?
Ich meine jetzt nicht die DNS Zone zu replizieren, sondern die Daten via Script auslesen und auf den anderen DNS Server setzen, dann würde der (BIND) DNS Server der die DNS Daten alle erstellt bekommen und diese im korrekten Format vorliegen haben (weil er sich selbst die SN setzt und diese nicht vorgegeben bekommt) oder benötigt deine Software explizit MS DNS mit AD Integration?
Gruß
@clSchak
Hallo Dani.
was uBound/PowerDNS machen kann ich nicht sagen.
Gruß,
Dani
Frank
Zitat von @Dani:
Hallo Frank,
also Bind zählt stumpf weiter hoch, das ist fakt, und habe ich grade noch mal getestet...Hallo Frank,
nein, wie kommst du zu dieser annahme? die SR hat nix mit dem Zeitstempel zu tun!
in der rfc1912 wird nur empfohlen, das aktuelle Datum mit einem zweistelligen zähler zu nutzen!
Probier es an einem Bind/uBound/PowerDNS einmal aus. Die halten sich meines Wissens bzw. laut einer Anfrage bei unseren Linux Jungs alle an das RFC.in der rfc1912 wird nur empfohlen, das aktuelle Datum mit einem zweistelligen zähler zu nutzen!
was uBound/PowerDNS machen kann ich nicht sagen.
deine anwendung/skript wird mit der änderung klarkommen, es geht wohl nur um das format.
Davon gehen wir aktuell aus. Wobei es nur eine Vermutung ist, die bisher nicht vom Hersteller verifiziert wurde.Gruß,
Dani
Hallo Dani,

Zitat von @Dani:
Hallo Frank,
also da gibbet keine Paramter Hallo Frank,
also Bind zählt stumpf weiter hoch, das ist fakt, und habe ich grade noch mal getestet...
vielen Dank für deinen Test. Ist es evtl. ein Parameter in der Konfiguration von BIND, wie er sich diesbezüglich verhalten soll?Unabhängig davon hake ich intern nochmals nach. 
Gruß,
Dani
FrankGruß,
Dani
Hallo Dani,
ich habe da noch was gefunden:
4.3. The Serial Number
The most important issue is that this value be incremented after any modification to the zone data. For debugging purposes it has shown to be helpful to encode the modification date into the serial number. The value "1999022301" so is an example of the YYYYMMDDnn scheme and must be replaced by proper values for the year (YYYY, four digits), month (MM, two digits), day of month (DD, two digits) and version per day (nn, two digits). The first version of the day should have the value "01". It is important to preserve the order year - month - day. People using this as a debugging aid must, however, not rely on the date information, since experience shows that after initial setup maintainance of this value is often left to the auto-increment feature the software sometimes provides. Other schemes exist - documentation of which is out of the scope of this document.
Quelle: Recommendations for DNS SOA Values
da steht ja drin, das es ist wichtig ist, dass die digits für Jahr - Monat - Tag erhalten bleiben sollen...
und so kenne ich das auch nur...
allerdings könnte ich mir vorstellen, das PowerDNS deinen wunsch erfüllen kann, da du dort ja die SQL DB per script ändern kannst...
aber, wie du schon weiter oben geschrieben hast, ist das eine manipulation am DNSSEC ...
Frank
ich habe da noch was gefunden:
4.3. The Serial Number
The most important issue is that this value be incremented after any modification to the zone data. For debugging purposes it has shown to be helpful to encode the modification date into the serial number. The value "1999022301" so is an example of the YYYYMMDDnn scheme and must be replaced by proper values for the year (YYYY, four digits), month (MM, two digits), day of month (DD, two digits) and version per day (nn, two digits). The first version of the day should have the value "01". It is important to preserve the order year - month - day. People using this as a debugging aid must, however, not rely on the date information, since experience shows that after initial setup maintainance of this value is often left to the auto-increment feature the software sometimes provides. Other schemes exist - documentation of which is out of the scope of this document.
Quelle: Recommendations for DNS SOA Values
da steht ja drin, das es ist wichtig ist, dass die digits für Jahr - Monat - Tag erhalten bleiben sollen...
und so kenne ich das auch nur...
allerdings könnte ich mir vorstellen, das PowerDNS deinen wunsch erfüllen kann, da du dort ja die SQL DB per script ändern kannst...
aber, wie du schon weiter oben geschrieben hast, ist das eine manipulation am DNSSEC ...
Frank
Da komme ich gerade nicht mit. Was haben Zeitprobleme mit meiner Frage zu tun? Wir holen uns die Zeit über DCF77 bzw. GPS Empfänger.
Ok, nehmen wir an ich setze die Serial Number auf 2018110400. Das funktioniert und wird problemlos repliziert. Werden heute noch Änderungen an der DNS-Zone durchgeführt, zählt die Serial Number entsprechend hoch. Nun springt der Zeiger der Uhr von 23:59 auf 00:00/00:01. Es erfolgt im Laufe des Tages wieder eine Änderung in der besagten DNS-Zone. Somit müsste die Serial Number 2018110501 heißen. In diesem Fall wird es aber 2018110402 sein.
Heisst für mich, entweder spinnt der DNS in Hinsicht auf die Zeit oder die Zeit ist grundsätzlich ein Problem.
Prüf das mal ganz basic-a-like.
Nabend Dani,

Inzwischen liegt auch ne korrigierte Antwort auf meine Frage vor. Du hattest Recht. Es wird in dem meisten Fällen über ein Script bzw. über die Interaktion in der Weboberfläche die entsprechende Serial Number gesetzt. Somit muss nicht jeder Nacht dier Serial Number gesetzt werden, was zu einem NOTIFY auf allen anderen Server führt, sondern bei Bedarf.
Wieder das technische Wissen erweitert. Hilft mir aber nicht wirklich weiter.
was ist das für ein Programm / Script ?
Frank
Gruß,
Dani
Zitat von @Dani:
Guten Abend Frank,

nee, hast du ja auch nicht... ich habe nur meine aussage überprüft.. ich hatte fast zweifel daran Guten Abend Frank,
da steht ja drin, das es ist wichtig ist, dass die digits für Jahr - Monat - Tag erhalten bleiben sollen...
und so kenne ich das auch nur...
Nichts anders habe ich behauptet, oder? und so kenne ich das auch nur...
Inzwischen liegt auch ne korrigierte Antwort auf meine Frage vor. Du hattest Recht. Es wird in dem meisten Fällen über ein Script bzw. über die Interaktion in der Weboberfläche die entsprechende Serial Number gesetzt. Somit muss nicht jeder Nacht dier Serial Number gesetzt werden, was zu einem NOTIFY auf allen anderen Server führt, sondern bei Bedarf.
Wieder das technische Wissen erweitert. Hilft mir aber nicht wirklich weiter.
Frank
Gruß,
Dani