[FRsAG] Les petits secrets de dig

Bégault Luc luc at begault.net
Mer 19 Juin 11:41:44 CEST 2013


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.


More information about the FRsAG mailing list