ip-koordination:autoupdate

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen der Seite angezeigt.

Link zu der Vergleichsansicht

Beide Seiten, vorherige Überarbeitung Vorherige Überarbeitung
Nächste Überarbeitung
Vorherige Überarbeitung
Nächste ÜberarbeitungBeide Seiten, nächste Überarbeitung
dokumentation:ip-koordination:autoupdate [18.08.2009 19:13 Uhr] dd9qpip-koordination:autoupdate [15.08.2015 15:39 Uhr] – ↷ Seite von dokumentation:ip-koordination:autoupdate nach ip-koordination:autoupdate verschoben dd9qp
Zeile 1: Zeile 1:
 +===== DL und der Rest der Welt =====
  
 +==== Sammeln und Prüfen aller DL-Daten ====
 +
 +Das Bottom-Up Prinzip stellt sicher, dass alle in DL vorhandenen Zonendaten meist sehr schnell auf dem zuständigen Hub und dann auch auf den anderen Hubs verfügbar sind. Dies trifft für alle Netze zu, die mit einem DNS-Server am Regionalzonenkonzept angeschlossen sind oder ihre Zone mangels eigenem Nameserver direkt auf dem zuständigen Hub hosten wollen.
 +
 +Zu diesem Zweck werden von uns Zugriffsmöglichkeiten vorbereitet, die Regionalkoordinatoren, die eine Zone verwalten wollen, aber keinen eigenen Nameserver zur Verfügung haben, auf verschiedene Art und Weise die Pflege ihrer Zonendaten ermöglichen (Emailrobot, WWW-Interface usw.). Es ist derzeit auch ein WWW-Interface in Entwicklung, dass es ermöglicht, eine einfache HOSTS-Datei zu pflegen.
 +
 +Dies ist für Zonen interessant, die aus verschiedenen Gründen nicht am Regionalzonenkonzept teilnehmen bzw. keinen eigenen DNS-Server betreiben können. Die Teilnahme am Regionalzonenkonzept mit eigenem, lokalen DNS und die Pflege der Zone auf einem DNS-Hub schließen sich allerdings gegenseitig aus. Um die Konsistenz der Daten sicher zu stellen, kann man nicht beides haben.
 +
 +==== Autoupdate auf ucsd.edu ====
 +
 +Durch das neue DNS-Konzept wird weitgehend sichergestellt, dass nahezu alle Zoneninformationen automatisch auf den DNS-Hubs eintreffen. Bei einem der DNS-Hubs findet die Zusammenfassung und Überprüfung aller Daten statt.
 +
 +Sind einzelne Zonendaten nicht in Ordnung oder aus anderen Gründen nicht bei ucsd.edu updatebar, werden sie ausgesondert und der zuständige Regionalkoordinator verständigt. Er kann dann auf seinem lokalen DNS Korrekturen vornehmen. Der Rücktransport erfolgt dann im Rahmen des Konzeptes wieder wie oben beschrieben im Bottom-Up Verfahren ohne dass der Sysop oder Regionalkoordinator sich weiter darum kümmern muss.
 +
 +Sind die Daten in Ordnung, werden sie automatisch entsprechend aufbereitet und in regelmäßigen Zeitabständen an ucsd.edu übermittelt. Dort findet alle 24h ein Updatelauf statt, sodass neu eingelieferte Daten bei ucsd.edu spätestens nach einem Tag weltweit verfügbar sind.
 +
 +In welchen Zeitabständen ein Update der DL-Daten bei ucsd.edu stattfinden soll, ist noch nicht endgültig geklärt. Sicher ist zumindest, dass eine Updatefrequenz von weniger als einem Tag relativ sinnlos wäre.
 +Neu an diesem Verfahren ist, dass auch der Updateprozeß mit ucsd.edu weitgehend automatisiert abläuft und bei Ausfall eines Koordinators oder des dafür zuständigen Hubs ein anderer jederzeit diese Aufgabe übernehmen kann. Es bleibt also nichts mehr liegen.
 +
 +==== Laufzeiten ====
 +
 +Das weitgehend durchautomatisierte Verfahren stellt sicher, dass vom Eintrag einer Zuweisung durch einen Regionalkoordinator auf seinem DNS bis zum Erscheinen des Eintrages auf ucsd.edu keine endlos langen Wartezeiten mehr entstehen.
 +
 +Durch geeignete Einstellung der Timeouts in den Zonendateien muss Rücksicht auf Eigenheiten wie Geschwindigkeit und Belastbarkeit unseres Funknetzes genommen werden. Durch Verwendung moderner Bind-Versionen sind die Hubs in der Lage, von manchen Regionalkoordinatoren möglicherweise ungünstig gewählte TTL-Einstellungen in den Zonendateien zu überschreiben.
 +
 +Dynamische DNS-Updates mit schneller, weltweiter Verfügbarkeit und Lebensdauern von kleiner 5 Minuten nach dem Muster von DynDNS.Org sind im Amateurfunk nach unserer Einschätzung nicht notwendig. Nach dem derzeitigen Stand können wir sagen, dass im ungünstigsten Fall, wenn alle TTL-Timereinstellungen maximal greifen und alle Notifies verloren gehen würden, ein Zeitraum von maximal einer Woche vergehen kann, bis ein Neueintrag in einer Region bei ucsd.edu eingetragen ist. Dies gilt unter der Voraussetzung, dass das DNS-Konzept vollständig umgesetzt ist und alle Systeme (inkl.ucsd.edu) laufen. Wir halten dies für die Belange im Amateurfunk für vertretbar.
 +
 +In 98 Prozent der Fälle wird das deutlich schneller gehen und ist auch davon abhängig, auf welcher Ebene eine Verzögerung eintreten sollte.
 +
 +Lokal vor Ort ist eine Änderung oder ein Neueintrag in einem DNS praktisch sofort verfügbar. Ein neu eingetragener TCP/IP-User kann praktisch sofort arbeiten. Alle lokalen Anwendungen, die einen DNS-Eintrag erfordern, funktionieren ebenfalls sofort. Funktioniert der Notify vom lokalen DNS zum Hub, ist die aktualisierte Zonendatei innerhalb weniger Minuten am zuständigen Hub verfügbar und gültig.
 +
 +Weitere wenige Minuten später ist die Information auf allen Hubs abrufbar. Beispiel: Ein Zonenupdate nach erfolgtem Notify dauert von DB0RES zu DB0FHN oder einem anderen DNS-Hub erfahrungsgemäß keine 10 Sekunden. Danach steht die Information auch für das Updaten bei ucsd.edu bereit.
 +
 +Etwas länger dauert das Rückverteilen der aktualisierten Zonendaten auf alle Regionalserver in ganz DL. Wenn zwischen Hub und Regionalserver kein Notifying für alle Fremdzonen stattfindet (davon ist aus Gründen der örtlichen Linkbelastung abzuraten), wird die Datei erst dann lokal geupdated, wenn der jeweilige lokale DNS für die Zone das Timeout erreicht und bei seinem Hub nachfragt, ob sich für die Zone XY etwas geändert hat. Je nach gewählter TTL sollte dies nach 1-2 Tagen auf allen Nameservern in ganz DL geschehen sein.
 +
 +Damit alles optimal funktioniert, sind auf allen beteiligten Nameservern bestimmte technische Voraussetzungen zu erfüllen und Anpassungen an der Konfiguration der Nameserver vorzunehmen. Diese können nach unserer Einschätzung von der überwiegenden Mehrheit der in Betrieb befindlichen regionalen Nameserver eingehalten werden.
 +
 +Weil gerade der Nameservice sehr empfindlich auf Fehler in der Konfiguration reagiert und zu netzweiten Störungen führen kann, werden von uns jedem interessierten Sysop geeignete Scripte und Konfigurationshilfen zur Verfügung gestellt, die auch einem technisch weniger erfahrenen Sysop ermöglichen, sein Nameserversystem umzustellen und alles Weitere automatisch aktualisieren zu lassen, vorausgesetzt, der Rest des Serversystems funktioniert soweit einwandfrei. Ist das System einmal richtig installiert und einige wenige Cronjobs aktiviert, hält es sich ohne weiteres Zutun quasi von selbst auf dem laufenden Stand. Dies ist eine große Arbeitserleichterung für jeden betroffenen Sysop.