Die Entwicklung des Einsatzes von IP-Vernetzung im deutschen Amateurfunkdienst ist fast so alt, wie die weltweite Entwicklung von Homecomputer und PC. Der Aufbau des AX.25 basierten Packet-Radio-Netzes im Amateurfunk war gleichermaßen Plattform und Initialzündung für Experimente mit TCP/IP-gestützter Kommunikation zwischen entfernten Standorten. Die Verbreitung von TCP/IP im deutschen Amateurfunk verlief nicht immer reibungsfrei. Heute gehören für einen Funkamateur die Nutzung von HAMNET und HAMCLOUD genauso selbstverständlich dazu wie die Nutzung des Internet.

Bereits Ende der achtziger, Anfang der neunziger Jahre setzte in einigen Regionen in DL das Interesse für TCP-basierte Übertragungen im digitalen Amateurfunknetz ein. Der von Phil Karn KA9Q entwickelte IP-Protokollstack und die weltweit einsetzende Verbreitung von PCs auf 8086-Basis ermöglichten es, mit verhältnismäßig geringem Aufwand TCPIP-basierte Dienste auf DOS-Maschinen abzuwickeln.

1987

Ralf D. Kloth DL4TA war der erste IP-Koordinator in Deutschland. Die IP-Adressen wurden von Ralf DL-weit seit 1987 (= Zeitpunkt der allerersten AMPR TCP/IP-Aktivitäten in DL mit KA9Q-Software) koordiniert und für die Allgemeinheit in den Packet-Radio Mailboxen im HOSTS-Format veröffentlicht.

Die erste Liste stammt aus dem Jahr 1987 und bestand aus genau zwei Einträgen: DJ7KA (Uli Wandel, Betreiber von DB0AAA/DB0AAU) und DL4TA. Wenige Tage später kam DK5SG dazu (Dieter Deyke alias N0PRA, WAMPES-Entwickler und damaliger Betreiber von DB0SAO). Etwa zeitgleich begann die Zusammenarbeit via Netzwerk mit zunächst Bdale Garbee KB0G und später Brian Kantor WB6CYT.

Die letzte von DL4TA veröffentlichte Liste (Stand 05-Nov-1997) enthielt mittlerweile 4014 Adresseinträge. Dies entspricht einer Zunahme von etwa 1 Eintrag pro Kalendertag.

1997

Die Zuständigkeit für die Verwaltung der IP-Adressen in DL ist mit Wirkung vom 01.12.1997 von DL4TA zunächst an Detlef Brunkel DH9KAE übergeben worden. Aus persönlichen Gründen musste Detlef dieses Amt jedoch nach gut einem Jahr wieder aufgeben.

1999

Seit 1999 lag die DL-IP-Adresskoordination dann bei Fred Baumgarten DC6IQ. Die technische Entwicklung und der Bedarf an IP-Zuteilungen bzw. Änderungen von Zuweisungen nahmen in den folgenden Jahren rasant zu. Das Subzonen-Konzept wurde ausgeweitet. IP-Listen mussten wegen unterschiedlicher Softwareanforderungen in verschiedenen Formaten erstellt, abgeglichen, ineinander umgewandelt und auf mehreren Wegen veröffentlicht werden. Der Arbeitsaufwand für den IP-Koordinator stieg in gleichem Maße. Die Koordination konnte kaum noch von einer Einzelperson mit vertretbaren Wartezeiten durchgeführt werden. Zusätzliche berufliche und private Veränderungen brachten dann das Ende der DL-IP-Koordination durch DC6IQ zum Ende des Jahres 2003.

2003

Vorausgegangen war eine Diskussion in der Amateurfunk-Newsgroup ampr.de.config, die im April 2003 begann und einige Wochen andauerte. An dieser Diskussion und Meinungsbildung waren zahlreiche Aktive Funkamateure aus ganz DL beteiligt. Besprochen wurden insbesondere die Punkte

• Status Quo des bisherigen DNS Subzonenprojektes,
• Schwachstellen und Lösungsmöglichkeiten,
• die Notwendigkeit von mehreren DL-Koordinatoren (Arbeitsteilung, Ausfallsicherheit usw.).

