Zusammenfassung

  • NAPTR Order und Preference steuern die Auswahl innerhalb der veröffentlichten ENUM-Daten. Sie beweisen weder Uptime noch niedrige Latenz, erfolgreiche Authentisierung, CalDAV-Berechtigung oder Mailzustellung.
  • RFC 5333 hält ical-access für CalDAV-Zugriff und ical-sched für Terminplanung über mailto: und iMIP getrennt. Ein Fallback zwischen beiden ändert die Operation und darf nicht als derselbe Erfolg erscheinen.

Eine korrekte Auswahl kann zu einem ausgefallenen Ziel führen

Aus einer E.164-Nummer wird ein ENUM-DNS-Name. Der Client erhält mehrere NAPTR Records, berücksichtigt Order und Preference, wendet die Ersetzungsregel an und gewinnt eine URI. Bis hierhin kann jede Entscheidung der Spezifikation entsprechen.

Der Zielservice kann dennoch offline sein. Die URI kann veraltet sein, ein Redirect kann ins Leere führen, TLS kann an der Client-Policy scheitern oder der Server kann den Principal abweisen. Kein NAPTR-Feld hat diese spätere Transaktion beobachtet.

Wer Selection und Health in einen Status presst, verliert die Fehlerstelle. „Bevorzugt“ ist eine Konfigurationsaussage. „Erreichbar“ ist eine zeitgebundene Messung. „Autorisiert“ ist eine Anwendungsentscheidung. „Erfolgreich“ braucht den Receipt der konkreten Operation.

Preference ist kein SLA-Gewicht

Das Wort Preference lädt zu einer betriebswirtschaftlichen Lesart ein: höhere Priorität, besserer Dienst. Im NAPTR-Kontext beschreibt es aber, wie Records innerhalb einer Order verarbeitet werden. Es enthält keine gemessene Verfügbarkeit und keinen Vertrag über Antwortzeit.

Ein Dashboard, das daraus Prozentwerte oder Ampeln ableitet, erzeugt Daten. Selbst wenn ein Betreiber die Felder mit einer betrieblichen Absicht pflegt, muss die aktuelle Wirkung separat gemessen werden. DNS-Caches können unterschiedliche Versionen sehen; ein Target kann zwischen Veröffentlichung und Nutzung ausfallen.

Das richtige Receipt nennt RRset, Resolver, Beobachtungszeit, TTL-Kontext, Order, Preference, Flags, Service, Regexp und Ergebnis-URI. Ein Health Receipt beginnt danach mit Auflösung, Verbindung und Anwendungstest.

Zwei Services sind nicht zwei gleichartige Endpunkte

RFC 5333 registriert ical-access:http und ical-access:https für CalDAV-Zugriff auf Kalender- oder Free/Busy-Ressourcen. ical-sched:mailto bezeichnet dagegen ein Ziel für iTIP-Scheduling über iMIP und Internet-Mail.

Ein Failover von HTTPS zu mailto: stellt deshalb nicht denselben Dienst wieder her. Aus Lesen oder Ändern einer Ressource wird Senden einer Nachricht. Die erforderliche Authority, das Fehlerbild und der Erfolgsbeweis ändern sich.

Ein Datenmodell mit nur calendar_endpoint[] begünstigt diesen Fehler. Es sollte Enumservice, Subtype, Scheme und erlaubte Operation erhalten. Eine Policy kann dann entscheiden, ob eine alternative Operation überhaupt zulässig ist, statt sie unter einer unveränderten grünen Anzeige auszuführen.

CalDAV-Zugriff bleibt eine Autorisierungsfrage

Eine ical-access URI zeigt, wo ein Client den Zugriff versuchen kann. Sie erteilt keine Rechte. Der CalDAV-Dienst kann Authentisierung fordern und Methoden pro Principal und Ressource erlauben oder ablehnen.

Ein Nutzer darf möglicherweise Free/Busy sehen, aber keine Titel. Ein anderer darf lesen, jedoch nicht schreiben. Ein dritter erhält unabhängig von der Erreichbarkeit eine Ablehnung. HTTPS schützt bei erfolgreicher Prüfung den Transport und die Serveridentität, ersetzt aber keine ACL.

Monitoring muss deshalb Netzwerk, TLS, Client Identity, Resource, Method, Authorization Result, Response und Commit trennen. Ein HTTP-Status ohne den angefragten Scope ist ebenso wenig ein umfassender Beweis wie die URI selbst.

Mailzustellung bleibt von Teilnahme getrennt

Für ical-sched wird ein Scheduling Object über Mail transportiert. Ein ausgehender Server kann die Nachricht annehmen; ein empfangender Server kann sie zustellen; ein Kalenderclient kann sie interpretieren. Der Teilnehmer kann trotzdem ablehnen oder schweigen.

