3. Design Considerations (Considérations de conception)
Cette section et ses sous-sections présentent les lignes directrices de conception qui ont été utilisées pour DoQ. Alors que toutes les autres sections de ce document sont normatives, cette section est de nature informative.
3.1. Provide DNS Privacy (Fournir la confidentialité DNS)
DoT [RFC7858] définit comment atténuer certains des problèmes décrits dans « DNS Privacy Considerations » [RFC9076] en spécifiant comment transmettre des messages DNS sur TLS. Les « Usage Profiles for DNS over TLS and DNS over DTLS » [RFC8310] spécifient des profils d'utilisation stricts et opportunistes pour DoT, y compris comment les résolveurs stub peuvent authentifier les résolveurs récursifs.
La configuration de connexion QUIC inclut la négociation des paramètres de sécurité à l'aide de TLS, comme spécifié dans « Using TLS to Secure QUIC » [RFC9001], permettant le chiffrement du transport QUIC. La transmission de messages DNS sur QUIC fournira essentiellement les mêmes protections de confidentialité que DoT [RFC7858], y compris les profils d'utilisation stricts et opportunistes [RFC8310]. Une discussion plus approfondie à ce sujet est fournie dans la section 7.
3.2. Design for Minimum Latency (Conception pour une latence minimale)
QUIC est spécifiquement conçu pour réduire les délais induits par le protocole, avec des fonctionnalités telles que :
-
Prise en charge des données 0-RTT lors de la reprise de session.
-
Prise en charge des procédures avancées de récupération de perte de paquets comme spécifié dans « QUIC Loss Detection and Congestion Control » [RFC9002].
-
Atténuation du blocage en tête de ligne en permettant la livraison parallèle de données sur plusieurs flux.
Ce mappage de DNS vers QUIC tirera parti de ces fonctionnalités de trois manières :
-
Prise en charge optionnelle de l'envoi de données 0-RTT lors de la reprise de session (les implications en matière de sécurité et de confidentialité sont discutées dans les sections ultérieures).
-
Connexions QUIC de longue durée sur lesquelles plusieurs transactions DNS sont effectuées, générant le trafic soutenu requis pour bénéficier des fonctionnalités de récupération avancées.
-
Mappage de chaque transaction de requête/réponse DNS vers un flux séparé, pour atténuer le blocage en tête de ligne. Cela permet aux serveurs de répondre aux requêtes « dans le désordre ». Cela permet également aux clients de traiter les réponses dès leur arrivée, sans avoir à attendre la livraison dans l'ordre des réponses précédemment publiées par le serveur.
Ces considérations se reflètent dans le mappage du trafic DNS vers les flux QUIC dans la section 4.2.
3.3. Middlebox Considerations (Considérations relatives aux middleboxes)
L'utilisation de QUIC pourrait permettre à un protocole de dissimuler son objectif aux dispositifs sur le chemin réseau en utilisant des techniques de résistance au chiffrement et à l'analyse de trafic comme le remplissage, le rythme du trafic et la mise en forme du trafic. Cette spécification n'inclut aucune mesure conçue pour éviter une telle classification ; les mécanismes de remplissage définis dans la section 5.4 sont destinés à obscurcir les enregistrements spécifiques contenus dans les requêtes et réponses DNS, mais pas le fait qu'il s'agit de trafic DNS. Par conséquent, les pare-feu et autres middleboxes pourraient être en mesure de distinguer DoQ d'autres protocoles qui utilisent QUIC, comme HTTP, et d'appliquer un traitement différent.
L'absence de mesures dans cette spécification pour éviter la classification de protocole n'est pas une approbation de telles pratiques.
3.4. No Server-Initiated Transactions (Pas de transactions initiées par le serveur)
Comme indiqué dans la section 1, ce document ne spécifie pas la prise en charge des transactions initiées par le serveur au sein des connexions DoQ établies. C'est-à-dire que seul l'initiateur de la connexion DoQ peut envoyer des requêtes sur la connexion.
DSO prend en charge les transactions initiées par le serveur au sein des connexions existantes. Cependant, DoQ tel que défini ici ne répond pas aux critères d'un transport applicable pour DSO car il ne garantit pas la livraison dans l'ordre des messages ; voir la section 4.2 de [RFC8490].