Est-il vrai qu'un serveur de noms doit répondre à des requêtes via TCP?

23

Je suis en train de mettre en place une surveillance des serveurs DNS de plusieurs gros hébergeurs Web. Mon objectif est de comparer les temps de réponse de leurs serveurs DNS en suivant leur réponse au ping.

Dans le processus, j'ai découvert que les serveurs de noms Bluehost ne répondent pas au ping. J'ai essayé d'obtenir plus d'informations en exécutant Pingdom DNS Check sur bluehost.com et cela a produit l'erreur suivante:

Le serveur de noms ns1.bluehost.com (74.220.195.31) ne répond pas aux requêtes via TCP.

Le serveur de noms n'a pas pu répondre aux requêtes envoyées via TCP. Cela est probablement dû au fait que le serveur de noms n'est pas correctement configuré ou à un filtrage mal configuré dans un pare-feu. C'est une idée fausse assez courante que DNS n'a pas besoin de TCP à moins qu'il ne fournisse des transferts de zone - peut-être que l'administrateur du serveur de noms n'est pas conscient que TCP est généralement une exigence.

Je voudrais savoir ce qui suit:

  • Dans quelle mesure la déclaration ci-dessus est-elle vraie?
  • Quelles sont les implications d'un serveur de noms ne répondant pas aux requêtes via TCP?
domain-name-system nameserver Taras Mankovski
la source

Réponses:

47

Le texte de diagnostic de Pingdom est exactement correct. TCP n'est pas seulement pour les transferts de zone.

Les implémentations de serveur DNS sont désormais "requises" (dans la mesure où tout RFC requiert quoi que ce soit) pour prendre en charge TCP, conformément à la RFC 5966 , "Transport DNS sur TCP - Exigences d'implémentation".

Notez qu'il s'agit d'une exigence sur la mise en œuvre du logiciel serveur, elle ne s'applique pas strictement au fonctionnement d'un serveur - la pratique opérationnelle n'est pas couverte.

Cela dit, si vos serveurs DNS particuliers ne sont pas configurés pour prendre en charge TCP, ou s'il est bloqué, l'effet à plus long terme sera une incapacité à prendre en charge DNSSEC correctement. De même, toutes les autres données DNS qui provoquent des réponses dépassant 512 octets peuvent être bloquées.

avertissement: j'ai écrit ce RFC.

EDIT RFC 5966 a été remplacé par RFC 7766