Auch die Identität ist nicht automatisch. Mailboxen können geteilt, weitergeleitet oder von Assistenzsystemen verwaltet werden. Eine Telefonnummer kann neu vergeben werden. Ein Mapping zu mailto: beweist daher nicht, welche Person die Nachricht gesehen hat.

Ein belastbarer Ablauf speichert iTIP Object, Message ID, Transport Handoffs, Delivery Status, Kalenderverarbeitung und Participant Response. „Gesendet“ darf nicht in „bestätigt“ umbenannt werden, nur weil ein Produkt einen einzigen Status erwartet.

DNSSEC sichert die Auswahlgrundlage, nicht den Zielzustand

Manipulierte DNS-Antworten können Clients zu falschen URIs lenken. DNSSEC ermöglicht dem Validator, die DNS-Daten unter der passenden Trust Chain zu authentisieren. Damit wird die Auswahlgrundlage belastbarer.

Die Signatur misst den Target-Service nicht. Ein sicher validierter Record kann auf einen abgeschalteten Server zeigen. Er kann zu einer gültigen Ressource führen, deren ACL den Client ablehnt. Er kann eine Mailbox bezeichnen, deren Nutzer nicht reagiert.

Der DNSSEC-Status gehört deshalb zum RRset und trägt Resolver, Zeitpunkt und Validierungskontext. Ihn in trusted_calendar umzubenennen, überschreitet seine Aussage. Präzise Grenzen stärken das Sicherheitsmerkmal, weil Fehler nicht fälschlich seiner Schicht zugerechnet werden.

Öffentliche Discovery erzeugt einen eigenen Privacy Surface

RFC 5333 geht davon aus, dass ENUM-DNS-Daten allen Anfragenden zur Verfügung stehen. Eine URI kann Namen oder Arbeitgeber offenbaren. Diese Beziehung wird sichtbar, bevor CalDAV eine Authentisierung verlangt.

Eine opake URI reduziert die direkte Lesbarkeit. Sie garantiert weder Unlinkability noch Aktualität. Stable Tokens, Query Timing, Domain, Redirects, TLS-Namen, Logs und spätere Anmeldung können korrelieren. Nach Rufnummernwechsel oder Organisationswechsel kann ein alter Mapping weiterbestehen.

Der Lifecycle braucht daher Minimierung, Rotation, Revocation und Ownership Review. Ein Security Test, der nur unautorisierte Kalenderinhalte prüft, übersieht die Informationen, die bereits in der Discovery-Schicht liegen.

Registration ist Semantik, nicht Deployment

Das IANA-Register definiert die interoperable Bedeutung von ical-access und ical-sched sowie deren URI Schemes. Es ist die richtige Authority für das Vokabular.

Es zählt keine aktiven Nummern, Server, Implementierungen oder Nutzer. Ein registrierter Enumservice kann ungenutzt sein. Ein publizierter Record kann stale sein. Ein erreichbarer Dienst kann eine Operation ablehnen. Jede Stufe braucht eine eigene Population und Beobachtungszeit.

Die Trennung verhindert eine häufige Kennzahlenverwechslung. Registry Coverage misst definierte Begriffe. DNS Observation misst veröffentlichte Mappings. Probes messen zeitgebundene Reachability. Transactions messen Berechtigung und Wirkung. Keine Zahl darf den Namen der nächsten übernehmen.

Ein Evidence Graph statt einer Verfügbarkeitsampel

Der Graph beginnt mit Input Number, Normalization, Query Name, Resolver, RRset, DNSSEC und Zeit. Der Selection Node enthält Order, Preference, Flags, Service, Regexp und URI.

Danach verzweigt er. ical-access führt zu Redirect, TLS Identity, Principal, Resource, Method, Authorization, Response und Commit. ical-sched führt zu Scheduling Object, Message Handoffs, Client Processing und Participant Response.

Jede Edge nennt Quelle und Zeit. Unknown bleibt Unknown. So kann ein Incident Review feststellen, dass DNS korrekt und der Service offline war, oder dass der Service lebte und die Ablehnung policykonform war. Eine Ampel kann diese Unterschiede nicht erklären.

Keine Quelle beweist einen aktuellen Ausfall

Die untersuchten Quellen definieren Standards, Registrierungen und Risiken. Sie belegen keinen gegenwärtigen Kalenderausfall, keine unautorisierte Einsicht, keine gefälschte Einladung und keinen Providerfehler. Dieser Artikel behauptet nichts davon.

Die Mechanik rechtfertigt trotzdem Vorsorge: Selection und Health trennen, Enumservice Types erhalten, öffentliche Identifikatoren minimieren und Receipts sammeln. Ein Architekturentscheid braucht kein erfundenes Opfer.

Quellen