DNS-over-HTTPS transporte les messages DNS via HTTPS. Il protège la relation de transport avec le point de terminaison DoH choisi, mais il ne fait pas de ce point de terminaison le résolveur utilisé par un destinataire de courrier. La réponse actuelle d'un navigateur et la recherche d'authentification d'un destinataire peuvent légitimement différer car leurs chemins de résolution, leurs caches et leurs politiques diffèrent.
Distinguer le transport de la confiance DNS
Références : RFC 8484 §8.1, RFC 4033 §3.
RFC 8484 définit les échanges d'applications/messages DNS en utilisant le format filaire DNS . Un statut de réussite HTTPS ne signifie pas en soi que la réponse DNS intégrée contient les enregistrements demandés. Lisez le code de réponse DNS , les indicateurs et les jeux d'enregistrements ainsi que l'état HTTP.
TLS auprès du service DoH authentifie le point de terminaison HTTPS selon son modèle de confiance. Cela ne remplace pas DNSSEC validation des données DNS faisant autorité. Un service DoH peut valider, filtrer ou appliquer une autre politique ; établir son comportement documenté au lieu de le déduire du schéma HTTPS.
Tenir compte de deux couches de mise en cache
Références : RFC 8484 §5.1, RFC 8484 §6.
DoH peut impliquer des caches HTTP en plus des caches DNS . RFC 8484 limite la fraîcheur HTTP par rapport aux données DNS et exige que les clients tiennent compte de la valeur HTTP Age lors du calcul de la durée de vie DNS restante. Un diagnostic qui ignore ces couches peut comparer les réponses d’âges différents comme s’il s’agissait de nouvelles recherches simultanées.
L'API DNS JSON d'un fournisseur n'est pas automatiquement l'interface au format filaire RFC 8484 . Enregistrez le point de terminaison, la méthode de demande, le type de média, les questions DNS et les en-têtes de réponse. Ne remplacez pas le message DNS par une étiquette d'état de page Web.
Reproduire une comparaison de réponses capturées
Références : RFC 8484 §4.2.1, RFC 8484 §5.1.
Construisez un appareil hors ligne avec deux descriptions de réponse DNS valides pour le même propriétaire et le même type TXT . Le luminaire DoH contient la politique P avec DNS TTL 300, HTTP Age 120 et des métadonnées de fraîcheur HTTP compatibles. Dans le modèle simplifié sans autre délai, il ne reste pas plus de 180 secondes de DNS TTL. Un appareil récepteur-résolveur obtenu après un changement contient la politique Q.
L'analyse attendue indique que les observations diffèrent en termes de résolveur et d'âge, mais que l'un ou l'autre des transports est intrinsèquement erroné. Ajouter un deuxième appareil avec HTTP 200 mais un DNS intégré SERVFAIL ; la classification attendue est un échec DNS et non une récupération de stratégie réussie. Le modèle compagnon d'origine vérifie uniquement ces classifications. L’échange HTTPS isolé historique retenu ci-dessous a testé le décodage filaire séparément.
Pour la reproduction en direct, utilisez un client compatible RFC 8484 , enregistrez sa version et enregistrez les métadonnées DNS et HTTP brutes à partir d'un point de terminaison autorisé. Comparez le même propriétaire et le même type avec le résolveur de courrier prévu lorsqu'il est accessible et avec chaque autorité. Les tests de production DoH et de chemin de réception restent en attente ; l'expérience HTTPS isolée ci-dessous est distincte.
Limitez les revendications de confidentialité
Références : RFC 8484 §8.2.
L'opérateur DoH reçoit la requête et peut observer les informations de connexion client pertinentes. HTTPS ne cache pas la requête à cet opérateur et ne garantit pas que chaque échange DNS ultérieur est crypté. Ne déplacez pas les noms internes sensibles vers un résolveur externe sans objectif autorisé et sans portée de partage de données.
Utilisez les résultats DoH comme une observation. Diagnostiquez les différences par nom, type, état d’autorité, âge du cache, validation et politique. Terminer les enquêtes d'authentification avec le message et la preuve du destinataire nécessaires à la réclamation ; un résultat DNS vert côté navigateur ne constitue pas une garantie de livraison du courrier.
Preuves historiques conservées en laboratoire
La capture conservée est datée du 7 novembre 2026. Ce qui suit décrit cette observation historique limitée, et non une nouvelle exécution ou un test d' EmailAuth.ai .
Un véritable HTTPS POST transportait une question au format filaire DNS vers un point de terminaison de bouclage isolé avec un certificat temporaire approuvé uniquement par ce client de test. Le point de terminaison a renvoyé application/dns-message et l'ancien message du redirecteur amorcé. p=none réponse; un transitaire séparé renvoyait du courant p=reject données. Un deuxième HTTPS POST a renvoyé HTTP 200 avec DNS intégré SERVFAIL , que le client a décodé correctement. Les en-têtes HTTP, les octets DNS et les heures sont conservés. Ce point de terminaison utilisait Cache-Control: no-store; l'arithmétique d'âge antérieure reste un modèle distinct, et non une expérience de cache HTTP observée. Les étiquettes de capture sont HTTPS_/dns-query ; Erreur HTTPS_/dns ; solver2_fresh_new. Les coureurs retenus et les captures brutes sont inclus dans ce dossier de révision à titre de preuves historiques. Ils ont été inspectés et non réexécutés pour cet examen. Les résultats de production DNS , DNSSEC et SMTP n'ont pas encore été testés.