DL-IP-Koordination
Zuletzt angesehen:

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen der Seite angezeigt.

Link zu der Vergleichsansicht

Beide Seiten, vorherige ÜberarbeitungVorherige Überarbeitung
archive:history:de-ampr-org:devel [03.01.2026 16:04 Uhr] – [DNS-Hubs] dd9qparchive:history:de-ampr-org:devel [04.01.2026 21:06 Uhr] (aktuell) – [Von Jägern und Sammlern ;-)] dd9qp
Zeile 158: Zeile 158:
  
 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:dns-system|HAMNET]] und [[hamcloud:|HAMCLOUD]] enthalten.   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:dns-system|HAMNET]] und [[hamcloud:|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 <del>überlastet</del> 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: 
- 
-  * **[[archive:history:de-ampr-org:ip_not_wanted|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:|HAMNET]] oder [[hamcloud:|HAMCLOUD]]  nicht mehr zwingend erforderlich.  **  
DL-IP-Koordination

Table of Contents


  • AKTUELL
  • HAMNET
  • HAMCLOUD
  • IPKOORD
  • MEETINGS
  • SERVICES

ARCHIV

  • Old News
  • Historie
  • Software
  • Diverses

  • Impressum
  • Datenschutz