Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen der Seite angezeigt.
Beide Seiten, vorherige Überarbeitung Vorherige Überarbeitung Nächste Überarbeitung | Vorherige Überarbeitung | ||
ip-koordination:autoupdate [15.08.2015 15:39 Uhr] – ↷ Seite von dokumentation:ip-koordination:autoupdate nach ip-koordination:autoupdate verschoben dd9qp | ip-koordination:autoupdate [02.12.2020 11:06 Uhr] (aktuell) – gelöscht 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, | ||
- | |||
- | Dies ist für Zonen interessant, | ||
- | |||
- | ==== Autoupdate auf ucsd.edu ==== | ||
- | |||
- | Durch das neue DNS-Konzept wird weitgehend sichergestellt, | ||
- | |||
- | 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, | ||
- | |||
- | 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, | ||
- | |||
- | 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, | ||
- | |||
- | 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, |