Catégories
Sysadmin

Queryperf DNS tir de performance et stress test

Queryperf pour la mesure de performance des serveurs DNS afin d’évaluer la capacité de réponse des services de nom de domaine.

Afin de valider des changements d’architecture DNS ou d’évaluer un choix de logiciel ou encore la capacité d’un serveur au travers de son architecture réseau, il faut pouvoir tester pour connaître les limites d’exploitation des services.

Bind Queryperf

En cherchant les outils susceptibles de pouvoir réaliser des tirs de performances DNS, il n’existe globalement que JMeter qui est capable d’intégrer un tel test. Néanmoins nous l’avons écarté car nous souhaitons pouvoir réaliser les tests sur chaque serveur DNS, puis rejouer ces tests en s’éloignant du serveur jusqu’à si possible une machine neutre quelconque sur Internet.

Si le web est rempli de testeur de performance et d’efficacité DNS, c’est la plupart du temps pour tester le temps de réponse de divers resolvers DNS pour savoir si celui de son FAI est plus ou moins performant par rapport à d’autres. Cela sort donc du sujet initial.

Nous avons trouvé l’outil simple et efficace dans les contributions de Bind. En effet un petit utilitaire nommé queryperf permet de remplir ces tests. Il prend en paramètre un fichier texte avec les requêtes qu’il doit effectuer. Ce fichier de scénarios va être utile pour rejouer exactement les mêmes tests depuis plusieurs endroits et ainsi détecter tout goulot d’étranglement ou anomalie. On va aussi pouvoir introduire plusieurs hypothèse comme interroger des enregistrements des zones gérées par le serveur DNS comme interroger des zones ou des enregistrements qui n’existent pas sur le serveur et voir comment il se comporte.

Installation Bind queryperf

Queryperf sur Debian / Ubuntu est très simple à compiler, on récupère les sources de Bind et on compile l’utilitaire.

Sur la version 9.7.3 queryperf ne sait pas gérer les enregistrements SPF et DS ce qui cause des erreurs du type : « Query type not understood: SPF » et « Query type not understood: DS ». Aussi voici un patch à appliquer avant de lancer la compilation.

--- queryperf.c.orig 2013-02-14 10:13:40.719397645 +0100
 +++ queryperf.c 2013-02-14 10:15:42.027403509 +0100
 @@ -85,13 +85,13 @@
 #define QTYPE_STRINGS { 
 "A", "NS", "MD", "MF", "CNAME", "SOA", "MB", "MG", 
 "MR", "NULL", "WKS", "PTR", "HINFO", "MINFO", "MX", "TXT", 
 - "AAAA", "SRV", "NAPTR", "A6", "AXFR", "MAILB", "MAILA", "*", "ANY" 
 + "AAAA", "SRV", "NAPTR", "A6", "DS", "SPF", "AXFR", "MAILB", "MAILA", "*", "ANY" 
 }
#define QTYPE_CODES { 
 1, 2, 3, 4, 5, 6, 7, 8, 
 9, 10, 11, 12, 13, 14, 15, 16, 
 - 28, 33, 35, 38, 252, 253, 254, 255, 255 
 + 28, 33, 35, 38, 43, 99, 252, 253, 254, 255, 255 
 }

 apt-get source bind9
 cd bind9-9.7.3.dfsg/contrib/queryperf
 ./configure && make
 

Rejouer du trafic DNS réel

Lorsque l’on fait des tirs de performances, rien de plus intéressant que de rejouer du trafic réel. Pour cela il faut capturer le trafic sur un laps de temps, ce qui nous donnera un fichier des requêtes demandées à un serveur DNS, puis on prépare d’après ces requêtes le fichier de test de scénarios pour queryperf.

Rien de plus simple avec un Bind suivi en métrologie, puisque vous aurez sans doute déjà activé la journalisation des requêtes sur une certaine période afin d’en tirer des statistiques. Pour rappel voilà ce qu’il faut déclarer dans votre /etc/bind/named.conf.options


 logging {
 channel query {
 file "/var/run/named/query.log" versions 2 size 1m;
 print-time yes;
 severity info;
 };
 category queries { query; };
 };
 

