1. Einführung

Dieses Dokument spezifiziert einen Mechanismus zur Verwaltung zustandsbehafteter DNS-Verbindungen. DNS arbeitet am häufigsten über einen UDP-Transport, kann aber auch über Streaming-Transporte arbeiten; das ursprüngliche DNS-RFC spezifiziert DNS-over-TCP [RFC1035], und ein Profil für DNS-over-TLS [RFC7858] wurde spezifiziert. Diese Transporte können persistente langlebige Sitzungen bieten, und daher ist es bei ihrer Verwendung für den Transport von DNS-Nachrichten von Vorteil, einen Mechanismus zu haben, der Parameter festlegen kann, die mit diesen Sitzungen verbunden sind, wie z. B. Timeouts. In solchen Situationen ist es auch vorteilhaft, serverinitiierte Nachrichten (wie DNS Push Notifications [Push]) zu unterstützen.

Der bestehende Erweiterungsmechanismus für DNS (EDNS(0)) [RFC6891] ist explizit so definiert, dass er nur "Pro-Nachricht"-Semantik hat. Während EDNS(0) verwendet wurde, um mindestens einen sitzungsbezogenen Parameter zu signalisieren (edns-tcp-keepalive EDNS(0) Option [RFC7828]), ist das Ergebnis aufgrund der durch die EDNS(0)-Semantik auferlegten Einschränkungen und des Fehlens serverinitiierter Signalisierung weniger als optimal. Beispielsweise kann ein Server einen Client nicht willkürlich anweisen, eine Verbindung zu schließen, da der Server EDNS(0)-Optionen nur in Antworten auf Abfragen senden kann, die EDNS(0)-Optionen enthielten.

Dieses Dokument definiert einen neuen DNS OPCODE für DNS Zustandsbehaftete Operationen (DSO) mit einem Wert von 6. DSO-Nachrichten werden verwendet, um Operationen innerhalb persistenter zustandsbehafteter Sitzungen zu kommunizieren, ausgedrückt unter Verwendung der Typ-Länge-Wert (TLV)-Syntax. Dieses Dokument definiert einen initialen Satz von drei TLVs, die zur Verwaltung von Sitzungs-Timeouts, Beendigung und Verschlüsselungs-Padding verwendet werden.

Alle drei hier definierten TLVs sind für alle Implementierungen von DSO obligatorisch. Weitere TLVs können in zusätzlichen Spezifikationen definiert werden.

DSO-Nachrichten können bestätigt werden oder auch nicht. Ob eine DSO-Nachricht bestätigt werden soll (eine DSO-Anforderungsnachricht) oder nicht bestätigt werden soll (eine DSO-unidirektionale Nachricht), wird in der Definition dieses bestimmten DSO-Nachrichtentyps festgelegt. Die MESSAGE ID ist für DSO-Anforderungsnachrichten ungleich Null und für DSO-unidirektionale Nachrichten Null. Nachrichten werden in einer Pipeline verarbeitet, und Antworten können in falscher Reihenfolge erscheinen, wenn mehrere Anforderungen gleichzeitig verarbeitet werden.

Das Format für DSO-Nachrichten (Abschnitt 5.4) unterscheidet sich etwas vom traditionellen DNS-Nachrichtenformat, das für Standardabfragen und -antworten verwendet wird. Der Standard-Zwölf-Byte-Header wird verwendet, aber die vier Zählfelder (QDCOUNT, ANCOUNT, NSCOUNT, ARCOUNT) werden auf Null gesetzt, und dementsprechend sind ihre entsprechenden Abschnitte nicht vorhanden.

Die eigentlichen Daten, die sich auf DNS Zustandsbehaftete Operationen beziehen (ausgedrückt in TLV-Syntax), werden an das Ende des DNS-Nachrichtenheaders angehängt. Genau wie bei traditionellem DNS-over-TCP [RFC1035] [RFC7766] rahmt das Stream-Protokoll, das DSO-Nachrichten (die nur eine andere Art von DNS-Nachricht sind) transportiert, diese ein, indem es eine 16-Bit-Nachrichtenlänge an den Anfang setzt. Die Länge der DSO-Nachricht wird daher aus dieser Länge bestimmt und nicht aus einem der DNS-Header-Zähler.

Bei der Anzeige mit Paketanalyse-Tools, die nicht aktualisiert wurden, um das DSO-Format zu erkennen, führt dies dazu, dass die DSO-Daten als unbekannte zusätzliche Daten nach dem Ende der DNS-Nachricht angezeigt werden.

Dieses neue Format hat deutliche Vorteile gegenüber einem RR-basierten Format, da es expliziter und kompakter ist. Jede TLV-Definition ist spezifisch für ihren Anwendungsfall und enthält daher keine redundanten oder überladenen Felder. Wichtig ist, dass es vollständig vermieden wird, DNS Zustandsbehaftete Operationen in irgendeiner Weise mit normalen DNS-Operationen oder mit vorhandener EDNS(0)-basierter Funktionalität zu vermischen. Ein Ziel dieses Ansatzes ist es, die operativen Probleme zu vermeiden, die EDNS(0) befallen haben, insbesondere in Bezug auf das Verhalten von Middleboxen (siehe Abschnitte, die EDNS(0) diskutieren, und Probleme, die durch Firewalls und Load Balancer verursacht werden, in der jüngsten Arbeit, die Ursachen für DNS-Ausfälle beschreibt [Fail]).

Mit EDNS(0) können mehrere Optionen in einen einzigen OPT-Pseudo-RR gepackt werden, und es gibt keinen generalisierten Mechanismus, mit dem ein Client feststellen kann, ob ein Server jede einzelne Option innerhalb des kombinierten OPT-Pseudo-RR verarbeitet oder anderweitig darauf reagiert hat. Die Spezifikationen für jede einzelne Option müssen definieren, wie jede unterschiedliche Option bestätigt werden soll, falls erforderlich.

Im Gegensatz zu EDNS(0) gibt es bei DSO keine zwingende Motivation, mehrere Operationen aus Effizienzgründen in eine einzige Nachricht zu packen, da DSO immer über ein verbindungsorientiertes Transportprotokoll arbeitet. Jede DSO-Operation wird in ihrer eigenen separaten DNS-Nachricht kommuniziert, und das Transportprotokoll kann sich darum kümmern, mehrere DNS-Nachrichten in ein einziges IP-Paket zu packen, falls dies angemessen ist. Beispielsweise kann TCP mehrere kleine DNS-Nachrichten in ein einziges TCP-Segment packen. Diese Vereinfachung ermöglicht eine klarere Semantik. Jede DSO-Anforderungsnachricht kommuniziert nur eine primäre Operation, und der RCODE in der entsprechenden Antwortnachricht zeigt den Erfolg oder Misserfolg dieser Operation an.