Est-ce que les requêtes DNS voyagent toujours sur UDP?

J'ai passé un peu de temps à chercher ce sujet et je n'arrive pas à trouver une réponse exacte. Je suis donc assez confiant que ce n'est pas un doublon. Bien que ma question soit basée sur un besoin de sécurité, je pense que c'est toujours sans danger. demandez ici, mais laissez-moi savoir si je dois le déplacer la communauté de la sécurité.

Essentiellement, les requêtes DNS utilisent-elles déjà le protocole TCP (le cas échéant, quel scénario pourrait-il se produire)? Encore une fois, je ne parle que de requêtes. Est-il possible pour eux de voyager sur TCP? Si les domaines ne peuvent avoir qu'une longueur maximale de 253 octets et que les paquets UDP peuvent atteindre 512 octets, les requêtes ne seront-elles pas toujours envoyées en tant que UDP? Je ne pensais pas qu'une requête résolvable pouvait être assez grosse pour nécessiter l'utilisation de TCP. Si un serveur DNS reçoit une demande pour un domaine de plus de 253 octets, le serveur le laissera-t-il tomber / ne tentera-t-il pas de le résoudre? Je suis certain que j'ai fait de fausses hypothèses ici.

Dans certains cas, je collabore avec le groupe de sécurité pour intégrer des requêtes DNS à leur outil de surveillance de la sécurité. Pour diverses raisons, nous avons décidé de capturer ce trafic via une capture de paquets standard sur des serveurs DNS et des 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 sommes pas concernés par la capture des réponses DNS ou d’autres types de trafic, tels que les transferts de zone, car nous devons également limiter le plus possible le volume des journaux. En tant que tel, nous prévoyons de ne capturer que les requêtes DNS destinées au serveur DNS et envoyées via UDP. Pour plus de contexte (genre de champ de question rampant ici), il a maintenant été évoqué que nous pourrions avoir besoin d'étendre la sécurité ' ■ visibilité afin qu'ils puissent surveiller les activités telles que les canaux cachés fonctionnant sur DNS (ce qui présenterait également le besoin de capturer les réponses DNS, puis le trafic TCP). Mais même dans ce type de scénario, je pensais que tout trafic DNS sortant serait sous forme de recherches / requêtes, et que celles-ci seraient toujours via UDP, même si elles provenaient d'une source malveillante (en raison de mon raisonnement dans le premier paragraphe). Cela soulève donc quelques questions supplémentaires:

• Ne pourrions-nous pas au moins capturer la moitié de la conversation avec l'approche que j'ai décrite? Ou un client pourrait-il jamais envoyer du trafic DNS qui ne soit 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 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 via TCP?

Nous ne savons pas si cela est pertinent, mais nous limitons les requêtes DNS aux serveurs DNS autorisés et bloquons tout autre trafic sortant sur le port 53. Je suis définitivement un débutant. Je suis donc désolé si ma question n'est pas conforme et informez-moi. 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", ce qui entraînera une conversation TCP 53 facilitant l'envoi / la réception de l'intégralité de la requête. En outre, le serveur DNS se connecte au port 53, mais la requête elle-même provient d'un port aléatoire portant le 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

Par conséquent, si vous envisagez de surveiller de manière sécurisée les requêtes DNS de votre réseau, vous devez tenir compte de ce qui précède.

En ce qui concerne le trafic autre que de recherche, considérons que DNS utilise également les 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, en DDOS sur un serveur de noms principal afin qu'il soit trop occupé pour répondre à une demande secondaire demandant des enregistrements mis à jour. Le pirate informatique usurpe ensuite ce même primaire pour alimenter les enregistrements «empoisonnés» vers le secondaire, qui redirige les domaines DNS courants 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 d'adresses IP spécifiques.

SANS Institute Salle de lecture InfoSec | sans.org

Cela a commencé comme un commentaire sur la réponse de George, mais cela a pris du temps. La situation dans son ensemble est quelque peu compliquée, car elle nécessite une compréhension de l’histoire.

• La RFC 1035 appelait à l'origine à une limite de 512 octets afin d'éviter la fragmentation UDP. Les datagrammes UDP fragmentés et le protocole TCP ont été choisis en dernier recours afin de minimiser le temps système des transactions DNS. Les transferts de zone utilisent toujours TCP, du fait que les transferts de zone prennent> 512 octets par leur nature même. (commencer par UDP serait un gaspillage de bande passante)

• Les nouvelles tentatives TCP sur la troncature sont largement prises en charge car elles sont spécifiées dans la RFC 1123 depuis 1989.

