4. L'échange HTTP (The HTTP Exchange)

4.1. La requête HTTP (The HTTP Request)

Un client DoH encode une seule requête DNS sous forme de requête HTTP en utilisant la méthode GET ou POST et les autres exigences de cette section. Le serveur DoH définit l'URI utilisé par la requête via un modèle d'URI (URI Template).

Le modèle d'URI défini dans ce document est traité sans aucune variable lorsque la méthode HTTP est POST. Lorsque la méthode HTTP est GET, la variable unique « dns » est définie comme le contenu de la requête DNS (tel que décrit à la section 6), encodé en base64url [RFC4648].

Les futures spécifications de nouveaux types de médias DoH DOIVENT (MUST) définir les variables à utiliser avec ce protocole pour le traitement des modèles d'URI.

Les serveurs DoH DOIVENT (MUST) implémenter les méthodes POST et GET.

Lors de l'utilisation de la méthode POST, la requête DNS est incluse dans le corps du message HTTP, et le champ d'en-tête de requête Content-Type indique le type de média du message. Les requêtes POST sont généralement plus petites que les requêtes GET équivalentes.

L'utilisation de la méthode GET est plus compatible avec de nombreuses implémentations de cache HTTP.

Les clients DoH DEVRAIENT (SHOULD) inclure le champ d'en-tête de requête HTTP Accept pour indiquer les types de contenu compréhensibles dans la réponse. Quelle que soit la valeur du champ Accept, le client DOIT (MUST) être prêt à traiter une réponse « application/dns-message » (telle que décrite à la section 6), mais PEUT (MAY) également traiter d'autres types de médias DNS reçus.

Pour maximiser la compatibilité avec le cache HTTP, les clients DoH utilisant des formats de médias contenant le champ ID dans l'en-tête DNS (par exemple « application/dns-message ») DEVRAIENT (SHOULD) utiliser un ID DNS de 0 dans chaque requête DNS. HTTP associe les requêtes et les réponses, éliminant ainsi le besoin d'utiliser l'ID dans des types de médias tels que « application/dns-message ». L'utilisation d'ID DNS variables peut entraîner la mise en cache séparée de requêtes DNS sémantiquement équivalentes.

Les clients DoH PEUVENT (MAY) utiliser le rembourrage (Padding) et la compression (Compression) HTTP/2 [RFC7540] de la même manière que les autres clients HTTP/2.

4.1.1. Exemples de requêtes HTTP (HTTP Request Examples)

Ces exemples utilisent le format de style HTTP/2 de [RFC7540].

Ces exemples utilisent un service DoH avec le modèle d'URI https://dnsserver.example.net/dns-query{?dns} pour résoudre les enregistrements IN A.

La requête est représentée sous forme de corps avec le type de média « application/dns-message ».

Le premier exemple montre une requête utilisant la méthode GET pour interroger www.example.com :

:method = GET
:scheme = https
:authority = dnsserver.example.net
:path = /dns-query?dns=AAABAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB
accept = application/dns-message

Les données de la requête DNS se trouvent dans la variable « dns ». Certains détails d'encodage et de rembourrage ont été omis.

Le deuxième exemple montre une requête utilisant la méthode POST pour la même requête :

:method = POST
:scheme = https
:authority = dnsserver.example.net
:path = /dns-query
accept = application/dns-message
content-type = application/dns-message
content-length = 33

<33 bytes represented by the following hex encoding>
00 00 01 00 00 01 00 00  00 00 00 00 03 77 77 77
07 65 78 61 6d 70 6c 65  03 63 6f 6d 00 00 01 00
01

Enfin, un exemple montre comment interroger l'enregistrement A de www.example.com en utilisant JSON [RFC8259] (également connu sous le type de média « application/json »). Ceci n'est pas compatible avec DoH, mais illustre l'utilisation de la négociation de contenu :

:method = GET
:scheme = https
:authority = dnsserver.example.net
:path = /dns-query?dns=AAABAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB
accept = application/dns-json

