Zusammenfassung

  • ENUM bildet aus einer E.164-Nummer einen DNS-Schlüssel und verarbeitet NAPTR-Regeln bis zu einem URI; das Ergebnis ist ein möglicher Dienstkontakt, keine abgeschlossene Verbindung.
  • Ein belastbarer Anrufnachweis hält Nummernvalidierung, DNSSEC-Status, ausgewählte NAPTR-Regel, erzeugten URI, Peer-Authentisierung, Signalisierung und beobachtete Medien getrennt.

Ein Betriebssystem nimmt eine E.164-Nummer entgegen und meldet Erfolg. Satzzeichen verschwinden, die Ziffern werden für einen Namen unter e164.arpa umgedreht, ein NAPTR-RRSet besteht DNSSEC, und der Client erzeugt einen SIP-URI. Danach kann eine weitere Auflösung zu einem alten Server führen. Der Anbieter kann die Einladung ablehnen. Das Endgerät kann stumm bleiben. Selbst angenommene Signalisierung kann nur einseitigen Ton hervorbringen.

Die ENUM-Antwort muss deshalb nicht falsch sein. Falsch ist die Anzeige, die „aufgelöst“ in „verbunden“ umbenennt und alle Übergaben nach dem URI verschweigt.

Patrik Fältström und Michael Mealling verfassten gemeinsam RFC 3761, der 2004 auf dem Standards Track erschien. 2011 ersetzte ihn RFC 6116 von Scott Bradner, Lawrence Conroy und Kazunori Fujiwara. Das neuere Dokument bezeichnet sich als Aktualisierung des von Fältström und Mealling edierten Textes. ENUM ist kollektive, revidierte Standardisierung und weder Eigentum noch laufende Betriebsentscheidung einer Person.

Die Zusage der Architektur ist präzise: Eine Anwendung kann mit einer Telefonnummer beginnen und über DNS einen URI entdecken. DNS wird dadurch nicht zur Telefonvermittlung, Nummernbehörde oder Zeugin eines Gesprächs.

Ein korrekter Schlüssel weist keinen aktuellen Inhaber nach

RFC 6116 bildet zunächst den Application Unique String. Aus der vollständigen E.164-Nummer werden Leerzeichen, Klammern und Bindestriche entfernt; das führende Plus bleibt. Die First Well Known Rule entfernt anschließend das Plus, kehrt die Ziffern um, trennt sie durch Punkte und hängt .e164.arpa. an. Damit entsteht der erste Schlüssel der ENUM-Regeldatenbank.

Die korrekte Umwandlung beweist nur, dass der Client richtig fragt. Sie authentisiert weder den Anfragenden noch den heutigen Nutzungsberechtigten. Portierung, verspätete Revalidierung oder eine unbefugte Eingabequelle liegen außerhalb dieser Syntax.

Der Schlüssel fragt NAPTR-Datensätze ab. Eine terminale Regel kann das Endergebnis liefern; eine nichtterminale Regel erzeugt einen weiteren Domainnamen und eine weitere Abfrage. Erwartete Ausgabe der letzten DDDS-Runde ist ein absoluter URI. ENUM endet bei einer Adressdarstellung, nicht bei einem Anrufzustand.

RFC 3403 zerlegt die Regel. ORDER bestimmt die Hauptreihenfolge, PREFERENCE ordnet geeignete Kandidaten derselben Stufe, FLAGS, SERVICES, REGEXP und REPLACEMENT steuern Deutung und Umschreibung. Wer nur den URI speichert, löscht die Begründung seiner Auswahl.

Eine einzelne Rückgaberegel lässt Entscheidungen offen

Der Satz, der ENUM-Algorithmus liefere stets eine Regel, beschreibt dessen Ausgang. Er ist kein Vollzugsbeleg für Telefonie. Eine Anwendung kann nur einige Enumservices unterstützen, private oder fehlerhafte Datensätze verwerfen, mehrere URLs anzeigen oder anwendungsspezifisches Wissen einsetzen.

Clients sortieren ein RRSet nach ORDER und PREFERENCE. Bei gleichen Werten ist die Lieferreihenfolge im DNS-Paket keine dauerhafte Präferenz. Zwei Resolver können denselben Satz verschieden anordnen, ohne dass Daten manipuliert wurden.

Auch die Präferenz des Registranten ist kein Befehl. RFC 6116 rät, nur Kontakte einzutragen, die er unterstützen will, weil selbst der ungünstigste Kandidat von einem Endnutzer gewählt werden kann. Das verspricht weder aktuelle Erreichbarkeit noch Schema-Unterstützung oder Zulassung beim nächsten Provider.

Eine brauchbare Spur bewahrt das gesamte RRSet, TTL, Reihenfolge, Präferenz, Dienst, Flags, Umschreibung und Clientfähigkeiten. Für jeden Kandidaten steht fest, warum er angenommen, übersprungen oder verworfen wurde. Ohne diesen Nenner lässt sich aus dem End-URI weder richtige Policy noch Gleichstand, alter Cache oder fehlende Alternative ablesen.

Das Recht an der Nummer wird vorgelagert geprüft

