Zusammenfassung

  • Jaco Kroon veröffentlichte am 22. Oktober Fehlermeldungen, die beim Löschen eines übergeordneten inetnum-Objekts vier domain-Objekte und ein route-Objekt als Hindernis nennen.
  • AFRINIC verlangt für eine Reverse-DNS-Delegation eine registrierte Zuweisung oder Unterzuteilung. Laut Kroon kann die Korrektur dieser Registrierung zunächst den Abbau der abhängigen Delegationsobjekte erfordern.

Wer eine veraltete Adresszuweisung korrigieren will, muss nach Kroons Schilderung zuerst die vier zugehörigen Reverse-DNS-Objekte und das Routenobjekt entfernen. Erst dann lässt sich der übergeordnete inetnum-Eintrag löschen und neu ordnen. Aus einer Buchung werden mehrere abhängige Änderungen. Jaco Kroon schilderte im AFRINIC-Policy-Forum, wie die Löschung eines inetnum-Eintrags an vier untergeordneten Reverse-DNS-Domänen und einem Routenobjekt scheitert. Sein Beispiel 10.0.0.0/22 stammt aus privatem Adressraum. Es belegt die von ihm beschriebene Fehlersituation, aber keinen Vorfall in einem benannten öffentlichen Netz.

Das Geflecht hat einen Zweck. Das inetnum-Objekt hält die Adressnutzung fest. Ein domain-Objekt bezeichnet die Reverse-DNS-Zone und ihre Nameserver; das route-Objekt gehört zur Routing-Datenbank. Nach AFRINICs Betriebsanleitung legt das Mitglied die Domain über MyAFRINIC, die WHOIS-Oberfläche oder per E-Mail an. AFRINIC prüft und veröffentlicht die Delegation, während das Mitglied die Zone betreibt. Wer das domain-Objekt entfernt, greift deshalb an einem veröffentlichten Verweis an.

Das aktuelle Policy-Handbuch schreibt in Abschnitt 10.5.2 vor, dass ohne registrierte Zuweisung oder Unterzuteilung keine Reverse-Delegation erfolgt. Für ein /24 genügt eine solche Registrierung; eine vollständige Belegung ist nicht nötig. Zugleich fordert der WHOIS-Leitfaden aktuelle Angaben und erklärt die Löschsperre für referenzierte Objekte. Kroon beschreibt die Reihenfolge so: Zuerst verschwinden die untergeordneten domain-Objekte, dann kann der alte Adresseintrag weg. AFRINICs Anleitung verbindet die domain-Objekte mit der veröffentlichten Reverse-DNS-Delegation und nennt für neue Einträge eine Verzögerung bis zur DNS-Veröffentlichung. Ein missglückter Wiederaufbau kann diese Lücke verlängern; ein konkreter Ausfall ist in seiner Nachricht nicht belegt.

Er regt an, den gesamten Abschnitt 10.5 zu streichen, damit AFRINIC die Datenbankregeln lockern kann. Damit träfe er auch 10.5.1, die Regel zu Delegationsanträgen von Mitgliedern mit gültigem Status. Ein formaler, nummerierter Vorschlag liegt in seiner Nachricht nicht vor. Der technische Beleg, der die Debatte voranbringt, ist eine von AFRINIC dokumentierte Folge von Löschen, Neuanlegen und Veröffentlichung. Sie würde zeigen, ob die Delegation während der Korrektur erhalten bleibt.