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


33

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.


2
Paging @Alnitak, nous discutons de votre bébé. :)
Andrew B

Comment puis-je forcer la requête DNS par défaut à fonctionner en mode TCP? . Bien que sous OS X / macOS q / a avec certains mods, il fonctionne également pour Linux / Windows.
klanomath

Bien sûr, de nos jours avec DNS sur HTTPS et DNS sur TLS et bientôt DNS sur QUIC ...
Patrick Mevzek

Pourquoi ne pas rediriger toutes les requêtes DNS vers un (des) serveur (s) DNS de votre choix?
Craig Hicks

Réponses:


38

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


1
Merci George, des choses vraiment utiles! Donc, pour clarifier rapidement votre première phrase, un paquet UDP ne peut contenir que 512 octets, n'est-ce pas? Donc, si une requête DNS était supérieure à 512, ne commencerait-il pas via TCP dès la sortie de la porte? J'ai essayé de le tester moi-même en exécutant Wireshark et en utilisant nslookup pour résoudre des domaines volumineux, mais cela semble m'empêcher d'essayer des domaines de plus de 200 caractères (pas le nombre exact, mais le fait est que je ne pouvais pas tester complètement ce scénario). .
Caderade

3
Ce n'est pas la "requête" mais la "réponse" qui serait supérieure à 512 octets et le client ne saurait pas ce que serait la "réponse".
AbraCadaver

7
@Caderade Oui, vous avez raison de dire qu'il peut s'agir de TCP ou d'UDP. Cependant, seuls les transferts de zone commenceront par TCP. Les requêtes client seront au format UDP, à moins qu’elles ne reçoivent une réponse du serveur sur lequel le bit truncate est défini. Puis peut alors utiliser TCP.
AbraCadaver

1
Les clients peuvent-ils utiliser TCP pour les petites réponses de toute façon?
Mehrdad

2
"Un paquet UDP ne peut contenir que 512 octets" Non, c'est l'hypothèse selon laquelle la mémoire tampon du client ne peut contenir que 512 octets, ce qui entraîne le comportement des serveurs de cette façon. Les serveurs peuvent être avertis d'un tampon plus long via EDNS.
Bryan

28

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.


Une des raisons pour laquelle le bit de troncature est défini est la limitation du taux de réponse (RRL). En tant que technique d’atténuation de l’amplification DNS, le serveur peut envoyer des paquets tronqués pour faire basculer les clients performants sur TCP, empêchant ainsi les réponses aux paquets d’adresses factices.
Edheldil

Réutilisation de la connexion: apprenez donc à votre résolveur de demander d'abord à google.com, avant qu'il ne demande scantycladladies.com, alors dnscap ne le remarquera pas. ;-)
Lenne

6

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.


2
Hey Ron - En fait, j’avais lu cette RFC avant de la publier, mais par exemple, si vous regardez dans le premier paragraphe, il semble insister sur le fait que TCP est nécessaire pour prendre en charge des réponses plus importantes - "Le déploiement croissant de DNS Security (DNSSEC) et IPv6 a augmenté la taille des réponses et donc l’utilisation de TCP ". Encore une fois, ma question portait sur les requêtes, mais merci quand même.
Caderade

4
La RFC indique clairement que le protocole TCP doit être pris en charge pour DNS et décrit l'utilisation de TCP par les clients. Par exemple, " Les clients utilisant TCP pour DNS doivent toujours être prêts à rétablir les connexions ou à réessayer les requêtes en attente. "
Ron Maupin

Bon point. Je dirais que ce commentaire a été réellement utile étant donné la clarté accrue. Ce que je veux dire, c’est que j’ai effectivement lu le RFC et que ce n’était toujours pas clair pour moi que les requêtes pouvaient commencer par utiliser le protocole TCP. Par conséquent, lorsque vous envoyez simplement le RFC pour obtenir une réponse, même comique, ce n’est pas vraiment utile. Les requêtes vont sur UDP et si la réponse est trop grande, le serveur DNS informe le client qu'il doit recommencer l'opération et l'exécuter via TCP. J'ai donc pensé que je répondrais toujours à l'exigence initiale car j'aurais capturé la demande initiale. Quoi qu'il en soit, j'apprécie votre contribution.
Caderade

1
Le INTERNET STANDARDRFC est tools.ietf.org/html/rfc1034 . Vous citez un PROPOSED STANDARDpour requérir TCP.
AbraCadaver

3
Il s’agit d’un RFC Standards Track qui a mis à jour un précédent RFC sur la même chose. Cette réponse ici sur Server Fault explique de telles choses. Même dans le document que vous référencez, il est indiqué " Dans Internet, les requêtes sont acheminées dans des datagrammes UDP ou via des connexions TCP. " La RFC 7766 explique clairement que TCP est une partie obligatoire, plutôt que facultative, du DNS.
Ron Maupin

3

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.


question n'a rien à voir avec le filtrage, et votre réponse n'ajoute rien par rapport aux autres réponses
Bryan

@ Bryan merci pour votre commentaire très utile et utile!
Patrick Mevzek

@PatrickMevzek Compris - ce que j'essayais de dire, c'est que nous autorisons uniquement le trafic vers des adresses IP spécifiques au-delà de notre périmètre sur le port 53 (TCP et UDP sont autorisés).
Caderade
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.