4.2. La réponse HTTP (The HTTP Response)

Le seul type de réponse défini dans ce document est « application/dns-message », mais d'autres formats de réponse pourront être définis à l'avenir.

Les serveurs DoH DOIVENT (MUST) être capables de traiter les messages de requête « application/dns-message ».

Les serveurs DoH DEVRAIENT (SHOULD) être capables de fournir des réponses « application/dns-message ».

Les serveurs DoH PEUVENT (MAY) fournir des réponses de négociation de contenu pour les requêtes utilisant la méthode GET.

Le champ d'en-tête de réponse Content-Type d'une réponse HTTP réussie indique le type de média de la réponse. La réponse peut contenir une réponse DNS au format « application/dns-message » défini à la section 6, ou un autre type fourni par négociation de contenu.

Si une réponse HTTP est présente, les champs d'en-tête de réponse HTTP indiquent le format de la réponse. Le type de média de la réponse détermine comment analyser et traiter la réponse. Les clients DoH DOIVENT (MUST) être capables de traiter les réponses au format « application/dns-message » et PEUVENT (MAY) être capables de traiter d'autres formats.

Lors de l'utilisation du type de contenu « application/dns-message », le corps du message de réponse contient la réponse DNS complète (y compris tous les champs d'en-tête), sauf si le code de réponse HTTP indique que la requête n'a pas réussi (voir ci-dessous). Les serveurs DoH DOIVENT (MUST) définir le champ « query identifier » (QID) dans l'en-tête DNS de la réponse à zéro. Les clients DoH DOIVENT (MUST) ignorer le champ QID dans la réponse DNS.

4.2.1. Gestion des erreurs DNS et HTTP (Handling DNS and HTTP Errors)

Si la réponse DNS n'est pas réussie, le serveur DoH retourne quand même un code de statut HTTP de succès (2xx) avec la réponse DNS. La réponse DNS elle-même indiquera l'erreur au niveau DNS.

Si le serveur ne peut pas résoudre la requête, il retourne généralement une erreur HTTP 4xx. Le client DEVRAIT (SHOULD) traiter cela comme une réponse DNS SERVFAIL.

Si le serveur refuse le service, il PEUT (MAY) utiliser une redirection HTTP (code de statut 3xx). Les clients DoH DOIVENT (MUST) gérer les redirections HTTP. Les clients DoH DEVRAIENT (SHOULD) imposer une limite supérieure au nombre de redirections pour éviter les boucles, de manière similaire aux clients HTTP ordinaires.

Si la requête DNS est absente ou si le serveur DoH ne peut pas analyser la requête DNS, le serveur DEVRAIT (SHOULD) retourner une erreur HTTP 400 (Bad Request).

Si le serveur DoH rencontre un problème technique non lié au DNS, il DEVRAIT (SHOULD) retourner une erreur HTTP 500 (Internal Server Error).

Si le serveur DoH ne fournit pas de service DoH sur le chemin d'URI configuré, il DEVRAIT (SHOULD) retourner une erreur HTTP 404 (Not Found).

Si le serveur DoH ne prend pas en charge le type de média soumis par le client, il DEVRAIT (SHOULD) retourner une erreur HTTP 415 (Unsupported Media Type).

4.2.2. Exemple de réponse HTTP (HTTP Response Example)

Voici la réponse au premier exemple de requête de la section 4.1.1 :

:status = 200
content-type = application/dns-message
content-length = 64
cache-control = max-age=128

<64 bytes represented by the following hex encoding>
00 00 81 80 00 01 00 01  00 00 00 00 03 77 77 77
07 65 78 61 6d 70 6c 65  03 63 6f 6d 00 00 01 00
01 03 77 77 77 07 65 78  61 6d 70 6c 65 03 63 6f
6d 00 00 01 00 01 00 00  00 80 00 04 5d b8 d8 22

La réponse DNS de cet exemple indique que l'adresse IPv4 de www.example.com est 93.184.216.34, avec un TTL de 128 secondes pour cette information.