3. Design Considerations (Designüberlegungen)
Dieser Abschnitt und seine Unterabschnitte präsentieren die Designrichtlinien, die für DoQ verwendet wurden. Während alle anderen Abschnitte in diesem Dokument normativ sind, ist dieser Abschnitt informativer Natur.
3.1. Provide DNS Privacy (DNS-Datenschutz bereitstellen)
DoT [RFC7858] definiert, wie einige der in „DNS Privacy Considerations" [RFC9076] beschriebenen Probleme gemildert werden können, indem spezifiziert wird, wie DNS-Nachrichten über TLS übertragen werden. Die „Usage Profiles for DNS over TLS and DNS over DTLS" [RFC8310] spezifizieren strikte und opportunistische Nutzungsprofile für DoT, einschließlich der Authentifizierung von rekursiven Resolvern durch Stub-Resolver.
Das QUIC-Verbindungssetup umfasst die Aushandlung von Sicherheitsparametern unter Verwendung von TLS, wie in „Using TLS to Secure QUIC" [RFC9001] spezifiziert, was die Verschlüsselung des QUIC-Transports ermöglicht. Die Übertragung von DNS-Nachrichten über QUIC bietet im Wesentlichen die gleichen Datenschutzgarantien wie DoT [RFC7858], einschließlich strikter und opportunistischer Nutzungsprofile [RFC8310]. Eine weitere Diskussion hierzu wird in Abschnitt 7 bereitgestellt.
3.2. Design for Minimum Latency (Design für minimale Latenz)
QUIC ist speziell darauf ausgelegt, protokollbedingte Verzögerungen zu reduzieren, mit Funktionen wie:
-
Unterstützung für 0-RTT-Daten während der Sitzungswiederaufnahme.
-
Unterstützung für erweiterte Paketverlust-Wiederherstellungsverfahren, wie in „QUIC Loss Detection and Congestion Control" [RFC9002] spezifiziert.
-
Minderung von Head-of-Line-Blocking durch parallele Datenübertragung auf mehreren Streams.
Dieses Mapping von DNS zu QUIC nutzt diese Funktionen auf drei Arten:
-
Optionale Unterstützung für das Senden von 0-RTT-Daten während der Sitzungswiederaufnahme (die Sicherheits- und Datenschutzimplikationen werden in späteren Abschnitten diskutiert).
-
Langlebige QUIC-Verbindungen, über die mehrere DNS-Transaktionen durchgeführt werden, wodurch der anhaltende Verkehr erzeugt wird, der erforderlich ist, um von erweiterten Wiederherstellungsfunktionen zu profitieren.
-
Zuordnung jeder DNS-Abfrage/Antwort-Transaktion zu einem separaten Stream, um Head-of-Line-Blocking zu mindern. Dies ermöglicht es Servern, auf Abfragen „außer der Reihe" zu antworten. Es ermöglicht Clients auch, Antworten zu verarbeiten, sobald sie eintreffen, ohne auf die geordnete Zustellung von zuvor vom Server gesendeten Antworten warten zu müssen.
Diese Überlegungen spiegeln sich im Mapping von DNS-Verkehr zu QUIC-Streams in Abschnitt 4.2 wider.
3.3. Middlebox Considerations (Middlebox-Überlegungen)
Die Verwendung von QUIC könnte es einem Protokoll ermöglichen, seinen Zweck vor Geräten auf dem Netzwerkpfad zu verschleiern, indem Verschlüsselung und Techniken zur Widerstandsfähigkeit gegen Verkehrsanalyse wie Padding, Verkehrssteuerung und Verkehrsformung verwendet werden. Diese Spezifikation enthält keine Maßnahmen, die darauf ausgelegt sind, eine solche Klassifizierung zu vermeiden; die in Abschnitt 5.4 definierten Padding-Mechanismen sollen die spezifischen Einträge in DNS-Abfragen und -Antworten verschleiern, nicht jedoch die Tatsache, dass es sich um DNS-Verkehr handelt. Folglich könnten Firewalls und andere Middleboxes in der Lage sein, DoQ von anderen Protokollen zu unterscheiden, die QUIC verwenden, wie HTTP, und eine unterschiedliche Behandlung anzuwenden.
Das Fehlen von Maßnahmen in dieser Spezifikation zur Vermeidung der Protokollklassifizierung ist keine Befürwortung solcher Praktiken.
3.4. No Server-Initiated Transactions (Keine vom Server initiierten Transaktionen)
Wie in Abschnitt 1 angegeben, spezifiziert dieses Dokument keine Unterstützung für vom Server initiierte Transaktionen innerhalb etablierter DoQ-Verbindungen. Das heißt, nur der Initiator der DoQ-Verbindung darf Abfragen über die Verbindung senden.
DSO unterstützt vom Server initiierte Transaktionen innerhalb bestehender Verbindungen. DoQ, wie hier definiert, erfüllt jedoch nicht die Kriterien für einen anwendbaren Transport für DSO, da es keine geordnete Zustellung von Nachrichten garantiert; siehe Abschnitt 4.2 von [RFC8490].