Entwicklung des Regionalzonenkonzeptes
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/24 Netze) selbst die IP-Adressvergabe für ihre Region durchführen. Die Vergabe erfolgte oft 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. Jetzt konnte man 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 konnte. Der damalige DL-IP-Koordinator Fred Baumgarten DC6IQ hat diese Entwicklung sehr gefördert, obwohl sie von Brian Kantor, dem damaligen 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.
Netzstrukturen und Regionalzonen
Das historisch gewachsene Regionalzonenkonzept ist von der IP-Koordination DL in seinen Grundzügen übernommen worden. Die Zuweisung der Subnetze und Zonen auf die User und einen oder mehrere Digipeater, die TCP/IP-Dienste anbieten und einen DNS betreiben, sollte erhalten bleiben. Die IP-Koordination DL führte im damaligen Packet-Radio-Netz eine Analyse durch und fand Strukturen vor, die sich am besten mit Aktivitätsinseln, Aktivitätszentren und Regionen beschreiben ließen. Darin wurde eine Vielzahl von DNS-Regionalservern betrieben, die jeweils nur für kleine Teile des deutschen ampr.org-Netzes zuständig waren.
Aktivitätsinseln
(mehrere User, 1 Digipeater, ein Subnetz)
TCP/IP Aktivitäten fanden in der Regel im Einzugsbereich eines Digipeaters statt. Die Abwicklung von lokalen TCP/IP-Diensten war normalerweise problemlos und je nach Benutzerzugang auch mehr oder weniger schnell, solange sie sich auf lokale Dienste beschränkte. Die Linksituation spielte dabei keine dominierende Rolle. Bandbreitenkritische Anwendungen waren ansatzweise möglich und fast nur von der Geschwindigkeit der Userzugänge abhängig. Solche „Aktivitätsinseln“ bildeten die kleinste Einheit im deutschen Packet-Radio-Netz und waren im Land überall verstreut aufzufinden. Traditionell wurde diesen Aktivitätsinseln ein 44.130.xx/24 Netzblock zugewiesen und auf Wunsch eine Regionalzone zugeteilt. An den meisten der beteiligten Digipeater wurde ein Host auf Linux-Basis betrieben, der einen autoritativen Nameserver für die Zone hatte. Er bot für die User weitere Dienste an. Ein Regionalzonen-Koordinator war mehr oder weniger aktiv.
Aktivitätszentren
(mehrere User, mehrere Digipeater, ein oder mehrere Subnetze)
Oftmals wuchsen innerhalb einer solchen Zone die Userzahlen und ihre Aktivitäten über den Einzugsbereich eines einzelnen Digipeaters hinaus. Es entstanden Aktivitätszentren, wo mehrere unmittelbar benachbarte Digipeater mit ihren Usern innerhalb einer Zone TCP/IP Betrieb ermöglichten. Die Linksituation, bezogen auf die Übertragungssicherheit zwischen benachbarten Digipeatern, war bei 1-2 Hops in der Regel gut, besonders dann, wenn die Geschwindigkeit auf den Interlinks ein Mehrfaches der Geschwindigkeit der Userzugänge betrug. Solche Aktivitätszentren hatten ebenfalls meist einen für die ganze Zone autoritativen Nameserver an einem der beteiligten Digipeater. Es waren ein oder (meist wegen der hohen Userzahl) zwei 44.130.xx/24 Netze innerhalb einer Zone zugewiesen. In einigen Fällen wurden auch mehrere Nameserver betrieben die gleichberechtigt für die ganze Zone autoritativ waren („hidden Primaries“). Ein Regionalzonenverwalter und ein bis zwei DNS-Administratoren waren mehr oder weniger aktiv.
Regionen
(mehrere Aktivitätsinseln und/oder Aktivitätszentren mit guter interner Vernetzung)
Abhängig von der Struktur des Packet-Radio Netzes liessen sich Regionen ausmachen, in denen benachbarte Aktivitätszentren über die zwischen ihnen vorhandenen Interlinks TCP/IP-Betrieb abwickelten. Innerhalb dieser Gebiete funktionierte in der Regel das IP-Routing zwischen den Zonen gut und stabil. Diese interne Interlinkvernetzung ermöglichte dauerhaften, sicheren und meist auch redundanten TCP/IP Betrieb für schmalbandige Anwendungen wie Email, News, Convers, DX-Cluster, Funkruf usw. Der automatische Austausch von Zonendateien zwischen Nameservern stellte ebenfalls eine schmalbandige Anwendung dar und funktionierte meist problemlos. Multimediales WWW oder FTP war bereits eingeschränkt möglich. Man behalf sich mit Caching-Proxies mit und ohne Kompressionsverfahren (z. B. Squid) und , im Vergleich zum Internet, relativ hohen Haltezeiten, die allerdings im Amateurfunk tolerierbar waren.
Anwendungen, die Echtzeitcharakter haben, z.B. Streamingverfahren, waren wegen der geringen Bandbreite auf den damaligen Interlinkstrecken kritisch und keinesfalls Standard. Die Ausdehnung solcher Regionen konnte sehr unterschiedlich sein und durchaus die Größenordnung eines Bundeslandes erreichen. Sie war in erster Linie von der in der Region vorherrschenden Link-Situation und User-Aktivität abhängig und ließ sich nicht an politischen, verwaltungsrechtlichen oder geografischen Grenzen festmachen.
Regionalzonen DNS
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. Weil ein DNS-Netz konzeptionell streng hierarchisch aufgebaut ist, wurde die flache Domainstruktur ampr.org innerhalb Deutschlands in Regionalzonen aufgegliedert und logisch unter der nationalen Zone de.ampr.org zusammengefasst. Auch in einigen Nachbarländern machte man diesbezüglich Versuche (Luxemburg, Belgien, Österreich).
Die Syntax für die Bezeichnung einer Regionalzone leitete sich daher wie folgt ab:
<Zonenname>.<Landeskenner>.ampr.org
Daraus entstanden in DL 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. Im April 2009 waren 79 Zonen koordiniert.
ac amk augsb baden bawue bln bri brsg brv bs dahme dd doi dssd eeosl enz erf esa goe h havel hdf hh hhm hhn hhs hi hot hrh husum in inet itzehoe ka kiel ks lake lg lpz luebeck mainz me mosel ms mue myk nbg ndh neisse nw nww oder ofr ohvl os ostbay osx owl pe pfalz pgntz rmn rnk ros rr rsk saar shg si ssa stgt sthur swb ual ufra wat wen westmfra wsx
Maximal sind unter 44.130/16 bis zu 255 44.130.x.x/24 Netzblöcke auf Regionalzonen in der Form von <zonenname>.de.ampr.org abbildbar. Zu beachten ist, dass einige Regionalzonen mehr als einen 44.130.x.x/24 Netzblock zugewiesen bekommen hatten.
Die Netze und ihre Koordinatoren wurden in den 1990er Jahren ursprünglich in einer Datei „koord.html“ von DO2KSM zusammengetragen. Diese Datenbestände hat die IP-Koordination DL seit 2003 durch umfangreiche und langwierige Recherchen zumindest in Teilen aktualisieren können. Diese Liste ist veraltet und wird nicht mehr weiter gepflegt:
Der IP-Koordination DL war es bis zu diesem Zeitpunkt in einer DL-weiten Initiative gelungen, alle Regional-DNS miteinander zu vernetzen und den Austausch der Zoneninformationen per Zonentransfer mit Hilfe von NOTIFYing (Bestandteil des Bind-DNS-Protokolles) so zu automatisieren, dass alle Regional-DNS alle Zonendateien lokal vorhielten. Jeder User konnte nun, egal in welcher Region er sich befand, auf ALLE Zonendaten des gesamten deutschen ampr.org Netzes zugreifen. Die schiere Anzahl an Zonendateien (bis zu 512 forward und reverse Zonen), die nun kreuz und quer durch die ganze Republik gesendet werden mussten, führte zu zahlreichen Mehrfachübertragungen auf den damals noch langsamen Interlinkstrecken.
Groß-Regionen
Charakteristisch für das TCP/IP-Amateurfunknetz in DL waren meist historisch gewachsene Regionen, innerhalb derer das TCP/IP-Routing und der Nameserver-Betrieb recht stabil funktionierten. Diese „Inseln“ verteilten sich über die Fläche der Republik und waren durch mehr oder weniger große Gebiete unterbrochen, in denen es (noch) keine bemerkenswerten TCP/IP Aktivitäten gab. Sie waren oft zu weit voneinander entfernt und die Netzverbindungen zwischen ihnen zu schlecht, als dass zwischen diesen Regionen direkt sinnvoller TCP/IP Betrieb stabil möglich war.
Insbesondere war ein automatischer Zonentransfer von Nameservern zwischen diesen Regionen äußerst problematisch und wegen des kritischen Timeoutverhaltens neuerer DNS-Software teilweise sogar unmöglich. Als geradezu klassischer Dauerbrenner sei beispielhaft die über viele Jahre fast nie stabil funktionierende Verbindung zwischen der NORD-Region (TheNetNode-Land) und anderen Regionen (FlexNet-Land) in DL erwähnt.
Nach genauerer Analyse der damaligen Netzstrukturen in Deutschland machte die IP-Koordination DL fünf größere Gebiete aus, innerhalb derer die einzelnen Regionen gut genug vernetzt waren, um stabilen DNS-Betrieb machen zu können.
Die Zusammenfassung mehrerer benachbarter Regionen zu Großregionen
Diese fünf Groß-Regionen im deutschen TCP/IP-Netz waren:
* Großregion NORD-DL: Großraum Norddeutschland * Großegion SUED-DL : Großraum Süd-Deutschland * Großregion OST-DL : Großraum Berlin, "neue" Bundesländer * Großregion WEST-DL : Großraum West-Deutschland * Großregion MITTE: Großraum Zentraldeutschland
DNS-Hubs
Die IP-Koordination DL führte mit den DNS-Hubs in den Großregionen einen weiteren Layer im hierarchischen DNS-System ein. Basierend auf den fünf Großregionen wurde von der IP-Koordination DL jeweils ein zentral und gut erreichbarer DNS-Hub-Server pro Großregion eingeplant. Drei der fünf DNS-Hubs waren über schnelle Internettunnel direkt vernetzt und verfügten jeweils über sämtliche Zoneninformationen von ganz DL. Zusätzlich konnten sie alle anderen Informationen der internationalen ampr.org-Zone ausliefern und auch alle DNS-Anfragen für sonstige Internet-Adressen beantworten. Die Namensbezeichner der DNS-Hubs wurden aus der Einteilung in Großregionen abgeleitet.
* Großregion NORD-DL: CNAME: hub-nord.ampr.org * Großregion SÜD-DL: CNAME: hub-sued.ampr.org * Großregion OST-DL: CNAME: hub-ost.ampr.org * Großregion WEST-DL: CNAME: hub-west.ampr.org * Großregion MITTE: CNAME: hub-mitte.ampr.org
Siehe auch:
Hierdurch wurde das DNS-System im deutschen Amateurfunknetz entscheidend verbessert:
- Mehrfachübertragungen von Zonendateien wurden auf ein Mindestmaß reduziert.
- Laufzeitverhalten und Stabilität des DNS-Systems wurden verbessert.
- Änderungen im Datenbestand waren in allen Großregionen nahezu in Echtzeit verfügbar.
- DNS-Regionalserver konnten „ihren zuständigen“ DNS-Hub schnell und sicher erreichen.
- DNS-Regionalserver waren nur noch für ihre eigene(n) Zone(n) authoritativ.
- DNS-Regionalserver konnten für unbekannte Zonen als einfache Cache-Server betrieben werden.
- Wesentlich vereinfachte Pflege und Wartung der DNS-Server durch die Admins einer Region.
- Automatisierte Übersetzung/Übertragung deutscher de.ampr.org-Zonen in die weltweite ampr.org Zone wurde möglich.
Von diesem Zeitpunkt an waren praktisch alle DNS-Daten in jeder Region, jedem Aktivitätszentrum, jeder Aktivitätsinsel bis hin zum einzelnen User an einem Digipeater online verfügbar. Dieses Prinzip hat sich sehr bewährt und ist auch heute noch in modifizierter Form in der DNS-Struktur von HAMNET und HAMCLOUD enthalten.
Von Jägern und Sammlern ;-)
Mit der Zunahme von TCP/IP-Aktivitäten im deutschen Packet-Radio-Netz begann schon frühzeitig die Zeit des großen Sammelns.
Jeder Sysop, der etwas auf sich hielt, wollte die Daten aller Regionalzonen möglichst aktuell auf seinem TCP/IP-Server verfügbar haben, um das TCP/IP-Netz zusammenhalten zu können. Digipeater mit eigenem DNS versuchten 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 für den „Refresh“ sorgten zusätzlich dafür, dass ein 120 Zonendateien auf den wichtigen, überregionalen Interlinkstrecken zig-fach am Tag hin und her transportiert wurden. Interlinkstrecken verfügten damals über Geschwindigkeiten von nur 9600 bis 19200 Baud. Manche Interlinkstrecken wurden durch diesen Automatismus unnötigerweise überlastet belastet. Der andauernde Überlastungszustand wichtiger Strecken wurde fast zum Dauerzustand. Das führte fast zwangsläufig zu Unzufriedenheit und Anfeindungen zwischen Anwendern, Sysops und Betreibergruppenruppen:
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. Das Routing von IP-Netzen musste manuell eingestellt und gepflegt werden. 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 zwingend geboten. Eng damit verknüpft ist die Koordination der IP-Adressen, deren Organisation sich an der hierarchischen Grundstruktur des DNS-Systems orientieren musste, wenn sie effektiv sein sollte.
Mit der Einführung von HAMNET und HamCloud in Deutschland und den Nachbarländern wurde das grundsätzliche Prinzip der Regionalisierung von DNS-Daten in Subdomain-Zonen beibehalten. Routingprobleme, die seinerzeit zum Zusammenbruch des überregionalen Netzes geführt hatten, wurden durch die Einführung von automatischen Routingprotokollen (BGP) und Aufteilung des IP-Adressraumes auf „Autonome Systeme (AS)“ gelöst. Die Zuteilung persönlicher IP-Adressen wurde obsolet und es erfolgte die Verwaltung und Anbindung von IP-Adressen in Form von IP-Subnetzen an die enstehenden AS.