bind9: отключение регистрации ошибок для рекурсивных запросов

Относительно отключения регистрации всех ошибок привязки для рекурсивных запросов, таких как «запрос (кеш) 'theswat.net/ANY/IN' запрещен»

Приведенный ниже файл /etc/ named.conf перенаправляет их в /var/ named/data/ named.security с общим ограничением размера 15 Мб для пролистывания журналов. Обратите внимание, что безопасность категории - это только «Утверждение и отклонение запросов».

logging {
        channel default_debug {
                    file "data/named.run";
                severity dynamic;
        };
        // Redirect all of those 'denied' logs for non-existing domains or external ones (we are 'recursion no;')
        //   logs to /var/named/data/named.security, up to 3 files of 5mbytes each
        //   independent hack_detect processes can then scan for flooders and known abusers and block their IPs
        channel hd_security {
                file "data/named.security" versions 3 size 5m;
                print-time yes;
                print-severity yes;
                print-category yes;
        };
        category security { hd_security; };
};

См. Справочное руководство администратора BIND (также известное как «ARM», которое включено в ваш исходный дистрибутив, либо обратитесь к таблицам ссылок в базе знаний ISC чтобы найти версию, специфичную для вашей версии BIND) и перейдите к разделу 6.2.10, который описывает ведение журнала.

Сообщения об ошибках BIND отправляются в различных категориях, и вы можете указать их место назначения в зависимости от категории. Хотя я не знаю наверняка и должен был бы проверить источник, чтобы точно знать, в какой категории находится сообщение об ошибке, которое вы хотите подавить, после того, как вы определили категорию (либо путем проверки источника, либо методом проб и ошибок), вы можете подавить сообщения об ошибках для этой категории с использованием синтаксиса образца, показанного в ARM, то есть:

To discard all messages in a category, specify the null channel:
category xfer-out { null; };
category notify { null; };

Я бы начал с категории «распознаватель», хотя, поскольку это сообщение об отказе, оно может принадлежать к «безопасности» - на самом деле описанная вами область находится между несколькими возможными категориями (поэтому я не могу сказать, что это верх из моей головы, что правильно ..) "resolver" звучит как сообщения, которые вы не ожидаете найти полезными в любом случае, если вы не пытаетесь выполнять рекурсию для клиентов.

Да, привязку можно отключить. Проверьте свою конфигурацию на предмет категорий и определений каналов. Если это отображается в вашем системном журнале, найдите каналы, упоминающие системный журнал. Также имеется встроенный канал default_syslog. Затем найдите категории, ведущие журналы на эти каналы. Закомментируйте категорию или перенаправьте ее на другой канал. Вы можете перенаправить в журнал во время тестирования.

Более подробную информацию можно найти здесь: http://www.zytrax.com/books/dns/ch7/logging.html

Для тех, кто использует syslog и не хочет все выбрасывать. Технически вы не хотите отправлять все в NULL. Здесь все еще регистрируются сообщения WARNING и CRITICAL.

logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
        };
        channel syslog {
                syslog;
                severity warning;
                print-severity yes;
                print-category yes;
        };
        category default{
                syslog;
        };
};