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

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?

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

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 ...)

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

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.