Сокращение Чрезмерных запросов DNS вызывается CDN
Возможно, ядро действительно исчерпывало энтропию. Это может произойти, по крайней мере, с Cyrus сервер IMAP, если он не настроен для использования/dev/urandom в качестве его источника случайности и если сервер не может генерировать достаточно "реальной" случайности к/dev/random. Ваши признаки соответствуют тем, я встретился несколько лет назад.
Для проверки, если это так, на Вас позволить
watch -n1 'cat /proc/sys/kernel/random/entropy_avail'
или
while true; do cat /proc/sys/kernel/random/entropy_avail >>/somepath/available_entropy.txt; sleep 1; done
выполненный и видят, спадает ли доступная энтропия постоянно, или около 0 во время IMAP зависают. В случае, если это происходит, программное обеспечение сервера IMAP ожидает новой случайности.
Один способ получить больше энтропии состоит в том, чтобы установить rngd в случае хинду, который средства появляются rng-инструменты и затем запуск rngd (Сборочный Демон Случайного числа). Это сгребает полуслучайность от/dev/urandom до/dev/random, если реальная случайность также исчерпывает ресурсы.
Обязательное предупреждение: в über-безопасных-средах это не то, что Вы хотите.
Основная причина слишком большого количества DNS-запросов - слишком низкие TTL. Ваши низкие, но не безумно низкие. (Я видел 60 и 1 как TTL в производственных системах.)
digitaldawn.net. 1800 IN A 109.73.163.166
www.digitaldawn.net. 3600 IN A 208.94.146.71
www.digitaldawn.net. 3600 IN A 208.94.146.70
www.digitaldawn.net. 3600 IN A 208.94.146.80
www.digitaldawn.net. 3600 IN A 208.94.146.81
cdn.digitaldawn.net. 1800 IN CNAME wpc.7b5c.edgecastcdn.net.
wpc.7b5c.edgecastcdn.net. 3600 IN CNAME gs1.wpc.edgecastcdn.net.
gs1.wpc.edgecastcdn.net. 14400 IN A 93.184.221.133
Если вы не меняете IP-адрес, на который указывают эти домены чаще, чем один раз в день, вам будет лучше изменить TTL на что-то вроде 86400 ( 24 часа). Вы можете подняться выше, если можете быть уверены в том, что у вас есть хотя бы период времени в TTL предварительного убывания, когда вам может потребоваться изменить IP-адрес.
Для субдомена cdn.digitladawn.net , даже если вы установите TTL равным 86400, только эта строка в приведенном выше выводе будет кэшироваться на 24 часа. Если ответ wpc.7b5c.edgecastcdn.net изменится, все клиенты должны были получить новое значение максимум через один час (пока игнорируем те DNS-серверы, которые игнорируют ваши TTL).
Две другие причины слишком большого количества DNS-запросов, которые я видел, - это слишком много клиентов (скажем, , тысячи пограничных серверов CDN, которые все атакуют ваши официальные серверы имен) или один некорректно работающий клиент (возможно, скрипт на вашем собственном сервере), который выполняет поиск десятки раз в секунду. Примером этого может быть обратный прокси-сервер, который использует backend.digitaldawn.net в качестве своего восходящего сервера и делает DNS-запрос для этого домена для каждого HTTP-запроса, который он должен проксировать. Эту проблему может решить добавление кэширования DNS на этот сервер или запуск собственного полномочного сервера имен в производственной среде.