Zusammenfassung

  • RFC 3403 speicherte DDDS-Regeln in NAPTR, doch ihre physische Position in der DNS-Antwort war keine Ausführungsfolge. Clients sortierten nach ORDER und nutzten PREFERENCE nur in derselben Schicht.
  • Nach einem Treffer durfte kein anderes ORDER wegen eines bekannten Dienstes gewählt werden. Additional-Daten, DNSSEC und Diensterfolg blieben getrennte Belege.

DNS-Ausgaben sehen wie Listen aus. Der erste Datensatz scheint Vorrang zu haben. RFC 3403 erklärte diese Darstellung für nicht normativ: NAPTR lieferte eine Kandidatenmenge, deren Regelreihenfolge in den Feldern lag.

Das Standards-Track-Dokument vom Oktober 2002 definierte DNS als DDDS-Regeldatenbank. Schlüssel waren gültige Domainnamen; Clients fragten NAPTR vom Typ 35 ab. Es ersetzte RFC 2915 und RFC 2168 als offizielle Spezifikation.

ORDER stellte die Delegationsfolge her, niedrige Werte zuerst. Datensätze mit gleichem ORDER galten autoritativ als dieselbe Regel. Nach einem Treffer durfte der Client kein anderes ORDER prüfen, abgesehen von der ausdrücklich beschriebenen komplexen Dienstauswahl.

Server, Cache oder Bibliothek konnten das RRset umordnen, ohne seine Bedeutung zu ändern. Wer den ersten bekannten Services-Wert nahm, ersetzte veröffentlichte Autorität durch Zufall der Darstellung.

PREFERENCE ordnete nur Alternativen mit gleichem ORDER. Als DDDS Priority erlaubte es bei mangelnder Protokollunterstützung eine weniger bevorzugte Option. Es öffnete keine Tür zur nächsten Autoritätsschicht.

Lastverteilung war ebenfalls ausgeschlossen. Das Feld vermittelte Qualität unter gleichwertigen Regeln. Für Verkehrsteilung gab es SRV oder mehrere A-Datensätze. Gewichtung aus PREFERENCE abzuleiten erfand neue Semantik.

Flags und Services wurden von der Anwendung definiert, einschließlich terminaler Flags. Ein Client, der Zeichen erkannte, hatte damit nicht den Anwendungskontext bewiesen.

REGEXP und REPLACEMENT waren ausschließende Formen der Substitution. REGEXP arbeitete auf der ursprünglichen Zeichenfolge; REPLACEMENT war ein vollständig qualifizierter Domainname ohne Kompression. Beide zusammen machten den Datensatz fehlerhaft.

Zwischen Zonendatei und Antwort lag Escape-Verarbeitung. Ein Backslash musste oft doppelt eingegeben werden, um einmal beim Client anzukommen. Der Nachweis brauchte daher administrierte und empfangene Form.

Textfelder waren UTF-8. Außerhalb ASCII musste auf Codepunkten statt Bytes gearbeitet werden. POSIX-Locale-Abhängigkeit war verboten, damit Regeln nicht je Client anders bedeuteten.

Mehrere DDDS-Anwendungen konnten kollidieren. Trennung erfolgte durch eigene Zonen, anwendungsspezifisch verankerte Ausdrücke oder unterscheidbare Flags und Services. Gemeinsamer Name bedeutete keinen gemeinsamen Vertrag.

Additional war nur Optimierung. Server durften relevante A- oder SRV-RRsets gleicher Authentizität beilegen; Anwendungen mussten aber ohne sie funktionieren. Fehlen verlangte eine weitere Abfrage, nicht die Ablehnung von NAPTR.

TTL sicherte zeitliche Kohärenz. Lief auch nur eine verwendete Regel ab, musste der Algorithmus neu beginnen. Eine alte erste und neue zweite Hälfte bildeten womöglich einen nie gleichzeitig existierenden Pfad.

Scheiterte eine Abfrage nach Umschreibung, sollte der Client den Fehler melden statt zu anderen Pfaden zurückzugehen. Opportunistisches Backtracking verwandelte geordnete Delegation in Suche und verbarg die Fehlerstelle.

DNSSEC konnte NAPTR authentisieren, bewies aber weder Ausdruckssicherheit, Sortierung, Anwendungspassung noch Diensterfolg. Der RFC warnte deshalb separat vor ungeprüfter Übergabe an codeausführende Umgebungen.

IANA führt NAPTR als DNS-Typ 35, einen Koordinationsbeleg. Erratum 2868, Held for Document Update, entfernt nur das doppelte this this in Services und ändert keine Verarbeitung.

Der Betriebsbeleg umfasst Schlüssel, RRset, DNSSEC, TTL, empfangene Folge, ORDER-Gruppen, PREFERENCE, Flags, Services, Substitutionsgültigkeit, UTF-8, Zone-zu-Netz-Ausdruck, Ablehnungen, Auswahl, genutzte Additional-Daten, nächste Abfrage und Verbraucherergebnis.

Lu Hengs minimale Anfangsspezifikation erklärt die Aufteilung: gemeinsame Darstellung standardisieren, Bedeutung den Anwendungen lassen. Vorrang des laufenden Codes prüft sie durch gemischte RRsets, fehlendes Additional, geänderte Locale und Ablauf. Autoritätsfelder müssen gewinnen.

Der erste NAPTR im Paket war nur der zuerst sichtbare. Die erste Regel bestimmte ORDER.

Quellen