In der Zeit vom 15.10.2003 bis 31.10.2003 wurden dann in einem online-Wahlverfahren (Wahlleiter Jens Schoon DH6BB) von den Funkamateuren die drei neuen IP-Koordinatoren für DL gewählt. Das AMPRNet IP-Koordinatorenteam für Deutschland bestand seitdem aus 3 Personen

• Egbert Zimmermann DD9QP,
• Thomas Osterried DL9SAU und
• Thomas Maisl DL3SBB.

2011

Am 02.04.2011 schied Tom Maisl DL3SBB auf eigenen Wunsch aus dem Team der IP-Koordination aus. Als neues Mitglied wurde vom verbliebenen Team Jann Traschewski DG8NGN berufen, der sich zur Mitarbeit bereit erklärte. Das Team der IP-Koordination DL stellte sich anlässlich der IPRT 2011 in Darmstadt der Öffentlichkeit vor. Es besteht seitdem aus den folgenden drei Mitgliedern:

• Egbert Zimmermann DD9QP,
• Thomas Osterried DL9SAU und
• Jann Traschewski DG8NGN

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.

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:

• Why is the ampr.org namespace flat?

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

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.

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

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

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

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:

• Datei "koord.html": Zonen, Netze, Koordinatoren, Digipeater

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.

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

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

Die IP-Koordination DL betrieb bis 2023 an drei örtlich getrennten Standorten jeweils einen Domain Name Server als DNS-Hub, welche eine redundante Erreichbarkeit aus dem HAMNET gewährleisten sollten. Die Nameserver konnten neben den Anfragen für die eigenen Zonen „de.ampr.org“ und „r1.ampr.org“ auch andere Anfragen beantworten.

Hostname: dl-sued.ampr.org
IP-Adressen: 44.130.60.100
UDP-Port: 53
TCP-Port: 53

Verantwortlich: IP-Koordination Deutschland, Jann Traschewski, DG8NGN

Hostname: dl-ost.ampr.org
IP-Adresse: 44.130.90.100
UDP-Port: 53
TCP-Port: 53

Verantwortlich: IP-Koordination Deutschland, Thomas Osterried, DL9SAU

Hostname: dl-west.ampr.org
IP-Adresse: 44.149.28.10
UDP-Port: 53
TCP-Port: 53

Verantwortlich: IP-Koordination Deutschland, Egbert Zimmermann, DD9QP

Das Konzept setzte auf dem 2003 im deutschen Packet-Radio-Netz vorgefundenen Status Quo auf und implementierte Bewährtes. Gleichzeitig wurden neuartige, automatisierte Verfahren eingesetzt, die die Fehleranfälligkeit minimieren sollten und den Arbeitsaufwand für Sysops und Regionalkoordinatoren vor Ort deutlich reduzieren halfen. Außerdem ermöglichte es in seinem Endausbau einen automatischen Ablauf mit zuverlässigem, überregionalen Austausch wirklich aller Zonen in ganz DL bei gleichzeitig voller Synchronisation auf die Master-DNS von „ampr.org“.

Die flache Domainstruktur ampr.org wurde innerhalb Deutschlands in Regionalzonen aufgegliedert. Um sich von künftigen Regionalisierungen im Ausland unterscheiden zu können, mussten die Regionalzonen national eindeutig gekennzeichnet werden.

Die Zonendaten wurden lokal auf Regional-DNS vorgehalten und auf 5 DNS-Hubs in 5 Groß-Regionen verteilt.

Den lokalen Subdomains wurden von der IP-Koordination DL Netzwerkblöcke zugewiesen und auf einen zuständigen Regional-DNS delegiert. Dort konnten die Regional-Koordinatoren aus dem ihnen zugeteilten IP-Adresskontingent (meist ein bis zwei 44.130.xx/24 Netze) die IP-Adressvergabe für eine geografisch begrenzte Region innerhalb Deutschlands selbst durchführen. Gebiete bzw. Zonen in Deutschland, für die es keine Regionalkoordinatoren gab, wurden von der IP-Koordination DL direkt betreut.

Pflege, Zonentransfer und Transformation auf die weltweite, flache ampr.org-Domain erfolgten nach einem festgelegten Schema:

