5. Intégration HTTP (HTTP Integration)

5.1. Interaction avec le cache (Cache Interaction)

Les échanges DoH sont compatibles avec le cache HTTP [RFC7234]. La durée de vie de fraîcheur (freshness lifetime) spécifiée pour une réponse DoH DOIT (MUST) être inférieure ou égale au TTL minimal dans la section Answer de la réponse DNS. Sinon, le cache pourrait fournir des réponses plus périmées que ce que le DNS définit. Si le TTL dans la section Answer est inférieur à la durée de vie de fraîcheur de la réponse HTTP, la réponse DNS peut être actualisée (via l'expiration et la validation habituelles du cache HTTP), et la réponse DNS retournée par le client DoH peut utiliser le TTL original plus court.

La clé de cache HTTP dérivée d'une requête DoH DOIT (MUST) inclure uniquement l'URI et le type de média de la requête (par exemple, le champ d'en-tête de requête Content-Type dans « application/dns-message »). Par exemple, inclure le champ d'en-tête Accept entraînerait une duplication inutile des entrées de cache pour des requêtes sémantiquement équivalentes. Cependant, conformément à la spécification HTTP, des en-têtes tels que « Authorization » devraient affecter le cache HTTP.

Les clients DoH PEUVENT (MAY) choisir de conserver une copie en cache de la réponse HTTP avant l'expiration de la fraîcheur du cache HTTP pour n'importe quelle raison (y compris, mais sans s'y limiter, la sémantique du cache HTTP privé et la connaissance nouvellement acquise des alias DNS). Les clients DoH PEUVENT (MAY) mettre à jour le TTL DNS pour qu'il soit cohérent avec la fraîcheur du cache HTTP, à condition que le TTL DNS soit inférieur ou égal à la fraîcheur du cache HTTP.

Les réponses aux requêtes HTTP conditionnelles [RFC7232] pour des requêtes DNS PEUVENT (MAY) revalider une réponse DNS non erronée comme entrée de cache. Le TTL DNS d'une réponse revalidée DEVRAIT (SHOULD) refléter la fraîcheur au moment de la réponse, et non la durée de vie restante de la réponse originale. Les clients peuvent avoir besoin de récupérer une nouvelle réponse lors de la réception d'une réponse 304 (Not Modified) pour obtenir un TTL mis à jour.

Les requêtes de plage (Range requests) [RFC7233] pour des requêtes DNS ne s'appliquent pas, car le contenu de la réponse ne se prête pas à la transmission par morceaux.

Les serveurs DoH PEUVENT (MAY) utiliser le push serveur HTTP (voir section 5.3) pour fournir des réponses aux clients DoH à l'avance, mais la politique de cache pour les réponses poussées est la même que pour les réponses non poussées.

Les redirections HTTP (telles que décrites à la section 4.2.1) modifient l'URI de la requête effective, et donc la clé utilisée pour le cache HTTP.

Les clients DoH DOIVENT (MUST) être capables de traiter le champ d'en-tête de réponse Vary [RFC7231]. Cela peut inclure le fait de ne pas mettre en cache les réponses aux requêtes pour de telles réponses.

Exemple : calcul de la durée de vie de fraîcheur

Si une réponse DNS contient trois enregistrements avec des TTL de 200, 300 et 400 secondes respectivement, la valeur max-age dans l'en-tête Cache-Control de la réponse HTTP DOIT être inférieure ou égale à 200 secondes :

Cache-Control: max-age=200

Si un client DoH reçoit une réponse du cache HTTP dont le champ d'en-tête Age indique que la réponse a été mise en cache pendant 50 secondes, le client peut utiliser cette réponse, mais le TTL effectif des enregistrements DNS devrait être réduit de 50 secondes.

5.2. HTTP/2

L'utilisation de HTTP/2 [RFC7540] permet de multiplexer les connexions entre les clients DoH et les serveurs DoH, réduisant ainsi la surcharge des requêtes DNS supplémentaires et améliorant les performances. Le nombre de requêtes pouvant être effectuées en parallèle est égal au paramètre SETTINGS_MAX_CONCURRENT_STREAMS HTTP/2 du serveur.

Le contrôle de flux des connexions HTTP/2 fournit également un certain contrôle sur la taille des requêtes. La taille minimale de la fenêtre au niveau du flux est de 65 535 octets. Les échanges DoH DEVRAIENT (SHOULD) au minimum fournir une taille de fenêtre de 65 535 octets pour éviter d'introduire des délais pour les réponses DNS inférieures ou égales à 65 535 octets.

Lors de l'utilisation du push serveur HTTP/2 (voir section 5.3), un flux bidirectionnel DOIT (MUST) être ouvert pour un échange normal de requête/réponse HTTP avant que ce flux de push puisse être déclaré.

5.3. Push serveur (Server Push)

Le push serveur HTTP/2 permet aux serveurs DoH de fournir des réponses DNS aux clients DoH avant que ceux-ci ne les demandent. Cela peut améliorer les performances. Par exemple, lorsqu'un client interroge l'enregistrement A d'un nom, le serveur peut pousser l'enregistrement AAAA du même nom.

Si une réponse poussée n'est pas utilisée immédiatement, elle est ajoutée au cache HTTP comme toute autre réponse HTTP, soumise aux mêmes politiques de contrôle de cache.

Les clients DoH DOIVENT (MUST) être capables de recevoir des réponses poussées du serveur, mais ne sont pas tenus de les utiliser. Les clients DoH PEUVENT (MAY) imposer des restrictions sur l'acceptation des réponses poussées, par exemple en limitant le nombre de réponses poussées en attente simultanément.

L'utilisation des réponses poussées nécessite que le client DoH soit capable d'associer les réponses poussées aux futures requêtes. À cette fin, lorsque la requête et la réponse poussée ont le même type de média, les clients DoH PEUVENT (MAY) associer une réponse poussée à une future requête effectuée via la méthode GET, à condition que l'URI de la réponse poussée corresponde à l'URI de cette requête.

5.4. Négociation de contenu (Content Negotiation)

Pour permettre la possibilité d'autres formats, les clients DoH PEUVENT inclure le champ d'en-tête HTTP Accept dans leurs requêtes. De telles requêtes DEVRAIENT (SHOULD) inclure le type de média « application/dns-message » pour assurer une interopérabilité minimale avec DoH.

Comme indiqué à la section 4.1, l'utilisation du champ d'en-tête Accept dans ces échanges a également des implications sur le cache HTTP, ce qui peut être indésirable.

Lors de l'utilisation du champ d'en-tête HTTP Accept, les serveurs DoH DEVRAIENT (SHOULD) retourner un champ d'en-tête de réponse Vary dont la valeur inclut au moins « Accept ».

Il est possible que le serveur ne puisse pas répondre dans le format demandé dans le champ d'en-tête Accept. Les clients DoH DOIVENT (MUST) être prêts à gérer cette situation.