Quel port utilise le DNS ? Le port 53, et les exceptions

Quel port le DNS utilise-t-il pour une résolution ordinaire ?

Une requête normale, le genre que votre navigateur envoie des dizaines de fois par minute, sort sous la forme d’un seul paquet UDP vers le port 53 et revient de la même façon. La RFC 1035 appelle l’UDP « la méthode recommandée pour les requêtes standard sur internet » parce qu’elle n’a besoin d’aucune poignée de main : un paquet part, un paquet revient, terminé. C’est aussi pourquoi le DNS semble instantané quand ça marche et pourquoi un seul paquet perdu suffit à le faire paraître cassé, puisque l’UDP ne retente pas automatiquement pour vous. Le logiciel résolveur sur votre appareil ou votre routeur gère la nouvelle tentative, généralement contre un second serveur configuré si le premier reste silencieux.

Quand le DNS utilise-t-il TCP à la place ?

Deux situations poussent un échange DNS vers le port TCP 53. La première est un transfert de zone, où un serveur de noms secondaire récupère une copie complète d’une zone depuis le primaire. La RFC 1035 est explicite : « l’UDP n’est pas acceptable pour les transferts de zone » parce que l’opération a besoin d’un flux fiable et ordonné, pas d’un seul paquet au mieux. La seconde est une réponse qui ne tient pas dans la taille de message UDP utilisée. Quand cela arrive, le serveur renvoie un paquet UDP tronqué avec le bit TC (truncated) activé, et un résolveur conforme remarque ce bit et renvoie la même requête via TCP pour obtenir la réponse complète. Vous pouvez forcer ce comportement vous-même et voir directement la réponse complète :

dig +tcp example.com

Les requêtes du quotidien ont rarement besoin de ce chemin, mais il existe spécifiquement pour que le DNS continue de fonctionner quand une réponse dépasse ce qu’un seul paquet UDP peut contenir, ce qui arrive plus souvent qu’avant.

Qu’était la limite de 512 octets, et qu’est-ce qui l’a changée ?

La RFC 1035 fixait la taille de message UDP à 512 octets, en-tête inclus, sans compter les en-têtes IP ou UDP eux-mêmes. Ce nombre était généreux en 1987, quand une réponse DNS était une poignée d’enregistrements d’adresse. Il a cessé d’être généreux une fois que les signatures DNSSEC, les noms d’hôtes plus longs et les enregistrements avec de nombreuses adresses IP sont devenus normaux, parce qu’une réponse signée avec un enregistrement RRSIG dépasse couramment 512 octets à elle seule.

La RFC 6891, publiée en 2013, a corrigé le plafond sans toucher au protocole filaire : EDNS0 ajoute un pseudo-enregistrement OPT qui permet à un résolveur d’annoncer « la plus grande charge utile UDP pouvant être réassemblée et livrée dans la pile réseau du demandeur », et la RFC suggère 4096 octets comme point de départ pratique. Un résolveur et un serveur qui prennent tous deux en charge EDNS0 peuvent échanger des réponses plusieurs fois plus grandes que l’ancien plafond de 512 octets sur un seul paquet UDP, et ne se replient sur TCP que lorsque même cette marge plus large ne suffit pas. Presque tous les résolveurs utilisés aujourd’hui, y compris celui de votre propre système d’exploitation, parlent EDNS0 par défaut, donc cette mise à niveau a déjà eu lieu sans aucune action de votre part.

Pourquoi les pare-feux qui n’autorisent que l’UDP 53 causent de vrais problèmes

Une règle de pare-feu écrite il y a des années et jamais révisée dit souvent « autoriser le port UDP 53, refuser tout ce qui touche au DNS ». Cette règle bloque le repli TCP dont le protocole a besoin, et l’échec qu’elle produit est facile à mal diagnostiquer parce que la plupart des résolutions continuent de fonctionner normalement. Seules celles qui dépassent la limite UDP échouent, et elles échouent d’une façon qui semble aléatoire : un domaine se résout normalement la plupart du temps puis expire, en particulier une fois la validation DNSSEC impliquée, puisqu’un résolveur validant doit récupérer les enregistrements RRSIG et DNSKEY en plus de la réponse qu’il demandait.

Le résultat pratique est que les zones signées DNSSEC et tout ensemble d’enregistrements avec de nombreuses valeurs (un domaine avec une douzaine de serveurs de messagerie, par exemple) deviennent peu fiables derrière un pare-feu UDP seul, tandis que tout le reste paraît sain. Bloquer le TCP 53 sortant, ou le bloquer dans une seule direction, est l’une des pannes DNS auto-infligées les plus courantes, et cela apparaît rarement dans une vérification de connectivité basique parce que cette vérification n’essaie généralement que l’UDP.

DNS over TLS et DNS over HTTPS : ports différents, mêmes résolutions

Deux transports plus récents transportent les mêmes requêtes et réponses DNS mais les déplacent entièrement hors du port 53. DNS over TLS, défini par la RFC 7858, enveloppe chaque requête dans une session TLS sur le port TCP 853, choisi pour qu’un opérateur réseau puisse toujours voir que le DoT est en cours (et le bloquer) même sans le déchiffrer, puisque le port lui-même est un signal clair.

