"Prozesse" (in einer Firma) dienen der Modellierung der Realität. Ziel ist es, standardisierte Abläufe zu schaffen, die zum einen unter Anlegen von Metriken das Messen von Effizienz erlauben, zum anderen das Einarbeiten neuer Mitarbeiter erleichtern.
Die entwickelten (Geschäfts-) Prozesse sollten alle üblichen aber auch weniger üblichen Aspekte einer Aufgabe abbilden, mithin sollte der "Prozessarchitekt" qua Tätigkeit in den entsprechenden Bereichen und/oder adäquater Analyse der Vorgänge in diesen entsprechendes Wissen besitzen.
So weit so gut. Aber was passiert, wenn dem nicht so ist!? :-) (so breit, wie der Smiley grinsen müßte, bekomme ich ihn auf diese Weise gar nicht :-))
Das folgende ist sicherlich nicht typisch für den öffentlichen Dienst - read: es passiert nicht nur dort - aber meiner Erfahrung nach passiert das beschriebene dort ein wenig öfter als anderswo.
Gegeben sei eine "große" second level Domain aus dem Bereich der öffentlichen Verwaltung. Man kann sich denken, dass unterhalb dieser weitere Subdomains / third level domains - im Sinne delegierter Verantwortung - existieren.
Nun betreibt die öffentliche Verwaltung in den seltensten Fällen solche Sachen selber sondern beauftragt einen Dienstleister mit dieser Aufgabe. Für das Zusammenspiel an den Schnittstellen (zwischen der öffentlichen Verwaltung und dem Dienstleister) werden Prozesse modelliert (Wer darf was? Wie ist der Workflow?). Einer dieser Workflows betrifft naturgemäß die sogenannten Glue-Records für die Subdomain in der second level domain.
Im Konkreten Fall hat natürlich der "Besitzer" der second level domain das Recht, die NS-Einträge für delegierte domains zu ändern. Im Konkreten Fall hatte bedauerlicherweise der Besitzer/Betreiber der Subdomain keinerlei Recht, seine eigenen Glue-Records verändern zu lassen, obwohl er den Ansprechpartner beim Dienstleister - Telefonnummer als auch e-Mail-Adresse des Support-Centers - kannte. Er hatte allerdings ebenfalls keine Kenntnis über seinen Ansprechpartner beim "Besitzer" der second level domain. Mithin hatte er keinerlei Möglichkeit, seine zwischenzeitlich geänderten Nameserver-Namen anpassen zu lassen. Noch dazu war DNSSEC aktiviert worden, was auf verifizierenden resolver DNSen - sinnvollerweise - zur Nicht-Erreichbarkeit der entsprechenden Subdomain führte.
So weit, so schlecht. Wenn es nur das gewesen wäre,... Shit happens.
Jetzt wird es - insbesondere im Kontext der oben angedeuteten Prozess-Modellierung - allerdings erst lustig.
Der Support-Center des Dienstleisters ist - eigentlich sinnvollerweise - auch als "Zone-C" (Zonen-Kontakt) für die angesprochene second level domain im Whois-System eingetragen. Nur war in den Prozessen bisher nicht vorgesehen, dass auch externe "Quellen" "öffnungsberechtig" für Tickets bezüglich Schwierigkeiten mit der Domain - wie in diesem Fall bei Nicht-Erreichbarkeit der Subdomain für verifizierende Resolver - sind. Mithin sind die Prozesse vorgeblich vom BSI designt und dürfen nicht so einfach verändert werden.
Man hätte vielleicht jemanden Fragen sollen, der sich damit auskennt <sigh/>.
Jedenfalls hat es recht lange Gedauert und einiges an Kommunikation gebraucht, bis die Glue-Records angepasst waren. Als Nebeneffekt hat der Besitzer/Betreiber der Subdomain jetzt einen Ansprechpartner, um in Zukunft selbst seine Glue-records ändern zu lassen - im konkreten Fall waren effektiv wir es, die die Glue-Records haben anpassen lassen...
Keine Kommentare:
Kommentar veröffentlichen