Aller au contenu principal

4. Specifications (Spécifications)

4.1. Connection Establishment (Établissement de connexion)​

Les connexions DoQ sont établies comme décrit dans la spécification de transport QUIC [RFC9000]. Pendant l'établissement de la connexion, le support DoQ est indiqué en sélectionnant le jeton de négociation de protocole de couche application (ALPN) « doq » dans la poignée de main cryptographique.

4.1.1. Port Selection (Sélection de port)​

Par défaut, un serveur DNS qui supporte DoQ doit (MUST) écouter et accepter les connexions QUIC sur le port UDP dédié 853 (Section 8), sauf s'il existe un accord mutuel pour utiliser un autre port.

Par défaut, un client DNS souhaitant utiliser DoQ avec un serveur particulier doit (MUST) établir une connexion QUIC vers le port UDP 853 sur le serveur, sauf s'il existe un accord mutuel pour utiliser un autre port.

Les connexions DoQ ne doivent pas (MUST NOT) utiliser le port UDP 53. Cette recommandation contre l'utilisation du port 53 pour DoQ vise à éviter la confusion entre DoQ et l'utilisation de DNS sur UDP [RFC1035].

4.2. Stream Mapping and Usage (Mappage et utilisation des flux)​

Le mappage du trafic DNS sur les flux QUIC tire parti des fonctionnalités de flux QUIC détaillées dans la section 2 de [RFC9000].

Tous les messages DNS (requêtes et réponses) envoyés sur les connexions DoQ doivent (MUST) être encodés sous forme d'un champ de longueur de 2 octets suivi du contenu du message tel que spécifié dans [RFC1035].

Le client doit (MUST) sélectionner le prochain flux bidirectionnel initié par le client disponible pour chaque requête ultérieure sur une connexion QUIC. Le client doit (MUST) envoyer la requête DNS sur le flux sélectionné et doit (MUST) indiquer via le mécanisme STREAM FIN qu'aucune autre donnée ne sera envoyée sur ce flux.

Le serveur doit (MUST) envoyer la ou les réponses sur le même flux et doit (MUST) indiquer, après la dernière réponse, via le mécanisme STREAM FIN qu'aucune autre donnée ne sera envoyée sur ce flux.

4.2.1. DNS Message IDs (Identifiants de message DNS)​

Lors de l'envoi de requêtes sur une connexion QUIC, l'identifiant de message DNS doit (MUST) être défini sur 0. Le mappage de flux pour DoQ permet une corrélation non ambiguë des requêtes et des réponses, le champ d'identifiant de message n'est donc pas nécessaire.

4.3. DoQ Error Codes (Codes d'erreur DoQ)​

Les codes d'erreur suivants sont définis :

  • DOQ_NO_ERROR (0x0) : Pas d'erreur
  • DOQ_INTERNAL_ERROR (0x1) : Erreur interne
  • DOQ_PROTOCOL_ERROR (0x2) : Erreur de protocole
  • DOQ_REQUEST_CANCELLED (0x3) : Requête annulée
  • DOQ_EXCESSIVE_LOAD (0x4) : Charge excessive
  • DOQ_UNSPECIFIED_ERROR (0x5) : Erreur non spécifiée
  • DOQ_ERROR_RESERVED (0xd098ea5e) : Réservé pour les tests

4.3.1. Transaction Cancellation (Annulation de transaction)​

Si un client DoQ souhaite annuler une requête en cours, il doit (MUST) émettre un STOP_SENDING QUIC et devrait (SHOULD) utiliser le code d'erreur DOQ_REQUEST_CANCELLED.

4.3.2. Transaction Errors (Erreurs de transaction)​

Les serveurs complètent normalement les transactions en envoyant une réponse DNS sur le flux de la transaction. Si un serveur est incapable d'envoyer une réponse DNS en raison d'une erreur interne, il devrait (SHOULD) émettre une trame QUIC RESET_STREAM avec le code d'erreur DOQ_INTERNAL_ERROR.

4.3.3. Protocol Errors (Erreurs de protocole)​

Les erreurs de protocole incluent la réception d'un message avec un identifiant de message non nul, la réception d'un STREAM FIN avant toutes les données attendues, ou d'autres violations de protocole. Si un pair rencontre une telle erreur, il devrait (SHOULD) interrompre de force la connexion en utilisant le mécanisme CONNECTION_CLOSE de QUIC avec le code d'erreur DOQ_PROTOCOL_ERROR.

4.3.4. Alternative Error Codes (Codes d'erreur alternatifs)​

L'utilisation d'un code d'erreur dans un contexte inattendu ou la réception d'un code d'erreur inconnu doit (MUST) être traitée comme équivalente à DOQ_UNSPECIFIED_ERROR.

4.4. Connection Management (Gestion de connexion)​

Les clients et serveurs implémentant DoQ devraient (SHOULD) négocier l'utilisation du délai d'inactivité. Les clients devraient (SHOULD) surveiller le temps d'inactivité sur leur connexion et établir une nouvelle connexion si le délai d'inactivité approche.

4.5. Session Resumption and 0-RTT (Reprise de session et 0-RTT)​

Un client peut (MAY) profiter des mécanismes de reprise de session et 0-RTT si le serveur les supporte. Le mécanisme 0-RTT ne doit pas (MUST NOT) être utilisé pour envoyer des requêtes DNS qui ne sont pas des transactions « rejouables ». Seules les transactions avec un OPCODE de QUERY ou NOTIFY sont considérées comme rejouables.

4.6. Message Sizes (Tailles de message)​

Les requêtes et réponses DoQ sont envoyées sur des flux QUIC, qui peuvent transporter jusqu'à 2^62 octets. Cependant, les messages DNS sont limités à une taille maximale de 65535 octets. Les implémentations DoQ supposent toujours que la taille maximale du message est de 65535 octets.

Dernière mise à jour le