Les requêtes DNS voyagent-elles toujours via UDP?
J'ai passé un peu de temps à rechercher ce sujet et je n'arrive pas à trouver une réponse exacte, donc je suis assez confiant que ce n'est pas un doublon, et bien que ma question soit basée sur un besoin de sécurité, je pense qu'il est toujours sûr de demandez ici mais faites-moi savoir si je dois le déplacer la communauté de sécurité.
Essentiellement, les requêtes DNS utilisent-elles jamais TCP (si oui, quel scénario cela pourrait-il se produire)? Encore une fois, je ne parle que de requêtes. Est-il possible pour elles de voyager via TCP? Si les domaines ne peut avoir qu'une longueur maximale de 253 octets, et les paquets UDP peuvent atteindre 512 octets, les requêtes ne sortiront-elles pas toujours comme UDP? Je ne pensais pas qu'une requête résolvable pouvait être suffisamment grande pour nécessiter l'utilisation de TCP . Si un serveur DNS recevait une demande pour un domaine supérieur à 253 octets, le serveur le supprimerait-il/ne tenterait-il pas de le résoudre? Je suis certain que j'ai fait de fausses hypothèses ici.
Pour un certain contexte, je travaille avec le groupe de sécurité pour intégrer les requêtes DNS dans leur outil de surveillance de la sécurité, et pour diverses raisons, nous avons décidé de capturer ce trafic via la capture de paquets standard sur les serveurs DNS et les contrôleurs de domaine. La principale exigence est de capturer toutes les requêtes DNS afin qu'elles puissent identifier quel client a tenté de résoudre un domaine donné. Sur la base de cette exigence, nous ne nous préoccupons pas de capturer les réponses DNS ou tout autre trafic comme les transferts de zone, ce qui est également motivé par le fait que nous devons limiter le volume de journal autant que possible. En tant que tel, nous prévoyons de capturer uniquement les requêtes DNS destinées au serveur DNS et envoyées via UDP. Pour plus de contexte (type de portée de la question qui rampe ici), il a maintenant été évoqué que nous devions peut-être étendre la visibilité de la sécurité afin qu'ils puissent surveiller les activités telles que les canaux secrets exécutés sur DNS (ce qui présenterait également la nécessité de capturer les réponses DNS, et par la suite TCP trafic). Mais même dans ce genre de scénario, je pensais que tout trafic DNS sortant serait sous la forme de recherches/requêtes, et que celles-ci seraient toujours sur UDP, même si à partir d'une source malveillante (à cause de mon raisonnement dans le premier paragraphe). Cela soulève donc quelques questions supplémentaires:
Ne capturerions-nous pas au moins la moitié de la conversation avec l'approche que j'ai décrite? Ou un client enverrait-il jamais du trafic DNS qui n'est pas sous la forme d'une requête? (peut-être comme une sorte de réponse à la réponse d'un serveur DNS et finit peut-être par passer par TCP)
Les requêtes DNS peuvent-elles être modifiées pour utiliser TCP? Un serveur DNS accepterait-il et répondrait-il à une requête DNS venant de TCP?
Je ne sais pas si c'est pertinent, mais nous limitons les demandes DNS aux serveurs DNS autorisés et bloquons tout autre trafic sortant sur le port 53. Je suis définitivement une recrue, donc je suis désolé si ma question n'est pas conforme, et faites-le moi savoir comment je devrais modifier.
Les requêtes DNS normales utilisent le port UDP 53, mais les requêtes plus longues (> 512 octets) recevront une réponse 'tronquée', qui se traduira par une conversation TCP 53 pour faciliter l'envoi/la réception de la requête entière. , le serveur DNS se lie au port 53, mais la requête elle-même provient d'un port aléatoire de numéro élevé (49152 ou supérieur) envoyé au port 53. La réponse sera renvoyée à ce même port à partir du port 53.
Ports réseau utilisés par DNS | Microsoft Docs
Donc, si vous prévoyez de faire de la surveillance de sécurité sur les requêtes DNS de votre réseau, vous devrez tenir compte de ce qui précède.
En ce qui concerne le trafic sans recherche, considérez que DNS utilise également des transferts de zone (type de requête AXFR) pour mettre à jour d'autres serveurs DNS avec de nouveaux enregistrements. Un homme au milieu de l'attaque peut commencer par un tel transfert, DDOS sur un serveur de noms principal afin qu'il soit trop occupé pour répondre à un secondaire demandant des enregistrements mis à jour. Le pirate usurpe ensuite ce même serveur principal pour envoyer des enregistrements "empoisonnés" au serveur secondaire, qui redirigent les domaines DNS populaires vers des hôtes compromis.
Votre audit de sécurité doit donc porter une attention particulière au type de requête AXFR, et vos systèmes DNS ne doivent accepter que les échanges AXFR à partir d'adresses IP spécifiques.
Cela a commencé comme un commentaire à la réponse de George, mais c'est devenu long. La vue d'ensemble est quelque peu compliquée, car elle nécessite de comprendre un peu d'histoire.
RFC 1035 initialement appelé pour une limite de 512 octets afin d'éviter la fragmentation UDP. Les datagrammes UDP fragmentés et TCP ont été choisis comme options de dernier recours afin de minimiser la surcharge des transactions DNS. Les transferts de zone utilisent toujours TCP, car les transferts de zone occupent> 512 octets par (ce serait un gaspillage de bande passante de commencer par UDP)
La nouvelle tentative de TCP sur la troncature est largement prise en charge car elle est spécifiée dans RFC 112 depuis 1989.
EDNS (0) est défini par RFC 6891 (2013), et avant cela existait en tant que norme proposée datant de 1999 . Il définit un mécanisme permettant aux clients et aux serveurs de négocier des tailles UDP supérieures à 512. En raison de la nouveauté d'EDNS (0), de nombreuses appliances matérielles émettent des hypothèses sur la structure des paquets DNS qui entraînent l'élimination des paquets conformes. La raison la plus fréquente est l'hypothèse que les messages DNS de plus de 512 octets ne sont pas valides, mais c'est l'un parmi plusieurs.
Si nous décomposons cela en comportements observés:
- Les requêtes DNS généralement commencent en UDP, à moins que l'on ne sache à l'avance que la réponse sera trop importante pour commencer. (transferts de zone)
- La réponse mai déclenche un TCP réessayez dans le client si une réponse tronquée est vue. Ceci est assez bien supporté.
- Une réponse UDP supérieure à 512 octets peut-être s'affiche si le client utilise EDNS (0) pour publier une charge utile plus importante, et le serveur de réception le prend en charge. Cela ne se produira que si le matériel assis entre les deux n'interfère pas et entraîne un paquet abandonné ou mutilé.
- Le client peut-être choisit de réessayer une requête EDNS (0) avec une charge utile publiée plus petite si aucune réponse n'est vue, mais les détails varient selon les implémentations.
- Il est important de noter que la réponse qui parvient finalement à passer peut être trop grande pour tenir dans la taille demandée, ce qui entraîne le comportement n ° 2 ci-dessus. (ye olde TCP réessayez)
- Le côté client mai choisissez de vous souvenir de la taille qui a finalement abouti à un succès. Cela lui permet d'éviter de gaspiller des requêtes inutiles en le testant à nouveau. Sinon, cela serait tout à fait inutile, surtout si le résultat final exigeait TCP fallback.
Vous devez également garder à l'esprit que la RFC 7766 permet la réutilisation des connexions via TCP , et il est possible de rencontrer un pipelining de requête sur TCP dans la nature. Certains outils ne détecte pas les requêtes DNS au-delà de la première vue dans une session TCP, dnscap en étant un exemple).
Il y a RFC 7766, Transport DNS sur TCP - Exigences d'implémentation.
- Introduction
La plupart des transactions DNS [ RFC1034 ] ont lieu sur UDP [ RFC768 ]. TCP [ RFC79 ] est toujours utilisé pour les transferts de zone complets (en utilisant AXFR) et est souvent utilisé pour les messages dont la taille dépasse la limite originale de 512 octets du protocole DNS. Le déploiement croissant de la sécurité DNS (DNSSEC) et IPv6 a augmenté la taille des réponses et donc l'utilisation de TCP. Le besoin d'une utilisation accrue de TCP a également été motivé par la protection qu'il offre contre l'usurpation d'adresse et donc l'exploitation du DNS dans les attaques par réflexion/amplification. Il est maintenant largement utilisé dans la limitation du taux de réponse [ RRL1 ] [ RRL2 ]. De plus, des travaux récents sur des solutions de confidentialité DNS telles que [ DNS-over-TLS ] sont une autre motivation pour revoir les exigences DNS-over-TCP.
Section 6.1.3.2 de [RFC1123] indique:
DNS resolvers and recursive servers MUST support UDP, and SHOULD support TCP, for sending (non-zone-transfer) queries.Cependant, certains implémenteurs ont pris le texte cité ci-dessus pour signifier que la prise en charge de TCP est une fonctionnalité facultative du protocole DNS.
La majorité des opérateurs de serveur DNS prennent déjà en charge TCP et la configuration par défaut de la plupart des implémentations logicielles consiste à prendre en charge TCP. Le principal public visé par ce document est les implémenteurs dont la prise en charge limitée de TCP limite l'interopérabilité et entrave le déploiement de nouvelles fonctionnalités DNS.
Ce document met donc à jour les spécifications principales du protocole DNS de telle sorte que la prise en charge de TCP est désormais une partie OBLIGATOIRE d'une mise en œuvre complète du protocole DNS.
Il existe plusieurs avantages et inconvénients à l'utilisation accrue de TCP (voir Annexe A ) ainsi que les détails de mise en œuvre qui doivent être pris en compte. Ce document résout ces problèmes et présente TCP comme une alternative de transport valide pour DNS. Il étend le contenu de [ RFC5966 ], avec des considérations supplémentaires et des enseignements tirés de la recherche, des développements et de la mise en œuvre de TCP dans DNS et dans d'autres protocoles Internet.
Bien que ce document n'impose aucune exigence spécifique aux opérateurs de serveurs DNS, il offre quelques suggestions aux opérateurs pour garantir que la prise en charge de TCP sur leurs serveurs et réseau est optimale. Il convient de noter que l'échec de la prise en charge de TCP (ou le blocage de DNS sur TCP au niveau de la couche réseau) entraînera probablement un échec de résolution et/ou des délais d'expiration au niveau de l'application.
Vous ne devez filtrer TCP/53 dans aucune direction. Par exemple, les requêtes nsupdate peuvent utiliser TCP dès que la demande est trop importante (ce qui peut arriver rapidement). Vous devez donc laisser UDP et TCP pour le port 53 (en IPv4 et V6!) circule dans toutes les directions.
De plus, il y a de plus en plus de travail vers DNS sur TLS, donc TCP sera nécessaire dans les deux sens. Voir RFC7858.