Wie alles begann

Das Regionalzonenkonzept und die Arbeit von Regionalkoordinatoren hat sich vom Grundsatz her schon in den späten 1980er Jahren entwickelt.

Wegen der ausgeprägten „Inselstruktur“ mit schlechter bis gar nicht vorhandener TCP/IP-Konnektivität wurde in Deutschland bereits unter dem ersten IP-Koordinator Ralf D. Kloth DL4TA das Regionalkoordinatorensystem auf freiwilliger Basis eingeführt. Regionalkoordinatoren mit stark variierenden Fachkenntnissen und Motivationen waren für die Vergabe von IP-Adressen in ihrem Gebiet verantwortlich.

Diese konnten aus einem ihnen zugeteilten IP-Adresskontingent (meist ein bis zwei 44.130.xx/16 Netze) selbst die IP-Adressvergabe für ihre Region durchführen. Die Vergabe erfolgte oft völlig willkürlich und orientierte sich meist nicht an technischen Gesichtspunkten wie etwa der Unterteilbarkeit der Zone in weitere Subnetze zu Routingzwecken. Die von den Regionalkoordinatoren in der Region gepflegten Datenbestände lagen zudem in unterschiedlichen Formaten vor (flache, traditionelle „HOSTS“ Datei, Domaindateien für die diversen NOS-Programmvarianten, eigene Konstrukte).

Teilweise wurden diese Dateien der Allgemeinheit und dem nationalen IP-Koordinator über verschiedene Transportwege zugänglich gemacht. Dazu gehörten zum Beispiel die Verbreitung über die Packet-Radio-Mailboxen (Rubrik TCPIP). Auch die nicht überall in Deutschland verfügbaren Newssysteme wurden verwendet und in Einzelfällen zeitweise auch drahtgebundene Transportmechanismen.

Die Vielfalt der verwendeten Dateiformate bedingte von der Region bis hinauf zur weltweiten Verfügbarkeit oft mehrfaches Umwandeln von einem Format ins andere. Dies geschah nicht in einem standardisierten Verfahren, sondern eher willkürlich, je nach Geschmack des gerade zuständigen Koordinators. Es geht das Gerücht, das manche sogar alles von Hand editiert haben sollen. Dem Einschleichen von Fehlern und dem Verlust von Informationen waren Tür und Tor geöffnet.

DNS-Server brachten Zonenkonzept

In den 1990er Jahren wurden zunehmend Linuxsysteme in Amateurfunknetzen eingesetzt. Man konnte in vielen Regionen „echte“ BIND-Nameserver betreiben, auf denen ein Regionalkoordinator zumindest die IP-Adressen der eigenen und evtl. einiger benachbarter Regionen autoritativ und maschinennutzbar pflegen konnten. Der damalige DL-IP-Koordinator Fred Baumgarten DC6IQ hat diese Entwicklung sehr gefördert, obwohl sie von Brian Kantor, dem Maintainer von „ampr.org“, und anderen bereits Ende der 1980er Jahre im Internet kontrovers diskutiert wurde:

Zur Vielfalt der Dateiformate gesellten sich nun auch noch die BIND-Dateiformate, die ebenfalls kreuz und quer durch die Republik verteilt wurden.

Da ein DNS aber nur für eine begrenzte Teilmenge an Adressen, nämlich die seiner lokalen Region, authoritativ sein kann, wurde in Deutschland das Regionalzonenkonzept eingeführt. Die flache Domainstruktur ampr.org wurde innerhalb Deutschlands in Subdomains aufgegliedert. Auch in einigen Nachbarländern machte man diesbezüglich Versuche (Luxemburg, Belgien, Österreich). Um sich von künftigen Regionalisierungen im Ausland unterscheiden zu können, mussten die Regionalzonen national eindeutig gekennzeichnet werden.

Die Syntax für die Bezeichnung einer Regionaldomain leitet sich daher wie folgt ab:

<Zonenname>.<Landeskenner>.ampr.org

Daraus entstanden Konstrukte wie

rr.de.ampr.org   für die Region Rhein-Ruhr
dd.de.ampr.org   für die Region um Dresden
kiel.de.ampr.org für die Region um Kiel

und viele andere.

Von Jägern und Sammlern

Mit der Verbesserung der Netzwerkstruktur begann nun die Zeit des großen Sammelns.

Jeder Sysop, der etwas auf sich hielt, wollte möglichst aktuell die Daten aller Regionalzonen auf seinem TCP/IP-Server verfügbar haben, um das TCP/IP-Netz zusammenhalten zu können. Jeder Digipeater mit eigenem DNS versuchte bei möglichst allen(!) anderen in regelmäßigen Zeitabständen die dort autoritativ vorgehaltenen Zonendaten zu bekommen. Jeder einzelne Digipeater mit eigenem Nameserver benötigte damals ca. 120 dieser Zonendateien. Ungünstig gewählte Zeitintervalle sorgten zusätzlich dafür, dass ein und dieselbe Zonendatei auf den großen überregionalen Interlinkstrecken zigfach am Tag hin und her transportiert wurde. Manche Interlinkstrecken wurden durch diesen Automatismus unnötigerweise überlastet belastet. Dies führte zu Anfeindungen zwischen einzelnen Sysops oder Gruppen:

Trotz dieser Nachteile funktionierte der technische Zonentransfer per DNS jahrelang erstaunlich stabil. Allerdings fehlte irgendwo immer etwas. Server wurden umgebaut, IP- und ARP-Adressen geändert, TCP/IP-fähige Digis kamen hinzu, andere fielen weg. Jeder Sysop musste ständig die Parameter für alle Systeme in DL kennen und in seiner Konfiguration aktuell halten, obwohl diese Parameter nie regelmäßig oder gar zentral veröffentlicht wurden.

Die Aktualität und Authentizität der Daten konnte trotz größtem Eifer und Einsatz mancher Sysops nicht gewährleistet werden. Die Datenbestände drifteten regional auseinander und enthielten mehr und mehr Fehler. Schließlich waren sie praktisch nicht mehr bei ucsd.edu einpflegbar.

Bei vielen Koordinatoren aller Ebenen machten sich Enttäuschung und Frustration breit. Andere verloren aus anderen Gründen das Interesse oder hatten einfach keine Zeit mehr. In einigen Regionen entstand eine Art „Wildwuchs“ („wild.de.ampr.org“), ohne Synchronisation auf ucsd.edu. Heute würde man das im Internet als „IP-Spoofing“ oder „IP-Hijacking“ bezeichnen! Andernorts brach der TCP/IP Betrieb fast vollständig zusammen oder er beschränkte sich in seiner Funktionalität auf die berühmten „Inseln“ der Anfangszeit: Man war froh, wenn es mit dem direkten Nachbarn klappte.

Für moderne TCP/IP-gestützte Anwendungen ist ein funktionierendes DNS-System von essentieller Bedeutung und daher auch für den Amateurfunkdienst in DL dringend geboten. Eng damit verknüpft ist die Koordination der IP-Adressen, deren Organisation sich an der hierarchischen Grundstruktur des DNS-Systems orientieren muss, wenn sie effektiv sein soll.