Sysadmins von Digipeatern bzw. dort angebundener Server in Aktivitätszonen, die einen eigenen DNS-Server betreiben (wollen), der für eine oder mehrere Regionalzonen in ihrer Umgebung authoritativ ist, müssen die Zonendateien per Zonentransfer ihres laufenden DNS-Servers nur noch bei dem für sie zuständigen DNS-Hub abliefern. Dies wird durch entsprechende Einträge in der Konfigurationsdatei für den lokalen DNS-Server sichergestellt. Die DL-IP-Koordination stellt zu diesem Zweck passende Scriptdateien zur Verfügung, die auf allen DNS-Hubs zum Download verfügbar sind.

Die Sysadmins brauchen sich nicht mehr um den Austausch und die weitere Verbreitung ihrer Zone in der ganzen Republik zu kümmern. Der Zonentransfer geschieht automatisch per Notify sofort nach einer Änderung/Aktualisierung durch den Regionalzonen-Koordinator oder nach Ablauf der Gültigkeitsdauer der verfügbaren Daten im lokalen DNS-Server (TTL gesteuert). Hört der zuständige DNS-Hub von einem lokalen DNS seiner Region allerdings längere Zeit nichts, fragt er seinerzeit dort nach, ob es etwas Neues in der/den Regionalzone(n) gibt.

Datentransfer findet nur dann statt, wenn sich in einer Zonendatei wirklich etwas geändert hat. Durch die feste Zuordnung der lokalen DNS-Server einer (Groß-)Region auf einen darin erreichbaren DNS-Hub bleibt der Datenfluss auf die im allgemeinen sicher genug funktionierenden Interlinkstrukturen der Region beschränkt. Mehrfachbelastungen überregionaler Linkstrecken fallen komplett weg.

Das Einsammeln der Daten für die DL-weite Verteilung und die Updates im Internet auf HAMRADIO.UCSD.EDU geschieht somit in allen Regionalzonen nach dem BottomUp Prinzip.

Das Verteilen der Zonendateien von Zonen außerhalb der eigenen (Gross-)Region geschieht analog zum beschriebenen BottomUp ebenfalls scriptgesteuert nach dem Top-Down Verfahren. Auch dies geschieht durch die scriptgesteuerte Konfiguration des lokalen DNS-Servers am lokalen Digipeater automatisch.

Die lokalen DNS-Server holen sich völlig automatisch alle ihnen fehlenden Zonendateien von dem für sie zuständigen DNS-Hub und müssen nicht mehr kreuz und quer durch die Republik connecten.

Der hierzu erforderliche Traffic beschränkt sich ebenfalls auf die Interlinkstrukturen in der eigenen Region. Durch den Wegfall von Mehrfachübertragungen von immer den gleichen Daten werden auch hier überregionale Interlinkstrecken erheblich entlastet.

Da fast alle DNS-Hubs über direkte Internetanbindung verfügen, ist es für jeden, an einen solchen Hub angebundenen lokalen DNS-Server möglich, per Caching-Abfrage auch alle anderen, internationalen Domainnamen und damit auch die gesamte „ampr.org“-Domain auflösen zu können. Da dies mit Ausnahme von Grenzregionen relativ seltener geschieht, kann hierzu eine bei Erstanfragen etwas längere Wartezeit in Kauf genommen werden.

Man bedenke, dass das Auflösen beliebiger, aktueller IP-Adressen bisher für die meisten lokalen Digis nicht möglich war.

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.

Die seinerzeit von der DL-IP-Koordination entwickelten Prinzipien zu einem strukturierten Aufbau vollautomatischer DNS-Systeme haben sich sehr bewährt.Sie wurden in modifizierter Form in der DNS-Struktur von HAMNET und HAMCLOUD übernommen und bis 2023 betrieben. Routingprobleme, die seinerzeit zum Zusammenbruch des überregionalen Packet-Radio-Netzes geführt hatten, wurden durch die Einführung von automatischen Routingprotokollen (BGP) und die 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.

• Der „Besitz“ einer persönlichen IP-Adresse ist heute für die Nutzung von HAMNET oder HAMCLOUD nicht mehr zwingend erforderlich.

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:

• Exkurs: TCP/IP ist hier unerwünscht

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.

• Der „Besitz“ einer persönlichen IP-Adresse ist heute für die Nutzung von HAMNET oder HAMCLOUD nicht mehr zwingend erforderlich.