Zum Hauptinhalt springen

4. Specifications (Spezifikationen)

4.1. Connection Establishment (Verbindungsaufbau)​

DoQ-Verbindungen werden wie in der QUIC-Transportspezifikation [RFC9000] beschrieben aufgebaut. Während des Verbindungsaufbaus wird die DoQ-Unterstützung durch Auswahl des Application-Layer Protocol Negotiation (ALPN)-Tokens „doq" im Krypto-Handshake angezeigt.

4.1.1. Port Selection (Portauswahl)​

Standardmäßig muss (MUST) ein DNS-Server, der DoQ unterstützt, QUIC-Verbindungen am dedizierten UDP-Port 853 (Abschnitt 8) abhören und akzeptieren, es sei denn, es gibt eine gegenseitige Vereinbarung zur Verwendung eines anderen Ports.

Standardmäßig muss (MUST) ein DNS-Client, der DoQ mit einem bestimmten Server verwenden möchte, eine QUIC-Verbindung zum UDP-Port 853 auf dem Server aufbauen, es sei denn, es gibt eine gegenseitige Vereinbarung zur Verwendung eines anderen Ports.

DoQ-Verbindungen dürfen (MUST NOT) UDP-Port 53 nicht verwenden. Diese Empfehlung gegen die Verwendung von Port 53 für DoQ soll Verwechslungen zwischen DoQ und der Verwendung von DNS über UDP [RFC1035] vermeiden.

4.2. Stream Mapping and Usage (Stream-Mapping und -Verwendung)​

Das Mapping von DNS-Verkehr über QUIC-Streams nutzt die in Abschnitt 2 von [RFC9000] detailliert beschriebenen QUIC-Stream-Funktionen.

Alle DNS-Nachrichten (Abfragen und Antworten), die über DoQ-Verbindungen gesendet werden, müssen (MUST) als 2-Oktett-Längenfeld gefolgt vom Nachrichteninhalt wie in [RFC1035] spezifiziert codiert werden.

Der Client muss (MUST) für jede nachfolgende Abfrage auf einer QUIC-Verbindung den nächsten verfügbaren vom Client initiierten bidirektionalen Stream auswählen. Der Client muss (MUST) die DNS-Abfrage über den ausgewählten Stream senden und muss (MUST) über den STREAM FIN-Mechanismus anzeigen, dass keine weiteren Daten auf diesem Stream gesendet werden.

Der Server muss (MUST) die Antwort(en) auf demselben Stream senden und muss (MUST) nach der letzten Antwort über den STREAM FIN-Mechanismus anzeigen, dass keine weiteren Daten auf diesem Stream gesendet werden.

4.2.1. DNS Message IDs (DNS-Nachrichten-IDs)​

Beim Senden von Abfragen über eine QUIC-Verbindung muss (MUST) die DNS-Nachrichten-ID auf 0 gesetzt werden. Das Stream-Mapping für DoQ ermöglicht eine eindeutige Korrelation von Abfragen und Antworten, daher wird das Nachrichten-ID-Feld nicht benötigt.

4.3. DoQ Error Codes (DoQ-Fehlercodes)​

Die folgenden Fehlercodes sind definiert:

  • DOQ_NO_ERROR (0x0): Kein Fehler
  • DOQ_INTERNAL_ERROR (0x1): Interner Fehler
  • DOQ_PROTOCOL_ERROR (0x2): Protokollfehler
  • DOQ_REQUEST_CANCELLED (0x3): Anfrage abgebrochen
  • DOQ_EXCESSIVE_LOAD (0x4): Übermäßige Last
  • DOQ_UNSPECIFIED_ERROR (0x5): Nicht spezifizierter Fehler
  • DOQ_ERROR_RESERVED (0xd098ea5e): Für Tests reserviert

4.3.1. Transaction Cancellation (Transaktionsabbruch)​

Wenn ein DoQ-Client eine ausstehende Anfrage abbrechen möchte, muss (MUST) er ein QUIC STOP_SENDING ausgeben und sollte (SHOULD) den Fehlercode DOQ_REQUEST_CANCELLED verwenden.

4.3.2. Transaction Errors (Transaktionsfehler)​

Server schließen Transaktionen normalerweise ab, indem sie eine DNS-Antwort auf dem Stream der Transaktion senden. Wenn ein Server aufgrund eines internen Fehlers keine DNS-Antwort senden kann, sollte (SHOULD) er einen QUIC RESET_STREAM-Frame mit dem Fehlercode DOQ_INTERNAL_ERROR ausgeben.

4.3.3. Protocol Errors (Protokollfehler)​

Protokollfehler umfassen den Empfang einer Nachricht mit einer Nachrichten-ID ungleich Null, den Empfang eines STREAM FIN vor allen erwarteten Daten oder andere Protokollverletzungen. Wenn ein Peer auf einen solchen Fehler stößt, sollte (SHOULD) er die Verbindung mit dem Fehlercode DOQ_PROTOCOL_ERROR unter Verwendung des CONNECTION_CLOSE-Mechanismus von QUIC zwangsweise abbrechen.

4.3.4. Alternative Error Codes (Alternative Fehlercodes)​

Die Verwendung eines Fehlercodes in einem unerwarteten Kontext oder der Empfang eines unbekannten Fehlercodes muss (MUST) als gleichwertig mit DOQ_UNSPECIFIED_ERROR behandelt werden.

4.4. Connection Management (Verbindungsverwaltung)​

Clients und Server, die DoQ implementieren, sollten (SHOULD) die Verwendung des Idle-Timeouts aushandeln. Clients sollten (SHOULD) die Leerlaufzeit ihrer Verbindung überwachen und eine neue Verbindung aufbauen, wenn sich das Idle-Timeout nähert.

4.5. Session Resumption and 0-RTT (Sitzungswiederaufnahme und 0-RTT)​

Ein Client kann (MAY) die Mechanismen zur Sitzungswiederaufnahme und 0-RTT nutzen, wenn der Server sie unterstützt. Der 0-RTT-Mechanismus darf (MUST NOT) nicht zum Senden von DNS-Anfragen verwendet werden, die keine „wiederholbaren" Transaktionen sind. Nur Transaktionen mit einem OPCODE von QUERY oder NOTIFY werden als wiederholbar betrachtet.

4.6. Message Sizes (Nachrichtengrößen)​

DoQ-Abfragen und -Antworten werden auf QUIC-Streams gesendet, die theoretisch bis zu 2^62 Bytes transportieren können. DNS-Nachrichten sind jedoch auf eine maximale Größe von 65535 Bytes beschränkt. DoQ-Implementierungen gehen immer davon aus, dass die maximale Nachrichtengröße 65535 Bytes beträgt.

Letztes Update am