Bonjour à tous, un rapide (promis quand j'ai commencé à écrire je pensais vraiment que ça allait l'être) partage d'expérience suite à un problème lors de l'usage de dig avec son option "+trace". Comme chacun le sait, celle-ci permet de dérouler l'algorithme récursif de résolution d'un fqdn en partant des serveurs racines. Pour une obscure raison je devais hier soir faire un peu de debug dns. J'utilisais donc les dites commandes et options quand oh malheur j'obtenais: $dig +trace machine.domain.tld
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> +trace machine.domain.tld ;; global options: +cmd ;; Received 12 bytes from ip.srv.dns.recursif#53(ip.srv.dns.recursif) in X ms
Ce qui est un peu léger et ne m'aidait guère. Pour comparaison, je testais sur un réseau dont je gère la résolution dns récursive et la même commande me donnait le résultat attendu. Après quelques recherches, il apparaît que dig demande au serveur dns courant de le renseigner quand aux serveurs racines. Il fait ceci en plaçant le bit "recursion desired" ( rfc 1035 - 4.1.1. Header section format) à 0. Ceci parait logique vu que l'on souhaite interroger les valeurs en cache du serveur. Visiblement certains fai (testé chez "libre", et en 3G chez "mandarine") ne souhaitent pas répondre à ce type d'interrogations, on le démontre simplement en comparant: dig +recurse NS . (+recurse est mis par défaut, je suis juste explicite ici) vs dig +norecurse NS .
Je viens de lire attentivement le manuel de dig et il ne me semble pas possible de faire en sorte que la première interrogation se fasse avec le flag rd à 1 ou d'utiliser un fichier. Le bug debian que j'ai donc ouvert: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712747
Autre point, pourquoi diable nos fai interdisent-ils ce type de requêtes ? Certe le fait d'arriver sur un recursif avec rd à 0 peut sembler suspect, et que c'est le comportement par défaut d'unbound: http://www.unbound.net/pipermail/unbound-users/2010-November/001489.html le "allow_snoop" permettant des "malicious acts" (http://www.unbound.net)/documentation/unbound.conf.html): consulter le cache du serveur pour essayer de l'empoisonner au bon moment je suppose ? Ce fonctionnement ne protège pas contre l'attaque par amplification dns décrite dans cet article http://www.bortzmeyer.org/dns-attaque-ns-point.html.
Votre avis ? Est-ce légitime ? Une réaction abusive aux soucis actuels de ddos par amplification dns (tout ce qui est pas propre-mainstream-qui-a-une-tete-qui-me-revient-pas sur mes dns je jette) ? Luc.