• EDNS (0) est défini par la RFC 6891 (2013) et existait auparavant sous la forme d’une proposition de norme 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é de EDNS (0), de nombreuses appliances matérielles émettent des hypothèses sur la structure des paquets DNS qui entraînent leur élimination. La raison la plus fréquente est l'hypothèse selon laquelle les messages DNS de plus de 512 octets sont invalides, mais il s'agit d'un message parmi plusieurs.

Si nous divisons cela dans les comportements observés:

1. Les requêtes DNS commencent généralement par UDP, à moins que l’on sache à l’avance que la réponse sera trop volumineuse pour commencer. (transferts de zone)
2. La réponse peut déclencher une nouvelle tentative TCP dans le client si une réponse tronquée est vue. Ceci est assez bien pris en charge.
3. Une réponse UDP supérieure à 512 octets peut être affichée si le client a utilisé EDNS (0) pour annoncer une charge utile plus importante et que le serveur de réception la prend en charge. Cela ne se produira que si le matériel situé entre les deux n'interfère pas et entraîne la perte ou la destruction d'un paquet.
4. Le client peut choisir de relancer une requête EDNS (0) avec une charge utile annoncée plus petite si une réponse n'est pas vue, mais les détails varieront d'une implémentation à l'autre.
   • Il est important de noter que la réponse qui réussit peut être trop grande pour tenir dans la taille demandée, ce qui entraîne le comportement n ° 2 ci-dessus. (vous êtes vieux TCP réessayer)
   • Le client peut choisir de se souvenir de la taille qui a finalement abouti à un succès. Cela lui permet d’éviter de gaspiller des requêtes inutiles. Autrement, ce serait très inutile, surtout si le résultat final nécessitait un repli du TCP.

Vous devez également garder à l'esprit que la norme RFC 7766 permet la réutilisation de connexion sur TCP et qu'il est possible de rencontrer le traitement en différé des requêtes sur TCP dans la nature. Certains outils ne détectent pas les requêtes DNS au-delà de la première constatée dans une session TCP, dnscap en étant un exemple.

Il existe RFC 7766, Transport DNS sur TCP - Exigences d'implémentation .

1. introduction

La plupart des transactions DNS [ RFC1034 ] ont lieu sur UDP [ RFC768 ]. TCP [ RFC793 ] est toujours utilisé pour les transferts de zone complète (avec AXFR) et est souvent utilisé pour les messages dont la taille dépasse la limite de 512 octets d'origine du protocole DNS. Le déploiement croissant de DNS Security (DNSSEC) et IPv6 a entraîné une augmentation de la taille des réponses et donc de l'utilisation de TCP. La nécessité d’accroître l’utilisation de TCP est également motivée par la protection qu’il offre contre l’usurpation d’adresse et donc l’exploitation du DNS lors d’attaques de 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] est une autre motivation pour revenir sur les exigences de DNS sur TCP.

La section 6.1.3.2 de la [RFC1123] stipule:

  DNS resolvers and recursive servers MUST support UDP, and SHOULD
  support TCP, for sending (non-zone-transfer) queries.

Cependant, certains implémenteurs ont interprété le texte cité ci-dessus comme signifiant que la prise en charge de TCP est une fonctionnalité optionnelle 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. Les principaux destinataires de ce document sont les implémenteurs dont la prise en charge limitée de TCP restreint l'interopérabilité et empêche le déploiement de nouvelles fonctionnalités DNS.

Ce document met donc à jour les spécifications de protocole DNS principales de sorte que la prise en charge de TCP constitue désormais un élément OBLIGATOIRE d'une implémentation de protocole DNS complet.

L'utilisation accrue du protocole TCP (voir l' annexe A ) présente plusieurs avantages et inconvénients, ainsi que des détails de mise en œuvre qu'il convient de prendre en compte. Ce document traite de ces problèmes et présente TCP comme une alternative de transport valide pour DNS. Il étend le contenu de la [ RFC5966 ], avec des considérations supplémentaires et des leçons tirées de la recherche, des développements et de la mise en œuvre du protocole TCP dans le DNS et d'autres protocoles Internet.

Bien que ce document n'impose aucune exigence spécifique aux opérateurs de serveurs DNS, il offre néanmoins quelques suggestions aux opérateurs pour garantir que la prise en charge du protocole TCP sur leurs serveurs et leur réseau est optimale. Il convient de noter que la non 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 la résolution et / ou des délais d'attente au niveau de l'application.

Vous ne devez pas filtrer TCP / 53 dans aucune direction. Par exemple, les nsupdaterequêtes peuvent utiliser TCP dès que la requête est trop grosse (ce qui peut arriver rapidement). Vous devez donc laisser UDP et TCP pour le port 53 (dans IPv4 et V6!) S’écouler dans toutes les directions.

De plus, le travail sur DNS sur TLS est de plus en plus important, de sorte que TCP sera nécessaire dans les deux sens. Voir RFC7858.