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.
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/
