Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen der Seite angezeigt.

--- ip-koordination:results [15.08.2015 13:39 Uhr] – ↷ Seite von dokumentation:ip-koordination:results nach ip-koordination:results verschoben dd9qp
+++ ip-koordination:results [02.12.2020 10:09 Uhr] (aktuell) – gelöscht dd9qp
@@ Zeile 1: / Zeile 1: @@
-===== Praxis =====
-==== Stand der Realisierung auf Hub-Ebene ====
-Alle 5 Hubs (Nord, Süd, West, Ost, Mitte((Der Hub-Mitte DB0SMG ist seit einiger Zeit nicht in Betrieb. Seine Funktionen werden von den anderen Hubs aufgefangen)) ) werden unter den neuen Konfigurationen betrieben. Hub Ost läuft zusätzlich aber noch in "alter" Konfiguration weiter: Damit können wir weiterhin Daten aus Regionen erhalten, die noch nicht für den ihnen zugeordneten Hub konfiguriert sind.
-==== Stand der Realisierung auf Regionalebene ====
-Derzeit sind relativ mehr Zonen im Regionalzonenkonzept aktiv als solche, die zentral verwaltet werden (müssen).
-(ToDo)
-==== Beliebte Fehler im Zonefile ====
-Viel Zeit hat es gekostet, die Zonen des zum Teil jahrelang nicht mehr gepflegten DL-DNS-Projektes wieder zu aktualisieren:
-Viele Zonen waren/sind veraltet ("expired"), weil
-  * schlicht das IP-Routing nicht funktionierte, Antworten auf dem Rückweg versackten oder auch nur der AX25-Arp zum Ziel nicht bekannt war.
-  * der Nameserver nicht gestartet war.
-  * das Zonefile auf Grund eines Fehlers nicht geladen wurde.
-  * der Rechner irgendwann neu aufgesetzt wurde.
-  * in der Region seit mehr als zehn Jahren nichts mehr am DNS gemacht wurde und dieser in Vergessenheit geriet (z.B. weil der Koordinator wegzog oder das Hobby aufgab und der neue (sofern überhaupt ein neuer ernannt wurde) vom DNS Projekt nichts wusste oder ihm niemand half es zu bedienen). So wurden die Daten auf anderem Wege aktualisiert (oder warten noch heute auf verstaubten Zetteln in irgendwelchen Schubladen auf ihre archäologische Entdeckung ;)
-  * der Digi längst qrt gemacht hat.
-Kreisende "Refresh's" von eigentlich expire'ten Zonen (weil "jeder von jedem" Zonen per AXFR wieder belebte) stellten ein zusätzliches Problem dar. Viele Probleme konnten durch Einführung des Hub-Konzeptes deutlich reduziert werden.
-Da oftmals die letzten Veröffentlichungen der "Hosts-Liste" in den BBS schon Jahre zurücklagen, standen wir bei verwaisten Regionen manches Mal vor der Frage, was aktueller war: die Einträge auf ucsd.edu (dort gibt es keine Zeitstempel) oder die Serien-Nummer des SOA Headers einer Region.
-Deshalb halten wir es für hilfreich, die Serien-Nummer in Form eines Datums zu codieren:
-  * Unix-Zeit: <code>
-$ perl -e '{printf("%lu\n", time());}'
-1079986731</code>[Trick: Welche Zeit war das noch gleich?<code>
-perl -e '{use Time::localtime; printf("%s\n", ctime(1079986731));}' ]</code>
-  * Händisch: 2004032200 JahrMMTTxx [MM=Monat, TT=Tag, xx= beliebige zweistellige Zahl]\\ Anmerkung: schreibt man z.B. mal (am 22.3.2004 12 mal geändert) 2004032212 und am nächsten Tag 200403231 Dann ist diese Zahl (Serial) kleiner als die zuvor. Die Folge ist, dass der Zonetransfer künftig scheitern wird. Die anderen Nameserver werden die Zone nicht laden. Der "Refresh" scheitert, und nach Erreichen des "Expire" Wertes (im SOA Header des bisher gültigen Zonefiles) werden die anderen Nameserver keine Antwort mehr geben. Sie werden jedoch auch dann die kleinere Serial nicht akzeptieren! Die Zonenedaten sind dann in allen DNS nicht mehr verfügbar.
-  * Wechsel von 2004032200 nach Unix-Zeit-Format (ähnlich des Problems oben): Ein RFC beschreibt, wie es geht. Problem: es klappt nur nicht.
-    *  Händische Intervention auf allen Nameservern notwendig.
-    * Kaum praktikabel. -> Besser so lassen wie es ist.
-Weitere Beispiele: Flüchtigkeitsfehler in Zonefiles. Zumeist wurde der Punkt am Ende der Zeile vergessen.
-<code>
-goe.rev:19 PTR wampes.dl1abc.goe.de.ampr.org
-goe.rev:78 PTR do9ose.goe.de.mapr.org.
-goe.rev:82 PTR dl8oai.goe.de.mapr.org.
-goe.rev:83 PTR dl1odr.goe.de.mapr.org.
-rmn24.rev:226 PTR db0fhd.dk0bp.rmn.de.a.mpr.org.
-os.rev:57 5184000 IN PTR dh1bm.
-os.rev:99 5184000 IN PTR dyn4.db0sm.8.130.44.in-addr.arpa.
-baden.rev:61 604800 IN PTR dh6iaz.baden.de.ampr.org.50.130.44.in-addr.arpa.
-rmn.zone: 86400 IN MX 10 dl5zr.rmn.de.ampr.org.rmn.de.ampr.org.
-rmn.zone: 86400 IN MX 20 db0ais.rmn.de.ampr.org.rmn.de.ampr.org.
-wat.rev:148 86400 IN SOA wat.de.ampr.org.148.130.44.in-addr.arpa.
-</code>
-Eine weitere Inkonsistenz: Der PTR zeigt direkt auf ampr.org,
-<code>
-$ host dl3dbt
-dl3dbt.ampr.org is an alias for dl3dbt.si.de.ampr.org.
-dl3dbt.si.de.ampr.org has address 44.130.35.1
-$ host 44.130.35.1
-.35.130.44.in-addr.arpa domain name pointer dl3dbt.ampr.org.
-</code>
-während ansonsten das Rückwärtsauflösen <region>.de.ampr.org anzeigt:
-<code>
-$ host db0bln.ampr.org
-db0bln.ampr.org is an alias for db0bln.bln.de.ampr.org.
-db0bln.bln.de.ampr.org has address 44.130.36.200
-$ host 44.130.36.200
-.36.130.44.in-addr.arpa domain name pointer db0bln.bln.de.ampr.org.
-</code>