Zusammenfassung

  • RFC 5346 berichtet über einen koreanischen Infrastructure-ENUM-Versuch von 2006. Falsch provisionierte Daten wirkten im Netz des rufenden Carriers, doch dieser konnte wegen verteilter Zuständigkeit und Rufnummernportierung den für die Korrektur verantwortlichen Carrier möglicherweise nicht erkennen.
  • Die Versuchsregeln trennten drei Fälle: NOERROR mit nutzbarer URI führte in die ENUM-Verarbeitung; NOERROR ohne nutzbare URI bedeutete bei einer ENUM-only-Nummer sofortigen Abbruch; NXDOMAIN, weitere DNS-Fehler und Timeout führten zur herstellerspezifischen Methode und meist zur PSTN zurück.
  • Verantwortlichkeit lässt sich nicht aus einem 200 OK rekonstruieren. Erforderlich ist ein Belegverbund aus Provisionierungsquelle, Datensatzversion, Portierungszustand, Resolver-Sicht, NAPTR-Entscheidung, Mapping-Quelle, Interconnect-Berechtigung, Fallback und tatsächlich ausgeführter Route.

Die Störung erschien in einem anderen Netz als ihr Ursprung

Ein gemeinsames Verzeichnis verspricht, Routendaten nicht in jedem Netz separat pflegen zu müssen. Der Gewinn hat eine Kehrseite: Ein Fehler, der bei einer Stelle eingetragen wird, materialisiert sich beim Absender eines Anrufs. Dort sieht der Operator eine falsche URI, einen nicht erreichbaren Domainpart oder ein unerwartetes Ziel. Er besitzt aber nicht notwendigerweise die Berechtigung, den Quelldatensatz zu reparieren.

RFC 5346 benennt dieses Problem ausdrücklich. Der rufende Carrier kann Schwierigkeiten durch fehlerhaft provisionierte ENUM-Daten erfahren, ohne zu wissen, welcher Carrier für die Nummer verantwortlich ist. Rufnummernportierung durchbricht die einfache Annahme, eine Vorwahl oder ein alter Nummernblock verrate den aktuellen Betreiber.

Technische Korrektheit der einzelnen Komponenten löst die Zuordnung nicht. DNS kann treu den vorhandenen Inhalt liefern. Der Softswitch kann die unterstützte NAPTR regelgerecht auswählen. Das Ziel kann dennoch falsch oder unerreichbar sein. Aus diesem Ablauf folgt weder, wer den Fehler verursacht hat, noch wer ihn jetzt beheben darf.

Eine Incident-ID ohne Reparaturinhaber ist deshalb unvollständig. Sie muss Datensatzversion, Provisionierungskanal, behaupteten Serving Carrier, Portierungsbeleg, Resolver-View, Entscheidungspfad und einen autorisierten Kontakt verbinden. Sonst verteilt das gemeinsame Verzeichnis den Schaden effizienter als die Verantwortung.

Der DNS-Code brauchte eine Nummernpolitik

Der Versuch führte einen ENUM-only-Nummernbereich. Eine aktive Nummer besaß eine nutzbare SIP- oder H.323-URI, aber keinen PSTN Point of Interconnect. Eine außer Betrieb genommene Nummer konnte weiterhin als ENUM-Name existieren, ohne eine für den Ruf nutzbare URI anzubieten.

Darum war RCODE=0 kein Synonym für „Anruf fortsetzen“. NOERROR mit einer verwendbaren URI öffnete den nächsten ENUM-Schritt. NOERROR ohne verwendbare URI führte bei der exklusiven Nummer zum sofortigen Fehlschlag. Ein PSTN-Fallback hätte dort keinen legitimen Anschluss gefunden und konnte Fehlversuche oder Schleifen erzeugen.

Bei NXDOMAIN, Formatfehler, Serverfehler, nicht implementierter Operation, Verweigerung oder ausbleibender Antwort wechselte der Softswitch dagegen zur herstellerspezifischen Methode. Für die große Menge gewöhnlicher Nummern war das plausibel: Nicht im neuen Verzeichnis zu stehen bedeutete nicht, außerhalb des Telefondienstes zu stehen.

Die gleiche äußerliche Kategorie „keine nutzbare ENUM-Route“ enthielt somit zwei gegensätzliche Handlungen. Die eine musste den Ruf stoppen, die andere durfte ihn in das Altsystem übergeben. Nur die Verbindung von DNS-Zustand, unterstütztem Service und Bereichspolitik konnte sie unterscheiden.

Fallback übergab nicht nur Verkehr, sondern Zuständigkeit