Alnitak
la source
RE: pratique opérationnelle, celui qui déteste DNSSEC pourrait simplement désactiver TCP et le déposer sur le pare-feu pour faire bonne mesure. Sans surprise, il y a des conséquences. Aucune prise en charge d'EDNS0 sur deux points d'extrémité ne peut forcer les appareils entre eux à ne pas interférer d'une manière ou d'une autre. (fragmentation, fausse signalisation par d'anciens pare-feu, etc.) Si vous avez de grands enregistrements DNS sur votre serveur d'authentification (TXT gonflé), TCP sera requis si vous ne souhaitez pas exclure un segment de votre audience. De même, sa désactivation sur un serveur récursif vous isole des réponses DNS dont votre cluster de messagerie peut avoir besoin pour traiter le spam.
Andrew B
3

il devrait prendre en charge TCP et UDP - le TCP est pour les réponses de tailles> 512 octets (ce qui inclurait les transferts de zone) (selon les trucs que j'ai lus, de toute façon. J'active généralement TCP et UDP pour les NS que j'exécute ...)

Mark Regensberg
la source
-2

Il est bon de savoir ce que disent les RFC sur le sujet, et nous avons déjà une bonne réponse faisant autorité à ce sujet, mais à des fins pratiques, je trouve les conseils du professeur Daniel J. Bernstein, PhD, auteur de DJBDNS, très divertissants.

http://cr.yp.to/djbdns/tcp.html#why (2003-01-16)

Quand les requêtes TCP sont-elles envoyées?

Si vous êtes dans l'une des situations suivantes, vous devez configurer votre serveur DNS pour répondre aux requêtes TCP:

  • Vous souhaitez publier des jeux d'enregistrements supérieurs à 512 octets. (C'est presque toujours une erreur.)
  • Vous souhaitez autoriser les transferts de zone sortants, par exemple vers un serveur tiers.
  • Un serveur parent refuse de vous déléguer un nom jusqu'à ce que vous configuriez le service TCP.

Si vous n'êtes dans aucune de ces situations, vous n'avez pas besoin de fournir de service TCP et vous ne devez pas le configurer. DNS-over-TCP est beaucoup plus lent que DNS-over-UDP et est intrinsèquement beaucoup plus vulnérable aux attaques par déni de service. (Cela s'applique également à BIND.)

Notez qu'il omet une mention explicite de DNSSEC; la raison en est que, selon DJB, DNSSEC relève de la catégorie "toujours une erreur". Voir https://cr.yp.to/djbdns/forgery.html pour plus de détails. DJB a une norme alternative, appelée DNSCurve - http://dnscurve.org/ - qui a déjà été adoptée indépendamment par certains fournisseurs (comme OpenDNS). D'intérêt: /security/45770/if-dnssec-is-so-questionable-why-is-it-ahead-of-dnscurve-in-adoption .

Notez que si la documentation ci-dessus sur la configuration de DJBDNS est une indication de ses fonctionnalités, il semble qu'elle ne supporte que AXFR pour TCP. Comme de nombreux fournisseurs utilisent encore DJBDNS, il est donc peu probable qu'ils prennent en charge DNS sur TCP sans efforts supplémentaires.

PS Notez que DJB pratique en fait ce qu'il prêche. Ses propres serveurs, (1), exécutent DNSCurve, (2), ne répondent pas correctement à TCP. Seul le +notcpréussirait (ce qui est par défaut):

% dig +trace @ordns.he.net +notcp cr.yp.to | tail
yp.to.                  86400   IN      NS      uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to.
yp.to.                  86400   IN      NS      uz5jmyqz3gz2bhnuzg0rr0cml9u8pntyhn2jhtqn04yt3sm5h235c1.yp.to.
;; Received 300 bytes from 216.74.32.100#53(tonic.to) in 151 ms

cr.yp.to.               600     IN      A       131.155.70.11
cr.yp.to.               600     IN      A       131.155.70.13
yp.to.                  3600    IN      NS      uz5jmyqz3gz2bhnuzg0rr0cml9u8pntyhn2jhtqn04yt3sm5h235c1.yp.to.
yp.to.                  3600    IN      NS      uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.yp.to.
;; Received 244 bytes from 131.155.70.13#53(uz5jmyqz3gz2bhnuzg0rr0cml9u8pntyhn2jhtqn04yt3sm5h235c1.yp.to) in 14 ms

, alors qu'un +tcpéchouerait (apparemment avec un message d'erreur différent, selon lequel de ses serveurs sera sélectionné):

% dig +trace @ordns.he.net +tcp cr.yp.to | tail
yp.to.                  86400   IN      NS      uz5hjgptn63q5qlch6xlrw63tf6vhvvu6mjwn0s31buw1lhmlk14kd.ns.yp.to.
;; Received 300 bytes from 216.74.32.100#53(tonic.to) in 150 ms

;; Connection to 131.155.71.143#53(uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to) for cr.yp.to failed: connection refused.
;; communications error to 131.155.70.13#53: end of file
;; Connection to 131.155.71.143#53(uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to) for cr.yp.to failed: connection refused.
;; communications error to 131.155.70.13#53: end of file
;; Connection to 131.155.71.143#53(uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to) for cr.yp.to failed: connection refused.
;; communications error to 131.193.32.147#53: end of file
;; connection timed out; no servers could be reached
cnst
la source
2
Votre numéro DJB fanboi devient plutôt fatigant. La communauté DNS a choisi DNSSEC, et une grande partie de la littérature sur DNSCurve confond complètement les exigences orthogonales d' authenticité des données et de chiffrement des données . IMNSHO, l'essentiel de votre réponse ne contribue en rien à cette question.
Alnitak
@Alnitak, votre insistance sur le fait que TCP est requis pour DNS ne fait pas que ce soit une exigence réelle pour DNS. De toute évidence, de nombreuses personnes s'exécutent sans TCP et ne rencontrent AUCUN problème de disponibilité de leurs propres sites Web. Pourtant, vous continuez à promouvoir la désinformation et le FUD.
2017
2
Ce document date-il vraiment de 2003? Comment pouvez-vous affirmer avec un visage impassible qu'il est toujours d'actualité en 2017?
Michael Hampton
1
@MichaelHampton, oui, de tout cœur et absolument. Certaines choses ne changent pas, et DJB peut être un connard, mais il est plutôt intelligent à cela. Tous les arguments qu'il présente sont de nature philosophique et ne changent pas comme le fait la technologie. Pendant ce temps, (1), pourquoi est-il si difficile à croire, (2), pourquoi se lier à des RFC encore plus anciens faits avec un visage droit, et sans que vous soyez un hypocrite, (3), quels contre-arguments réels avez-vous à part Un rendez-vous"? Les gens continuent de dire que son chemin a des problèmes d'interopérabilité, mais les arguments mêmes proposés (par exemple, le courrier rebondi), il a démystifié en 2003!
2017 à 2h58
-5

TCP n'est requis que et n'est généralement utilisé que lorsqu'une réponse longue est requise. Il peut y avoir des impacts négatifs. Les transferts de zone sont effectués sur TCP car ils sont volumineux et doivent être fiables. Ne pas autoriser TCP à partir de serveurs non fiables est un moyen de garantir que seules de petites réponses sont données.

Avec l'introduction des réponses DNS signées, il a été nécessaire de relâcher la limite de 512 octets aux réponses UPD. EDNS0 fournit le mécanisme pour des réponses UDP plus longues. Le fait de ne pas autoriser DNS sur TCP risque fortement de briser une implémentation DNS sécurisée.

Il est parfaitement possible d'exécuter un serveur DNS qui n'a que le port UDP 53 ouvert à Internet. L'accès TCP aux homologues DNS est requis, mais il s'agit d'une petite liste d'hôtes.

Il existe une nouvelle RFC596 qui nécessite désormais TCP pour une implémentation DNS complète. Ceci est destiné aux implémenteurs. Les documents ne concernent pas spécifiquement les opérateurs, mais avertissent que l'interdiction de TCP peut entraîner un certain nombre de scénarios de défaillance. Il détaille une grande variété d'échecs qui peuvent survenir si DNS sur TCP n'est pas pris en charge.

Il y a eu des discussions sur l'utilisation de TCP pour empêcher les attaques d'amplification DNS. TCP a ses propres risques de déni de service, mais la distribution est plus difficile.

BillThor
la source
DNSSEC n'a pas relâché la limite, EDNS0 l'a fait, en 1999 (voir RFC 2671).
Alnitak
Non, comme expliqué par Alnitak, TCP est requis dans la plupart des cas (sauf si vous pouvez être absolument certain que vous n'aurez jamais de réponse> 512 octets, ce que vous ne savez généralement pas à l'avance)
bortzmeyer
J'ai réussi à exécuter DNS via un pare-feu autorisant uniquement UDP. À moins de configurations pathalogiques, les recherches d'adresse comporteront moins de 512 caractères. J'ai vu des références selon lesquelles les chemins DNS sont limités à 256 caractères. Des preuves dans la base de données de mon serveur de messagerie suggèrent que les chemins DNS du serveur dépassent rarement 100 caractères, et les sites qui ont plusieurs noms renvoyés par un enregistrement PTR retournent rarement plus de 256 caractères. Toutes ces réponses s'exécuteraient sur UDP. Quelqu'un at-il un cas raisonnable qui s'exécute près de 512 caractères sans DNSSEC ou un transfert de zone.
BillThor
Concernant DNSSEC, je n'ai pas vérifié RFC pour les tailles étendues, mais les seules références que j'ai vues pour utiliser des tailles de paquets étendues sur UDP sont ben DSNSEC.
BillThor
L'un des grands fournisseurs de contenu s'est décollé il y a quelques années en ajoutant tant d'enregistrements A pour l'une de ses fermes Web qu'il dépassait 512 octets. Cela a causé de vrais problèmes d'interopérabilité.
Alnitak