Как я тестировал доступность доменов в интернете

Увидел вчера в интернетах любопытную задачу: человек хочет проверять домены на существование. Ну или на делегированность (или припаркованность). В общем формулировка задачи проста: берём очередной домен из списка и смотрим наличие для него записей NS. Если вдруг их нет - делаем отметку об этом.

Проста-то проста, но он хотел обходить список из трёх миллиардов доменов за сутки. Это значит, тридцать пять тысяч доменов в секунду. С этого места начинаются трудности:

1. Если предположить, что на один домен тратится в среднем триста байт входящего трафика, то за секунду подобная инсталляция должна потреблять десять мегабайт. Ну ладно, стомегабитные подключения сейчас не что-то необычное, но эти сто мегабит всегда должны быть ста мегабитами, а не «по вечерам канал сильно загружен».
2. Надо учитывать, что рекурсивный ресольвинг может иногда занимать по нескольку секунд на домен. То есть последовательная работа не подходит сразу и со всей очевидностью. Нужен параллельный процесс.

В общем, решил посмотреть, что за штука такая — perl mutithreading. Посмотрел.
Инсталляция: клиент на Core i5 - перловый скрипт, читающий список доменов из файла. Запросы посылает BIND'у, работающему на другой машине. Почему-то я пока считаю, что так оно должно работать быстрее. Хотя бы BIND будет делать кэширование TLD-серверов, чтобы не заморачиваться с этим в скрипте. Канал - 50 мегабит в секунду.

Результаты: си-ильно далеки от цели. Максимум, чего мне удалось добиться на некэшированном списке доменов (то есть при первом его проходе) — 110 доменов в секунду. И я бы не сказал, что какая-то часть стенда у меня сильно нагружена.

И вот интересно мне: сто доменов в секунду — это всё, что может выдать связка «один клиент — один кэширующий сервер с рекурсией», или можно выжать больше?