DNS over HTTPS, défini par la RFC 8484, va plus loin. Il envoie les requêtes DNS comme des requêtes HTTPS ordinaires sur le port 443, le même port que n’importe quel autre site que vous visitez, et la RFC mentionne « la capacité de mélanger le trafic DoH avec d’autres trafics HTTPS sur la même connexion » comme une propriété délibérée. C’est tout l’intérêt du DoH : un réseau qui n’inspecte ou ne filtre que par port ne peut pas distinguer une résolution DNS de n’importe quelle autre requête HTTPS, parce que c’est le même protocole sur le même port. Chrome, Firefox et Edge peuvent tous envoyer le DNS de cette façon par défaut maintenant, ce qui explique pourquoi bloquer « le port 53 » sur un réseau ne garantit plus que vous avez bloqué le DNS. Cela garantit que vous avez bloqué le transport classique ; un navigateur avec DoH activé continue de résoudre des noms sur le port 443 quoi qu’il arrive.

Qu’est-ce que le mDNS sur le port 5353 ?

Le Multicast DNS est un protocole différent portant un nom similaire. La RFC 6762 le définit comme des appareils « envoyant des messages de requête et de réponse UDP de type DNS sur IP Multicast vers le port UDP 5353 », adressés au groupe multicast 224.0.0.251 (ou son équivalent IPv6, FF02::FB) plutôt qu’à un serveur précis. Il n’y a aucun serveur de noms central impliqué : chaque appareil sur le segment de réseau local écoute sur le port 5353 et répond pour son propre nom. C’est ainsi qu’une imprimante ou une enceinte connectée devient joignable en tant que device.local sans que personne n’ait configuré d’enregistrement DNS pour elle. C’est confiné au lien local par conception et n’a rien à voir avec la résolution d’un nom de domaine public, donc le trafic mDNS n’a jamais besoin de quitter votre routeur.

Comment tester si le port 53 est joignable

Commencez par une requête directe contre un résolveur connu comme fiable, ce qui vous dit si les résolutions UDP ordinaires fonctionnent du tout :

nslookup example.com 8.8.8.8
dig example.com @1.1.1.1

Si cela réussit mais que vous soupçonnez le chemin de repli TCP d’être bloqué, forcez TCP et comparez :

dig +tcp example.com @1.1.1.1

Une requête UDP qui réussit alors que la version forcée en TCP expire est un signe fort que quelque chose entre vous et le résolveur abandonne spécifiquement le TCP 53, exactement le mode d’échec décrit plus haut. Tester la joignabilité brute d’un port depuis l’extérieur de votre propre réseau est là où notre outil de vérification de port est utile : pointez-le vers le port 53 de votre résolveur ou serveur de noms et il ouvre une vraie connexion TCP depuis un autre réseau, confirmant si le TCP 53 est joignable du tout. Lisez le résultat avec une réserve en tête : un vérificateur de port teste le TCP, donc un succès là confirme que le chemin de repli est ouvert mais ne dit rien sur l’UDP, qui n’a pas de poignée de main à tester de la même façon. Pour la requête elle-même, y compris comparer les réponses de plusieurs résolveurs publics et différentes régions à la fois, lancez l’outil de requête DNS.

Questions fréquentes

Dois-je ouvrir le TCP 53 en plus de l’UDP 53 ?

Oui, pour le trafic résolveur sortant. Un pare-feu qui n’autorise que l’UDP 53 traitera bien la plupart des requêtes puis échouera de façon imprévisible sur des réponses plus grandes, typiquement signées DNSSEC, qui ont besoin du repli TCP.

Bloquer le port 53 arrête-t-il tout le trafic DNS ?

Plus vraiment. Cela bloque le transport UDP/TCP classique. DNS over HTTPS tourne sur le port 443 et ressemble à n’importe quelle autre requête HTTPS, et DNS over TLS tourne sur son propre port 853, donc un navigateur ou une application avec l’un ou l’autre activé continue de résoudre des noms.

DNS over HTTPS est-il le même protocole que le DNS classique ?

Les requêtes et réponses sont les mêmes enregistrements et codes DNS définis par la RFC 1035. Seul le transport change : au lieu d’un paquet UDP ou TCP brut sur le port 53, la même requête est enveloppée dans une requête HTTPS sur le port 443.

Pourquoi dig utilise-t-il parfois TCP sans qu’on le lui demande ?

Quand une réponse UDP revient tronquée, avec le bit TC activé, un client conforme aux standards renvoie automatiquement la requête via TCP pour obtenir la réponse complète. Vous voyez cela le plus souvent sur des domaines avec DNSSEC activé ou de nombreux enregistrements du même type.

Le mDNS sur le port 5353 est-il la même chose que le DNS de mon FAI ?

Non. Le mDNS fonctionne seulement sur votre segment de réseau local, n’a aucun serveur central, et résout des noms comme device.local pour des appareils sur le même lien. Il n’a aucun rôle dans la résolution d’un domaine public comme example.com.

Quelle est une taille de charge utile EDNS0 normale aujourd’hui ?

La RFC 6891 suggère 4096 octets comme défaut pratique, et la plupart des résolveurs actuels annoncent quelque chose dans cette plage, bien au-dessus du plafond d’origine de 512 octets, avant de ne se replier sur TCP que lorsque même cela ne suffit pas.