Vor dem Fallback hing die Entscheidung an e164.arpa, dem Resolver, der NAPTR-Menge, dem unterstützten enumservice und der URI. Danach bestimmten Präfixtabelle, Herstellerlogik und PSTN-Regime den nächsten Schritt. Die E.164-Eingabe blieb gleich, die Autorität wechselte.

Ein erfolgreich beendeter Anruf konnte daher zwei unvereinbare Geschichten besitzen. In der ersten wählte ENUM eine URI, deren Domain zu einem IP-Interconnect führte. In der zweiten scheiterte die Anfrage, und das alte Routing brachte den Ruf über PSTN ans Ziel. Ein SIP 200 OK unterschied die Geschichten nicht.

Das macht Fallback organisatorisch attraktiv und analytisch gefährlich. Der Betrieb schützt die Erreichbarkeit. Das Migrationsprogramm kann weiter ausrollen, obwohl das neue Verzeichnis noch dünn oder instabil ist. Gleichzeitig verdeckt das erfolgreiche Altsystem genau jene Lücken, die vor seiner Abschaltung sichtbar werden müssten.

„ENUM wurde versucht“ ist ebenfalls kein hinreichender Nachweis. Der Versuch kann vor der NAPTR-Auswahl, bei der URI-Verarbeitung oder bei der Domain-Auflösung enden. Entscheidend ist, welche Autorität tatsächlich den ausgeführten Gateway auswählte.

Die private Tabelle war ein technischer und vertraglicher Datensatz

Auch eine gültige URI war noch keine fertige Route. RFC 5346 beschreibt zwei Wege, ihren Domainpart abzubilden: rekursives DNS mit SIP-Lokalisierung oder eine feste private Tabelle im Softswitch. Diese Tabelle verband Domains mit vereinbarten Gateways.

Fehlte der Domainname in der Tabelle, konnte der Ruf in die PSTN zurückfallen. Schlug die rekursive Auflösung fehl oder ergab keine brauchbaren Records, galt dasselbe. Die NAPTR hatte also die erste Schwelle passiert, nicht die letzte.

Die feste Tabelle verdoppelte Pflege. ENUM-Daten und lokales Domain-Gateway-Mapping mussten konsistent bleiben. Der Bericht bewertet das nicht als vernünftige Dauerarchitektur; es war ein temporäres Mittel, weil der Versuch wenige Einträge hatte und der bestehende kommerzielle Dienst nicht gefährdet werden durfte. Die Softswitches konnten rasch zwischen festem Mapping und DNS wechseln.

Gleichzeitig verkörperte die Tabelle bilaterale Interconnection. Carrier erwarteten Entgelte und konnten sich auf ein bestimmtes, nicht öffentlich erreichbares Gateway einigen. Dass ein Domainname öffentlich zu einer Adresse aufgelöst wurde, bewies nicht, dass der rufende Carrier diese Verbindung benutzen durfte.

Damit hatte die Tabelle eine doppelte Natur: Routendatum und Schatten eines Vertrags. Ein veralteter Eintrag konnte nach einer Vertrags- oder DNS-Änderung weiter wirken. Eine ungeprüfte öffentliche Auflösung konnte umgekehrt die vereinbarte Zugangskontrolle umgehen. Der Reparaturinhaber des ENUM-Records war nicht automatisch der Inhaber dieses zweiten Datensatzes.

Timeout war ein Eigentümerwechsel im Entscheidungspfad

Eine ausbleibende Antwort wurde schließlich zum DNS-Fehler und löste Fallback aus. Für den Teilnehmer war das eventuell nur ein etwas langsamerer erfolgreicher Verbindungsaufbau. Für die Steuerung war der Timeout der Moment, in dem ENUM die Route nicht mehr bestimmte.

Der Versuch verkürzte die DNS-Timeouts nicht einfach auf einen nicht konformen Wert. Die Resolver-Bibliothek des Softswitches diente weiteren Funktionen; eine Änderung hätte unbekannte Seiteneffekte auf andere DNS-Nutzung gehabt. Der vermeintlich lokale Parameter gehörte einer gemeinsamen Laufzeitabhängigkeit.

Ein belastbarer Trace muss daher Anfragebeginn, Antwort oder Fristablauf, Fallback-Entscheidung, Auswahl der Altroute und endgültige SIP-Antwort getrennt führen. Eine einzige Call-Setup-Dauer kann diese Kausalität nicht ersetzen.

Das für eine spätere Dokumentaktualisierung gehaltene Erratum korrigiert in Abschnitt 4.1.1 vier Verweise von „rule 2“ auf „rule 3“. Ein weiteres berichtigt „non-complaint“ zu „non-compliant“. Die Route ändert sich dadurch nicht; wohl aber zeigt es, dass Runbooks Textversion und Errata als Teil ihrer Herkunft speichern sollten.

