Annexe A. Développement du protocole (Protocol Development)

Les versions antérieures de ce protocole utilisaient des types de médias et des structures d'URI différents. La conception actuelle a évolué sur la base de l'expérience d'implémentation et des retours de la communauté IETF.

La proposition initiale envisageait d'utiliser un schéma d'URI dédié (par exemple « dns-over-https: ») plutôt que l'URI standard « https: ». Cependant, il a été décidé d'utiliser l'URI standard « https: » pour une meilleure intégration avec l'infrastructure HTTP existante et pour rendre le trafic DoH plus difficile à distinguer du trafic HTTPS ordinaire.

Le choix du type de média a également fait l'objet de plusieurs itérations. Le type de média « application/dns-message » a été choisi pour indiquer explicitement que le contenu est un message au format DNS Wire Format (format filaire DNS). D'autres formats, notamment JSON, ont été envisagés, mais il a été décidé d'utiliser le format DNS Wire Format comme format par défaut, car il est compatible avec l'infrastructure DNS existante et plus efficace.

Le mécanisme de modèle d'URI (URI Template) a été ajouté pour offrir de la flexibilité, permettant aux serveurs DoH d'utiliser différents chemins d'URI tout en maintenant la compatibilité avec le protocole. Cela facilite également l'ajout futur de nouveaux paramètres et fonctionnalités.

Les méthodes POST et GET ont toutes deux été incluses pour prendre en charge différents cas d'utilisation. La méthode POST est généralement plus efficace car elle évite la surcharge de l'encodage base64, mais la méthode GET est plus compatible avec les caches HTTP et peut être plus facile à implémenter dans certains environnements.

La prise en charge de HTTP/2 a été jugée importante car elle offre le multiplexage et d'autres avantages en termes de performances. Bien que HTTP/1.1 puisse également être utilisé, l'utilisation de HTTP/2 ou d'une version ultérieure est fortement recommandée pour des performances optimales.

Les considérations de sécurité et de vie privée ont été des préoccupations majeures tout au long du développement. L'exigence d'utiliser HTTPS et l'authentification du serveur visent à prévenir les attaques passives et certains types d'attaques actives. Cependant, il a également été reconnu que DoH ne peut pas résoudre tous les problèmes de sécurité et de vie privée, en particulier ceux liés au serveur DoH lui-même.

Le développement de ce protocole a impliqué une collaboration étendue entre des contributeurs des communautés DNS, HTTP et sécurité. Cette collaboration inter-communautaire a été essentielle pour s'assurer que le protocole répond aux besoins de toutes les parties concernées.