Les lignes de log sont sous la forme :

 # pour de l'ipv4
14-Feb-2013 09:54:30.266 client 192.93.X.X#31792: query: ns-02.digdeo.eu IN A -EDC (X.X.X.X)
 # pour de l'ipv6
14-Feb-2013 09:54:26.971 client 2001:X:X:X:X:X:X:X#25495: query: ns-01.digdeo.com IN AAAA -EDC (2001:X:X:X::X)

On va donc extraire les informations qui nous intéresse. Pour avoir un maximum de requêtes nous allons prendre tous les fichiers query.log.


 cat /var/run/query.log* | awk '{ print $6, $8 }' > liste
 

Le résultat nous donnera donc les enregistrements demandés et leurs type DNS.


 ns-01.digdeo.com A
 ns-01.digdeo.com AAAA
 

Il ne reste plus qu’à lancer le tir de performance à partir de ce fichier. Pour commencer nous faisons le test en local ou sur une machine proche sans élément actif entre les deux afin d’enlever toute contrainte réseau / firewall / latence. Ainsi nous pourrons évaluer les performances brutes du serveur DNS.

 ./queryperf -d list -s 127.0.0.1 -t 1Statistics:Parse input file: once
 Ended due to: reaching end of fileQueries sent: 425682 queries
 Queries completed: 424460 queries
 Queries lost: 1222 queries
 Queries delayed(?): 0 queries>RTT max: 0.966948 sec
 RTT min: 0.000004 sec
 RTT average: 0.000207 sec
 RTT std deviation: 0.001559 sec
 RTT out of range: 0 queries
 Percentage completed: 99.71%
 Percentage lost: 0.29%
 Started at: Thu Feb 14 10:27:18 2013
 Finished at: Thu Feb 14 10:28:26 2013
 Ran for: 67.791860 seconds
 Queries per second: 6261.223693 qps

Ce premier tir de performance met en évidence le souci des anciens domaines hébergés sur ce serveur dns qui ont été déplacés et donc des requêtes sont toujours effectuées par certains clients DNS. Cela cause des erreurs du type : « [Timeout] Query timed out: msg id 31235 » ou bien dans le syslog « named[1519]: error (unexpected RCODE REFUSED) resolving » et « named[19503]: lame server resolving ». Ces erreurs sont normales car nous sommes en présence d’un DNS autoritaire et non d’un DNS récursif. En filtrant les quelques domaines posant des soucis, les résultats sont bien meilleurs puisque tous les threads de queryperf n’ont pas rencontré d’obstacle particulier.


Statistics:
Parse input file: once
 Ended due to: reaching end of file
Queries sent: 424458 queries
 Queries completed: 424458 queries
 Queries lost: 0 queries
 Queries delayed(?): 0 queries
RTT max: 0.033989 sec
 RTT min: 0.000068 sec
 RTT average: 0.000524 sec
 RTT std deviation: 0.000271 sec
 RTT out of range: 0 queries
Percentage completed: 100.00%
 Percentage lost: 0.00%
Started at: Thu Feb 14 10:34:20 2013
 Finished at: Thu Feb 14 10:34:31 2013
 Ran for: 11.430219 seconds
Queries per second: 37134.721566 qps
37 mille requêtes par secondes pour 424458 requêtes DNS jouées en 11,4 secondes c'est déjà beaucoup mieux.

Test à distance

A présent vous pouvez vous éloigner au fur et à mesure de votre serveur DNS et voir si les résultats changent. Il se pourrait notamment que vous mettiez en évidence des limitations UDP sur certains équipements et/ou prestataires réseaux. Il convient notamment de voir avec vos prestataires comment peuvent être réalisé ce type de tests au travers de leurs architectures, car si ils n’ont pas de protection spécifiques cela pourrait occasionné des effets de bord.