ENUM-Domains hängen an E.164-Zuteilungen. RFC 4725 unterscheidet Nummernzuteiler, den nutzungsberechtigten Assignee, ENUM-Registrant, Validierungsstelle, Registry, Registrar, DNS-Dienst und Anwendungsanbieter.

Die Validierungsstelle prüft, ob der Registrant der Assignee ist oder für ihn handeln darf. Eine Erstprüfung reicht nicht für die gesamte Delegationsdauer. Änderungen von Zuteilung oder Recht verlangen Revalidierung; entfallene Voraussetzungen verlangen Widerruf.

Diese Provenienz steckt nicht automatisch in jeder NAPTR-Antwort. Ein Resolver kann veröffentlichte Daten authentisieren, ohne die jüngste Portierung, Validierungsmethode oder lokale Genehmigung zu kennen. „Der Name existiert“ und „der Registrant kontrolliert die Nummer jetzt“ sind getrennte Behauptungen.

Ein veralteter Datensatz beweist umgekehrt keinen Betrug. Eine laufende TTL, ungleichzeitige Zonenupdates oder verzögerter Widerruf können den Zustand erklären. Die Untersuchung verbindet Zuteilungsversion, Prüfzeit und -methode, Ablauf, Delegationsänderung und die tatsächlich empfangene Antwort.

DNSSEC authentisiert nicht den späteren Dienst

RFC 6116 empfiehlt DNSSEC, um DNS-Daten zu authentisieren und Angriffe zu mindern. Er sagt ebenso deutlich: Eine über eine validierte ENUM-Abfrage erhaltene Adresse garantiert nicht, dass die dort erreichte Entität der beabsichtigte Dienstpeer ist.

Der Dienst muss den Peer in seiner eigenen Aufbauphase authentisieren. Außerhalb des Dienstes entdeckte Adress- oder Identitätsdaten ersetzen diese Prüfung nicht. DNSSEC beantwortet die Herkunft innerhalb einer signierten DNS-Kette, nicht die Identität der später antwortenden Software.

Caching verlängert die Kette. Im SIP-Beispiel löst der ENUM-URI weitere NAPTR-, anschließend SRV- und Adressabfragen aus, bevor der User Agent überhaupt eine Sitzung versucht. Zonen und TTLs ändern sich in verschiedenen Takten. Einzelne authentische Datensätze können zusammen einen vorübergehend inkonsistenten Weg ergeben.

Zu speichern sind daher DNSSEC-Ergebnis, Signaturgültigkeit, Resolver, Cachealter, negative Antworten und jede Folgeauflösung. Danach wird der Signalisierungsversuch mit dem tatsächlich authentisierten Peer verbunden.

Der Sprach-URI startet erst das nächste Verfahren

RFC 4415 registrierte den Enumservice voice:tel. Ein erzeugter tel:-URI kann zum Einleiten eines interaktiven Sprachanrufs verwendet werden. Ein Dialer nutzt die Nummer über PSTN oder PLMN, direkt oder über IP-Anbieter und Gateway.

„Einleiten“ markiert die Grenze. Der Client muss Typ und Untertyp beherrschen. Ein Anbieter kann authentisieren, autorisieren, weiterleiten, annehmen oder ablehnen. Das entfernte Gerät kann klingeln, umleiten, auslaufen oder antworten. Medien müssen danach gesondert ausgehandelt und übertragen werden.

Bei einem SIP-URI übernimmt RFC 3261. SIP ist ein eigenes Protokoll zum Auffinden möglicher Teilnehmer und zum Erzeugen, Ändern und Beenden von Sitzungen. Es hat Authentisierung, Autorisierung, Einladungen, vorläufige und endgültige Antworten, Bestätigungen und Dialogzustände. ENUM liefert einen Eingabe-URI; es führt diese Zustandsmaschine nicht vorab aus.

Selbst angenommene Signalisierung beweist kein Gespräch. Beidseitiges Audio, menschliche Teilnahme, Nutzungsdauer und korrekte Abrechnung brauchen Medien- und Anwendungsbelege unter angemessenen Datenschutzgrenzen.

Der Nachweis wird in Reihenfolge gebaut

Der erste Teil umfasst Originalnummer, Normalisierung, DNS-Schlüssel, Resolver, Zeit, DNSSEC, RRSet, TTLs und nichtterminale Umschreibungen. Es folgen unterstützte Enumservices, Kandidaten, Auswahlgrund und End-URI.

Der zweite Teil beginnt außerhalb von ENUM: Folgeauflösung, authentisierter Peer, Provider-Autorisierung, Signalisierungsanfrage, Transaktionskennung, Antworten, Bestätigung und Abschlussgrund. Erst danach kann die Beobachtung beidseitiger Medien und des nutzbaren Zeitfensters folgen.

Eine Stufe kann erfolgreich sein, bevor die nächste scheitert. So lassen sich abgelaufene Delegation und alter Cache, inkompatibler Dienst und unerreichbarer Host, falscher Peer und abgewiesener Anrufer sowie angenommene Signalisierung und Einwegaudio auseinanderhalten.

Quellen