Agregando las herramientas y sugerencias mencionadas, algunos comentarios
* Si vas a utilizar tráfico pre-generado, no hay nada mejor que las capturas ya hechas en la vida real (pueden ser PCAPs con el tcpreplay que mencionó Sebastian, o partir de los query-logs de un bind). Ojo que a veces no es lo mismo enviar todo el tráfico en una ráfaga, que en intérvalos con distintas aceleraciones.
* La tendencia estos últimos años sobre cómo medir capacidad de respuesta de QPS, generalmente apunta a que uno tenga un contador de paquetes de entrada y de salida (caso Knot y NSD en los links que ya te compartieron) pocas veces se mide la correctitud de las respuestas. Si vas a seguir ese camino, al menos intenta revisar que algunas de las respuestas sean coherentes (no es lo mismo preguntar por sólo NXDOMAINS, que por siempre el mismo nombre por ejemplo)
* Toma en cuenta que generar o emitir tráfico puede ser más costoso que lo que uno creería. Para ayudar a mejorar eso, piensa en un grupo de servidores haciendo el trabajo en paralelo, o utiliza una cantidad óptima de forks en un equipo más sobre-dimensionado que el mismo que vas a testear. Del difunto proyecto BIND10 se hizo una nueva version de queryperf, llamada queryperf++ que se comporta mucho mejor que la anterior y permite utilizar los forks mucho mejor:
https://github.com/jinmei/queryperfpp
* Ojo con entender y saber ubicar el cuello de botella tanto en el equipo medido, como en el punto de referencia de tráfico generado... a veces puede ser algún parámetro del kernel... otras veces el stack tcp... otras el mismo cable o un switch mal configurado (true story).
* Si realizas la prueba con distintos S.O. puede pasar que no tengas las mismas herramientas para poder medir el uso del equipo (por ejemplo una vez yo probé uno que era linux y otro freebsd)... para tener una idea de qué pasaba modifiqué un script en python para poder tener consistencia entre ambos:
https://github.com/mave007/scripts/blob/master/psutil-process-benchmark.py
Saludos!