Die Mittelwerte belegten nur eine schmale Beobachtung

Der Versuch maß die durchschnittliche Zeit von SIP INVITE bis 200 OK. Die sechs ENUM-/Nicht-ENUM-Paare lagen weniger als eine Sekunde auseinander: 2,33 zu 2,28 Sekunden für A zu A; 2,23 zu 2,25 für A zu B; 4,11 zu 3,79 für A zu einem weiteren PSTN-Ziel; sowie 2,18 zu 2,05, 2,19 zu 2,19 und 3,95 zu 3,41 für die von B ausgehenden Kombinationen.

Das stützt die begrenzte Aussage, dass ein Nutzer im gemessenen Versuch durchschnittlich keinen großen Unterschied wahrgenommen hätte. Der Bericht nennt jedoch keine Stichprobengrößen, Perzentile, Fehlernenner, Cache-Zustände oder per-call Route Provenance.

Der Messpunkt endet bei 200 OK. Medienqualität, Gesprächsabschluss, Abrechnung, aktuelle Nummerninhaberschaft und Berechtigung des Interconnects bleiben außerhalb. Ein schneller PSTN-Fallback und eine schnelle echte ENUM-Route können im selben Mittelwert verschwinden.

Für Zuständigkeit ist das besonders relevant. Wenn die Messung nur den grünen Endzustand aufbewahrt, ist später weder der fehlerhafte Record noch die Instanz, die den Ruf gerettet hat, sicher ermittelbar.

Öffentliche Daten machten die Resolver-Sicht selbst zum Risiko

Die Infrastructure-ENUM-Daten des Versuchs waren über das öffentliche Internet erreichbar. Das schuf eine realistische Resolver-Umgebung und vereinfachte Datenteilung. Carrier bezweifelten jedoch, dass dieser Zugang nötig sei, weil Informationen über Telefonnummern offengelegt werden könnten; teilweise bevorzugten sie privaten Zugriff.

Auch der Resolver war eine Kontrollstelle. RFC 5346 warnt, ein Angreifer mit Kontrolle über ihn könne Anrufe verzögern oder scheitern lassen. Der Zugriff sollte auf das lokale Netz des Softswitches begrenzt und von außen eingeschränkt werden.

Privatheit, Richtigkeit und Nutzungsberechtigung sind verschiedene Eigenschaften. Ein privater Resolver kann falsche Records liefern. Ein öffentlicher Resolver kann einen technisch richtigen Endpoint liefern, dessen Nutzung vertraglich nicht erlaubt ist. Der Incident-Beleg muss deshalb auch Resolver-View und Zugriffsdomäne festhalten.

Der historische Bericht begrenzt seinen eigenen Anspruch

RFC 5346 ist Informational und kein Internet Standard. Er beschreibt einen vor-kommerziellen Versuch von 2006; RFC 6116 löste später RFC 3761 als ENUM-Spezifikation ab. Seine Regeln beweisen weder den gegenwärtigen Betrieb koreanischer Carrier noch eine universelle Zielarchitektur.

Gerade diese Begrenzung macht die Analyse sauber. Wiederverwendbar ist nicht eine konkrete Timeout-Zahl, sondern das Entscheidungsmodell: ein neuer gemeinsamer Namensraum, ein altes Routingsystem, private Absprachen, unterschiedliche Fehlerbedeutungen und eine Reparaturzuständigkeit, die nicht automatisch mit dem Fehler mitwandert.

Eine belastbare Reparaturkette beginnt vor dem Anruf

Der operative Beleg sollte die normalisierte E.164-Nummer und ihre Bereichspolitik aufnehmen. Dazu gehören Query, RCODE, Antwortmenge, unterstützte und verworfene NAPTRs, order, preference, enumservice, URI, TTL und Resolver-View.

Anschließend folgen Mapping-Quelle, Tabellen- oder DNS-Version, ausgewählter Gateway, Interconnect-Bezug und Fallback-Grund. Der Portierungszustand und die Provisionierungsquelle müssen mit einem Ansprechpartner verbunden sein, der tatsächlich ändern darf. Erst danach kommen SIP-Ergebnis, Medienerfolg, Gesprächsabschluss und Abrechnung.

Diese Kette trennt zwei Fragen: Wer hat die ausgeführte Route gewählt? Wer kann die falsche Eingabe reparieren? Ein gutes System beantwortet beide, ohne den einen Eigentümer aus dem anderen zu erraten.