03.11.2018, aktualisiert am 04.11.2018

3542

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

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: 24.03.2025 um 12:03 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

Guten Morgen,

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

Guten Morgen Christian,

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.

wenn es so einfach wäre, hätten wir die Variante weiterverfolgt. Aber der Hersteller weisst auf das Standardformat (ist wohl genormt o.ä.). Was die Anwendung genau macht, darf ich leider nicht sagen.

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.

Das war bezogen auf Microsoft (Support). Den der muss schließlich bei Problemen Gewehr zu Fuß stehen.

Gruß,
Dani

Guten Morgen Frank,

was hindert dich die Seriennummer hoch zu setzen?
ich sehe jetzt kein probelm darin: 2018110409 ; Serial

Ok, nehmen wir an ich setze die Serial Number auf 2018110401. 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 2018110502 sein.

Gruß,
Dani

Hast du Dokumente die die Definition der Anwendung in der Hinsicht unterlegen?

Ich nehme es zwar grundsätzlich nicht an, aber Zeitprobleme habt ihr keine? Obwohl das letzte Beispiel stark dafür spricht...

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.

moin Dani,

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

Frank

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...

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

@Frank

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...)

Zitat von @Vision2015:
unötige zonentransfers machen einfach keinen sinn...

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...

Zitat von @certifiedit.net:

Zitat von @Vision2015:
unötige zonentransfers machen einfach keinen sinn...

Bind macht es aber auch nicht anders....
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

Hallo Christian,

Hast du Dokumente die die Definition der Anwendung in der Hinsicht unterlegen?

Offizielle Unterlagen zur Funktionswiese von Anwendungen im tiefen Maschienenraum gibt es selten. Ich habe einen Kollegen beauftragt, die Anwendung mit Bind/PowerDNS zu testen. Dort funktioniert alles wie es soll. Einzigster (sichtbarer) Konfigurationsunterschied ist nach dem Vier-Augen-Prinzip die SOA Seriennummer.

Ich nehme es zwar grundsätzlich nicht an, aber Zeitprobleme habt ihr keine? Obwohl das letzte Beispiel stark dafür spricht...

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.

Gruß,
Dani

Hallo @137443,

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.

Soweit bin ich ja bereits. Siehe 3. Link in meiner Beitrag. Nur steht dort eben dass es nicht empfohlen ist. Das untermauert meinem Verständis nach auch der 2. Link deutlich.

Der dadurch zusätzlich ausgelöste Sync sollte den Braten ja heutzutage nicht mehr fett machen.

Es geht um eine 3stellige Anzahl von Zonen.

Gruß,
Dani

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.

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,

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.

also Bind zählt stumpf weiter hoch, das ist fakt, und habe ich grade noch mal getestet...
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

Frank

Hallo @clSchak,

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?

Daran habe ich bzw. ein Kollege auch schon gedacht.

Aber nach folgenden Überlegungen/Gegebenheiten wieder verworfen:

Es gibt nur eine handvoll an Kollegen, die DNS-Einträge editieren (anlegen, ändern, löschen) dürfen. Wir haben einige WRDC welche auch als DNS-Server (somit autoritativ und mit Active Directory Integration) fungieren. Der Rest sind RODCs mit der DNS-Rolle und somit automatisch als Slaves konfiguriert. Diese werden auch von allen Geräten im Netzwerk als Ansprechpartner herangezogen.
Alle DNS-Zonen sind mit DNSSEC gesichert. D.h. das Ganze wird auf den autoritativen DNS-Servern verwaltet. Dadurch sollen mögliche Manipultionsversuche unterbunden werden. Durch die Krücke ist meiner Meinung nach das DNSSEC aufgebrochen.
Ist der autoritativen Server X im LAN1 nicht verfübar, funktioniert die Krücke auch nicht mehr. Bei dem Master-Slave Konstrukt kann ich laut den Linux Jungs mehrere Masters angeben. D.h. die Replizierung ist gewährleistet.
Eine weitere Schnittstelle die betreut, gewartet, überwacht und entstört werden muss.

Somit gibt es zwei Möglichkeiten:

Auf DNSSEC verzichten. Ist auf Grund von Richtlinien nicht möglich.
Die Jungs von DNS müssen zukünftig zwei Systeme pflegen, was auf die Dauer doch ein zeitlicher Aufwand ist.

Dadurch das in dem LAN2 auch eine externes Unternehmen zu Gange ist, war eben unserer Idee die jeweiligen DNS-Zonen entsprechend auf 1-2-3 Linux-Server zu replizieren. Somit ist die Zone schreibgeschützt, die DNSSEC Signaturen bleiben gültig und es entsteht bei den DNS Jungs kein manueller Mehraufwand. Bis die Sache mit der SOA Seriennummer aufkam...

Gruß,
Dani

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

Hallo Dani,

Zitat von @Dani:

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?

also da gibbet keine Paramter

Unabhängig davon hake ich intern nochmals nach.

Gruß,
Dani

Frank

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

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.

Guten Abend Christian,

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.

Nein, ich habe mich vertippt.

Hab den Fehler oben im Kommentar korrigiert.

Gruß,
Dani

Das ist natürlich von einer gewissen Relevanz für den Gedankenansatz.

Also sprich aus
YYYYMMDD(x)ss(n)
Wird
YYYYMMDD(x+1)ss(n+1)

gefordert wäre aber, üblich

YYYYMMDD(x+1)ss(1)

?

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?

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.

Gruß,
Dani

Guten Abend Christian,
ich blick's langsam nicht mehr...

Das Format sollte wie @Frank bereits geschrieben hat YYYYMMDDss sein. Das ss steht für Sequenz Number.
Wie gesagt es geht nach wie vor um den DNS-Server von Microsoft. Die Umgebung habe ich weiter oben schon näher beschrieben.

Gruß,
Dani