Днс перестает отвечать на запросы

1.0.0.127.dnsbugtest.1.0.0.127.in-addr.arpa это как бы тестовый запрос от клиента, чтобы что-то там проверить у DNS-сервера, вроде как не должен приводить к проблемам.

″after disabling EDNS″ это вобще нормальное явление, BIND не смог пообщаться с другим DNS-сервером на «расширенном» DNS-протоколе (EDNS) и отключил это расширение.

Вы лучше посмотрите tcpdump'ом что в проблемные моменты творится на 53 порту. Сообщения ″no more recursive clients: quota reached″ в логах нет?

Вы лучше посмотрите tcpdump'ом что в проблемные моменты творится на 53 порту. Сообщения ″no more recursive clients: quota reached″ в логах нет?

Эта проблема была, я поднял количество рекурсивных клиентов до 10к и она исчезла.Трафа там как ты понимаешь много , и проблема возникает спонтанно и потом только для отдельных сайтов .

″after disabling EDNS″ это вобще нормальное явление, BIND не смог пообщаться с другим DNS-сервером на «расширенном» DNS-протоколе (EDNS) и отключил это расширение.

стоит ли ее вообще включать или будет сразу переход на tcp ?

Не знаю, есть ли смысл совсем отключать EDNS, или в логах много подобных записей? Так, ничего страшного произойти не должно, ИМХО, большинство DNS-ответов входит в 512 байт старого протокола.

А ″rndc status″ в моменты затыков ничего интересного не сообщает?

Не знаю, есть ли смысл совсем отключать EDNS, или в логах много подобных записей? Так, ничего страшного произойти не должно, ИМХО, большинство DNS-ответов входит в 512 байт старого протокола.

Такого рода запросов много ,кроме того вот к пример возьмем один из них

./default.log:230988:20-May-2014 15:51:50.953 success resolving 'smtp.laposte.net/A' (in 'laposte.net'?) after^Cadvertised EDNS UDP packet size to 512 octets

При этом сам ответ по этому сайту ;; MSG SIZE rcvd: 186 дотягивает до 200 байт .

также сейчас я ночью поставил рестарт bind(благо он быстро перегружается ) и такого поведения больше не наблюдаю

rndc сейчас выдает следующее( особенно интересно количество рекурсивных клиентов ? )

 
 rndc status
version: 9.9.5 <id:f9b8a50e>
CPUs found: 1
worker threads: 1
UDP listeners per interface: 1
number of zones: 282
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is ON
recursive clients: 29/9900/10000
tcp clients: 0/100
server is up and running

При этом сам ответ по этому сайту ;; MSG SIZE rcvd: 186 дотягивает до 200 байт .

Да, пока имена короткие. Но, я не помню, а named что-нибудь пишет в логи, по поводу того, что udp не хватило и был использован tcp, чтобы как-то отслеживать потребность в EDNS?

особенно интересно количество рекурсивных клиентов

Нет, всякое прочее, типа ″soa queries in progress″, с обычными udp клиентами named без проблем «разделывался», если их слишком много, то просто игнорировал, но не тупил. Ну раз перезапуск решил проблему, то и искать особо нечего, может он просто кеш перестраивал.

Да, пока имена короткие. Но, я не помню, а named что-нибудь пишет в логи, по поводу того, что udp не хватило и был использован tcp, чтобы как-то отслеживать потребность в EDNS?

Я это добавил для логгинга этих траблов «* after disabling EDNS »

  channel default_file {
        file "/var/log/default.log" versions 3 size 500m;
        severity dynamic;
        print-time yes;
    };

Нет, всякое прочее, типа ″soa queries in progress″, с обычными udp клиентами named без проблем «разделывался», если их слишком много, то просто игнорировал, но не тупил. Ну раз перезапуск решил проблему, то и искать особо нечего, может он просто кеш перестраивал.

У меня перед серваком стоит ASA может ли ее inspect ф-ция криво работать? Надо разобраться до первопричине .

ASA может всё :-)

Как разбираться с первопричиной я не подскажу. Если бы ситуация чётко воспроизводилась, можно было бы записать tcpdump dns-пакетов, чтобы посмотреть, отправляет ли bind запрос. Но при таком количестве запросов и неопределённости с моментом возникновения проблемы, дамп будет просто огромным и в нём трудно будет что-то найти.

ASA может всё :-)

Уже много от ее inspect натерпелись ;)
http://unixrevolution.blogspot.com/2012/01/cisco-asa-5505-and-edns-issue.html#! однако у меня до сих пор эта трабла есть . седня перегрузим ее думаю