Развертывание рекурсивного кэширующего сервиса dns пакет bind. Настройка кеширующего DNS сервера (BIND) для локальной сети

С каждым годом скорость интернета - как последней мили, так и магистральных каналов становится все выше. Лишь одно неизменно - латентность уже уперлась в физические ограничения: скорость света в оптоволокне - около 200тыс километров в секунду, и соответственно, быстрее чем за ~150ms ответ от сервера через атлантический океан не получить в обозримой перспективе (хотя конечно есть изыски, вроде оптоволокна с воздушной сердцевиной или радиорелейной связи, но это для простых смертных едва-ли доступно).

Когда мы пытаемся например из России открыть web-сайт, расположенный в США (его NS сервера вероятно там же), и домен не нашелся в DNS-кэше вашего провайдера - то ждать придется долго даже на гигабитном интернете, возможно даже целую секунду: пока мы через океан получим имена NS серверов домена, пока разрезолвим их IP, пока отправим и получим собственно сам DNS запрос…

Пару лет назад Google завела свои публичные DNS сервера, а для агитации перехода на них - они разработали утилитку NameBench , которая прогоняет тесты DNS по вашей истории серфинга и показывает, насколько Google DNS быстрее DNS сервера вашего провайдера.

Но мне удалось сделать свой DNS сервер, который работает быстрее Google Public DNS, и в этой краткой заметке хочу поделится результатами.

PDNSD

pdnsd - кэширующий DNS proxy. Помимо банального кэширования DNS запросов (с возможностью жестко задавать минимальный TTL - может быть нужно на очень плохом интернете), он умеет отсылать запрос одновременно на несколько «родительских» DNS серверов, и отдавать клиенту первый вернувшийся ответ.

Именно включение параллельного опроса и дает нам основное преимущество в скорости , т.к. при нахождении результата в кеше любого из провайдеров мы получаем результат очень быстро, и не ждем полного и медленного разресолвивания если у первого провайдера нет ответа в кэше.

Ставится в Ubuntu - банальным apt-get.

Пара моментов в конфиге

global { perm_cache=10240; //Максимальный размер кэша в килобайтах. //По дефолту было 1024, все записи у меня не влазили. cache_dir="/var/cache/pdnsd"; [...] min_ttl=60m; // Минимальное время сохранения записи в кэше. //Даже если TTL придет меньше 60минут - будет 60минут max_ttl=1w; // Максимальное время сохранения записи в кэше neg_ttl=5m; //Время кеширования отрицательных ответов (т.е. если домен не найден) [..] par_queries=3; //Количество одновременно опрашиваемых "родительских" DNS серверов } server { label = "main"; ip = 85.21.192.5 //Тут 4 сервера, если первые 3 не ответят, то будет отправлен запрос на 4-й, 213.234.192.7 //Первые 2 сервера - это сервер вашего провайдера, и какого-нибудь соседнего, 8.8.4.4 //Это Google Public DNS - у них закэшировано все редкое и резолвят они быстро, 8.8.8.8 ; [..] }

В принципе, кэширование можно сделать менее агрессивным (min_ttl=1m например), но за год работы проблем особых не возникло. В случае проблем - при желании можно вытереть одну запись из кэша:
sudo pdnsd-ctl record 3.14.by delete или сразу все:
sudo pdnsd-ctl empty-cache

Результаты тестирования в NameBench

Видим, что для 50% запросов ответ мы получаем менее чем за 10мс, для 85% быстрее Google Public DNS, ну а дальше результаты естественно совпадают с гуглом.

По результатам тестов NameBench нам радостно сообщает:

8.8.8.8 Slower replica of SYS-192.167.0.98 8.8.4.4 Slower replica of SYS-192.167.0.98

Таким образом, умный кэширующий DNS прокси с параллельными запросами - позволяет ускорить даже 100-мегабитный интернет. А уж для медленных (радио)линков с большой латентностью и потерей пакетов - и вовсе разница может быть как между небом и землей.
Автор: Paul Cobbaut
Дата публикации: 24 мая 2015 г.
Перевод: A.Панин
Дата перевода: 11 июля 2015 г.

Глава 4. Вводная информация о серверах DNS

4.3. Кэширующие серверы DNS

Сервер DNS , не обслуживающий зону DNS , но соединенный с другими серверами имен для кэширования запросов, называется кэширующим сервером DNS . Кэширующие серверы DNS не работают с базами данных зон DNS , содержащими ресурсные записи. Вместо этого они соединяются с другими серверами имен и кэшируют соответствующую информацию.

Существует два вида кэширующих серверов DNS. Это серверы DNS, использующие перенаправляющие серверы DNS , а также серверы DNS, использующие корневые серверы DNS .

4.3.1. Кэширующий сервер DNS, не использующий перенаправляющий сервер

Кэширующий сервер DNS, не использующий перенаправляющий сервер, должен получать информацию где-либо еще. В момент приема запроса от клиента он связывается с одним из корневых серверов. Корневой сервер передает кэширующему серверу информацию о сервере, обслуживающем целевой домен верхнего уровня, который, в свою очередь, направит его на другой сервер DNS . Последний сервер может либо обладать информацией для ответа на запрос, либо передать информацию о другом сервере DNS, который может обладать этой информацией. В конце концов наш сервер DNS получит информацию, необходимую для ответа на запрос, и отправит ответ клиенту.

На иллюстрации ниже показан процесс отправки клиентом запроса информации об IP-адресе для доменного имени linux-training.be. Наш кэширующий сервер соединится с корневым сервером и будет перенаправлен на сервер, обслуживающий домен верхнего уровня.be. После этого он соединится с сервером, обслуживающим домен верхнего уровня.be, и будет перенаправлен на один из серверов имен организации Openminds. Один из этих серверов имен (в данном случае nsq.openminds.be) ответит на запрос, передав IP-адрес сервера с доменным именем linux-training.be. После того, как наш кэширующий сервер передаст данную информацию клиенту, клиент сможет соединиться с рассматриваемым веб-сайтом.

При использовании сниффера tcpdump в процессе разрешения данного доменного имени можно получить следующий вывод (первые 20 символов каждой строки были удалены).

192.168.1.103.41251 > M.ROOT-SERVERS.NET.domain: 37279% A? linux-tr\ aining.be. (46) M.ROOT-SERVERS.NET.domain > 192.168.1.103.41251: 37279- 0/11/13 (740) 192.168.1.103.65268 > d.ns.dns.be.domain: 38555% A? linux-training.\ be. (46) d.ns.dns.be.domain > 192.168.1.103.65268: 38555- 0/7/5 (737) 192.168.1.103.7514 > ns2.openminds.be.domain: 60888% A? linux-train\ ing.be. (46) ns2.openminds.be.domain > 192.168.1.103.7514: 60888*- 1/0/1 A 188.93.155.\ 87 (62)

4.3.2. Кэширующий сервер DNS, использующий перенаправляющий сервер

Кэширующий сервер DNS , использующий перенаправляющий сервер, является сервером DNS, который получает всю необходимую информацию от перенаправляющего сервера (forwarder). В качестве перенаправляющего сервера DNS может выступать, к примеру, сервер DNS интернет-провайдера.

На иллюстрации выше показан сервер DNS в локальной сети компании, который использует предоставляемый интернет-провайдером сервер DNS в качестве перенаправляющего сервера DNS . В том случае, если IP-адресом предоставляемого интернет провайдером сервера DNS является адрес 212.71.8.10, в файле конфигурации named.conf сервера DNS компании должны присутствовать следующие строки:

Forwarders { 212.71.8.10; };

Кроме того, вы также можете настроить ваш сервер DNS для работы с условно-перенаправляющими серверами DNS (conditional forwarders). Описание условно-перенаправляющего сервера DNS в файле конфигурации выглядит следующим образом:

Zone "someotherdomain.local" { type forward; forward only; forwarders { 10.104.42.1; }; };

4.3.3. Итеративный или рекурсивный запрос

Рекурсивным запросом называется запрос DNS, после отправки которого клиент ожидает получения окончательного ответа от сервера DNS (на иллюстрации выше он изображен с помощью жирной красной стрелки, направленной от Макбука к серверу DNS). Итеративным же запросом называется запрос DNS, после отправки которого клиент не ожидает получения окончательного ответа от сервера DNS (на иллюстрации выше он изображен с помощью трех черных стрелок,направленных от сервера DNS). Итеративные запросы чаще всего осуществляются между серверами имен. Корневые серверы имен не отвечают на рекурсивные запросы.

Сервер DNS, осуществляющий управление зоной DNS, называется авторитативным сервером DNS (authoritative DNS server) для данной зоны. Помните о том, что зона DNS является всего лишь набором ресурсных записей.

Первый авторитативный сервер DNS для зоны DNS называется первичным сервером DNS (primary DNS server). Этот сервер будет работать с копией базы данных зоны DNS , доступной как для чтения, так и для записи. При необходимости повышения сохранности данных в случае сбоев, повышения производительности сервера или балансировки нагрузки вы можете ввести в строй другой сервер DNS , который также будет управлять данной зоной DNS. Этот сервер будет называться вторичным сервером DNS (secondary DNS server).

Вторичный сервер получает копию базы данных зоны DNS от первичного сервера в процессе передачи данных зоны DNS (zone transfer). Запросы осуществления передач данных зон DNS отправляются вторичными серверами через определенные временные интервалы. Длительность этих временных интервалов устанавливаются в рамках ресурсной записи SOA .

Вы можете инициировать принудительное обновление данных зоны DNS с помощью утилиты rndc . В примере ниже инициируется передача данных зоны DNS fred.local , а также выводится соответствующий фрагмент файла системного журнала /var/log/syslog .

root@debian7:/etc/bind# rndc refresh fred.local root@debian7:/etc/bind# grep fred /var/log/syslog | tail -7 | cut -c38- zone fred.local/IN: sending notifies (serial 1) received control channel command "refresh fred.local" zone fred.local/IN: Transfer started. transfer of "fred.local/IN" from 10.104.109.1#53: connected using 10.104.33.30#57367 zone fred.local/IN: transferred serial 2 transfer of "fred.local/IN" from 10.104.109.1#53: Transfer completed: 1 messages, 10 records, 264 bytes, 0.001 secs (264000 bytes/sec) zone fred.local/IN: sending notifies (serial 2) root@debian7:/etc/bind#

При добавлении вторичного сервера DNS в зону DNS вы можете настроить этот сервер таким образом, что он окажется ведомым сервером DNS (slave DNS server) по по отношению к первичному серверу. Первичный же сервер DNS окажется ведущим сервером DNS (master DNS server) по отношению к вторичному серверу.

Чаще всего первичный сервер DNS является ведущим сервером, работающим со всеми ведомыми серверами. Иногда ведомый сервер может являться одновременно и ведущим сервером для ведомых серверов следующего уровня. На иллюстрации ниже сервер с именем ns1 является первичным сервером, а серверы с именами ns2, ns3 и ns4 - вторичными серверами. Хотя ведущим сервером для серверов с именами ns2 и ns3 и является сервер с именем ns1, ведущим сервером для сервера с именем ns4 является сервер с именем ns2.

Ресурсная запись SOA содержит значение частоты обновления данных зоны DNS с именем refresh . В том случае, если это значение устанавливается равным 30 минутам, ведомый сервер будет отправлять запросы на передачу копии данных зоны DNS через каждые 30 минут. Также данная запись содержит значение продолжительности периода ожидания с именем retry . Данное значение используется в том случае, если ведущий сервер не отвечает на последний запрос передачи данных зоны DNS. Значение с именем expiry time устанавливает период времени, в течение которого ведомый сервер может отвечать на запросы от клиентов без обновления данных зоны DNS.

Ниже приведен пример использования утилиты nslookup для чтения данных ресурсной записи SOA зоны DNS (linux-training.be).

Root@debian6:~# nslookup > set type=SOA > server ns1.openminds.be > linux-training.be Server: ns1.openminds.be Address: 195.47.215.14#53 linux-training.be origin = ns1.openminds.be mail addr = hostmaster.openminds.be serial = 2321001133 refresh = 14400 retry = 3600 expire = 604800 minimum = 3600

Передачи данных зон DNS осуществляются лишь в случаях изменения данных в базах данных зон DNS (то есть, тогда, когда происходит добавление, удаление или изменение одной или большего количества ресурсных записей на стороне ведущего сервера). Ведомый сервер осуществляет сравнение номера версии (serial number) собственной копии ресурсной записи SOA с номером версии ресурсной записи SOA соответствующего ведущего сервера. В том случае, если номера версий совпадают, обновления данных не требуется (по той причине, что другие ресурсные записи не были добавлены, удалены или изменены). В том же случае, если номер версии ресурсной записи SOA на стороне ведомого сервера меньше номера версии той же записи на стороне соответствующего ведущего сервера, будет осуществлен запрос передачи данных зоны DNS.

Ниже приведен снимок окна сниффера Wireshark с данными, перехваченными в процессе передачи данных зоны DNS.

4.9. Полные или частичные передачи данных зон DNS

Передача данных зоны DNS может быть как полной, так и частичной. Решение об использовании того или иного режима зависит от объема данных, который необходимо передать для полного обновления базы данных зоны DNS на ведомом сервере. Частичная передача данных зоны предпочтительна в том случае, когда полный объем измененных данных меньше объема всей базы данных. Полные передачи данных зон DNS осуществляются с использованием протокола AXFR , а частичные передачи данных зон DNS - с использованием протокола IXFR .

Назначение DNS это перевод доменных имен, легко запоминаемых человеком в IP адреса которые понимают компьютеры, этот процесс называется-Разрешение имен.
Что нам даст установка собственного кеширующего DNS сервера?!
Это немного ускорит отклик сайтов + Linux не очень хорошо воспринимает имена NetBios, а ведь иногда приходится находить компьютеры или принтеры внутри локальной сети, а хочется это делать по именам.
Запоминать IP адреса- не удобно, а постоянно лазить к журнал работы DHCP сервера- тоже не наш метод. Вот для таких случаев и нужен DNS в локальной сети.
Сама установка пакета bind9 не отличается сложностью, затыки, обычно возникают на стадии его конфигурирования, т.к. после легко читаемых конфигурационных файлов системы, на человека сваливается непонятный синтаксис, кстати, очень похожий на язык программирования С. Т.к. сервер будет работать внутри локальной сети, то не имеет смысла переносить его в chroot окружение и вся настройка занимает совсем немного времени.
На этом, лирическую часть, можно завершить, переходим к установке и настройке.
Установим DNS сервер Bind9:
sudo apt-get install bind9
После завершения, закачки и установки, нам необходимо отредактировать его конфигурационный файл:
sudo nano /etc/bind/named.conf.options
Находим секцию, она находится в самом начале конфигурационного файла, кроме нее там больше ничего нет…

Options { directory "/var/cache/bind"; // If there is a firewall between you and nameservers you want // to talk to, you may need to fix the firewall to allow multiple // ports to talk. See http://www.kb.cert.org/vuls/id/800113 // If your ISP provided one or more IP addresses for stable // nameservers, you probably want to use them as forwarders. // Uncomment the following block, and insert the addresses replacing // the all-0"s placeholder. // forwarders { // 0.0.0.0; // }; auth-nxdomain no; # conform to RFC1035 listen-on-v6 { any; }; };

Секция forwarders, отвечает за то, куда будет передаваться DNS запрос на разрешение имени, в случае если его нет в собственной базе. Последнее время меня совсем не радует, работа этих серверов у провайдера по этому можно подключить сторонние например гугловские, запомнить IP очень легко 8.8.8.8, на его примере я и буду вести настройку, но никто не мешает использовать, те что вам нравятся больше.

Редактируем секцию, для начала с нее нужно снять комментарии и добавить сторонние DNS, если есть необходимость добавить несколько серверов, например на тот случай если сервер google не выдержит ваших запросов и поломается:), то IP других серверов можно написать в столбик, тогда можно добиться более значительной отказоустойчивости.
forwarders { 8.8.8.8; 193.58.251.251; //Российская служба DNS -SkyDNS };
В эту секцию лучше вписать IP того сервера который у вас указан в файле /etc/resolv.conf или вписать туда в секцию nameserver этот IP
Сохраняем изменения и выходим
Перезапускаем сервер и проверяем
Набираем в командной строке nslookup mail.ru
Должно выдать:

Non-authoritative answer: Name: mail.ru Addresses: 94.100.191.202
Это говорит о том, что наш сервер не является, главным в обслуживании этой зоны (mail.ru), но запросы добавил в кеш!
Теперь нужно создать ДНС зону для нашей сети чтобы машины могли находить различные сетевые сервисы - могут быть, например, сетевые принтеры, они могут быть как самостоятельными так и расшаренными на других рабочих станциях.
Нашу зону можно назвать orgname –т.е. название организации.
Первым делом создаем зону, для этого отредактируем named.conf.local

Sudo nano /etc/bind/named.conf.local
и добавим в него следующее:
zone "orgname" { type master; file "/etc/bind/db.orgname"; };
Сохраняем и выходим
Теперь нам необходимо создать файл настройки зоны
sudo nano /etc/bind/db.orgname
и вставляем в него следующее:
(Прошу отнестись внимательно к синтаксису конфигурационного файла, даже точки имеют значение)

@ IN SOA orgname. root.orgname. (20101015 4h ; время обновления -4 часа 1h ; повтор каждый час 1w ; как долго хранить информацию -1 неделю 1d) ; TTL (время жизни) записи - 1 день @ IN NS orgname. ; имя сервера имен @ IN A 192.168.10.1 ; A - запись - IP адрес нашего ДНС сервера который обслуживает эту зону, @ означает что это корневая зона. * IN CNAME @ printer IN A 192.168.10.25 ; Можно создать ДНС запись сетевого принтера который находится по адресу 192.168.10.25

Теперь, при добавлении нового сетевого устройства, вам необходимо сделать 2 вещи:
1) Зарезервировать IP адрес на DHCP сервере, о том, как это сделать, можно прочитать в статье-
2) Создать DNS зону для этого IP, вида devicename IN A XXX.XXX.XXX.XXX. Где: devicename-сетевое имя устройства; XXX.XXX.XXX.XXX-его IP адрес который зарезервирован на DHCP сервере.

Теперь нам необходимо отредактировать файл resolv.conf

Sudo nano /etc/resolv.conf

И вписать туда:

Nameserver 127.0.0.1

Все что там было можно закоментировать поставив #

Перезапускам сервер

Сделано это для того чтобы сервер искал все в собственной базе, а уже потом BIND будет перенаправлять запросы к серверу 8.8.8.8 IP которого вписан в директиве forwarders .

Теперь можно проверять работоспособность:

Если тестирование происходит из под Windows:
ping devicename.orgname

Если тестируем из под Linux:
ping devicename.orgname -c 4
Должны пойти пинги на тот IP который вы указали вместо XXX.XXX.XXX.XXX

На этом настройку DNS сервера можно завершить.

PDNSD

Ставится в Ubuntu - банальным apt-get.

Пара моментов в конфиге

Результаты тестирования в NameBench

По результатам тестов NameBench нам радостно сообщает:

8.8.8.8 Slower replica of SYS-192.167.0.98 8.8.4.4 Slower replica of SYS-192.167.0.98

Одним из важных сервисов, обеспечивающих функционирование современного интернета является сервис по преобразованию имени сайта в ip адрес. Настройкой реализации сервиса DNS мы займемся в этой статье на примере настройки Bind 9 (named) на сервере под управлением CentOS 7. Мы подготовим минимально необходимый базовый функционал и заглянем немного глубже в настройки логирования.

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

Bind — самая распространенная на текущий день реализация ДНС сервера, которая обеспечивает преобразование IP адресов в dns-имена и наоборот. Его также называют named, например в Freebsd. Судя по информации из Википедии, сейчас 10 из 13 корневых ДНС серверов интернета работают на bind. Он установлен из коробки практически во всех linux дистрибутивах. Я рассмотрю его установку на сервер CentOS 7.

Устанавливаем Bind 9 (named) в CentOS 7

Первым делом проверим, установлен ли у нас днс сервер в системе:

# rpm -qa bind* bind-libs-lite-9.9.4-14.el7.x86_64 bind-license-9.9.4-14.el7.noarch

У меня не установлен, так как во время выбрал минимальный пакет программ. Сервер имен у нас будет работать в chroot окружении, так что устанавливаем соответствующие пакеты:

# yum - y install bind bind - utils bind - chroot

Еще раз обращаю внимание, что мы будем использовать bind в chroot среде для увеличения безопасности. Это накладывает определенные особенности в настройке и управлении сервером. Нужно быть внимательным в этих мелочах. Итак, запускаем bind :

# systemctl start named-chroot # systemctl enable named-chroot ln -s "/usr/lib/systemd/system/named-chroot.service" "/etc/systemd/system/multi-user.target.wants/named-chroot.service"

Проверяем содержимое chroot каталога:

# ls -l /var/named/chroot/etc

Все в порядке, сервер запустился, необходимые файлы созданы, все готово для настройки. Займемся ей.

Настраиваем DNS сервер в CentOS 7

Файл конфигурации нашего сервера располагается по адресу /var/named/chroot/etc/named.conf . Открываем его и приводим к следующему виду:

# mcedit /var/named/chroot/etc/named.conf options { listen-on port 53 { any; }; listen-on-v6 port 53 { none; }; directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; allow-query { 127.0.0.1; 192.168.7.0/24; }; recursion yes; allow-recursion { 127.0.0.1; 192.168.7.0/24; }; forwarders { 8.8.8.8; }; version "DNS Server"; managed-keys-directory "/var/named/dynamic"; pid-file "/run/named/named.pid"; session-keyfile "/run/named/session.key"; dnssec-enable no; dnssec-validation no; }; zone "." IN { type hint; file "named.ca"; }; include "/etc/named.rfc1912.zones"; include "/etc/named.root.key"; logging { channel default_file { file "/var/log/named/default.log" versions 3 size 5m; severity dynamic; print-time yes; }; category default { default_file; }; };

Эта конфигурация обеспечит работу обычного кэширующего сервера в локальной сети. Комментарии к некоторым параметрам:

Не забудьте отредактировать правила фаервола для корректной работы DNS сервера — открыть 53 порт UDP для работы кэширующего сервера, который мы сейчас настроили, и 53 порт TCP для пересылки зон, о которых речь пойдет дальше

Теперь создадим папку для логов. Не забываем, что мы работаем в chroot окружении:

# cd /var/named/chroot/var/log && mkdir named && chown named. named

Поддержка собственной зоны

Допустим, нам необходимо в нашем named разместить собственную зону site1.ru. Первым делом создаем файл зоны, которую будет обслуживать dns сервер:

# mcedit /var/named/chroot/var/named/site1.ru.zone $TTL 86400 @ IN SOA site1.ru. site1.ru.local. (2015092502 43200 3600 3600000 2592000) IN NS ns1.site1.ru. IN NS ns2.site1.ru. IN A 192.168.7.254 IN MX 10 mx.site1.ru. gate IN A 192.168.7.254 mx IN A 192.168.7.250 ns1 IN A 192.168.7.235 ns2 IN A 192.168.7.231

Описание синтаксиса файлов зон достаточно хорошо освещено в интернете, не хочется подробно на этом останавливаться. При желание каждый сам сможет посмотреть, если у него возникнет необходимость настроить поддержку собственной зоны.

Выставляем необходимые права:

# chown root:named /var/named/chroot/var/named/site1.ru.zone # chmod 0640 /var/named/chroot/var/named/site1.ru.zone

Zone "site1.ru" { type master; file "site1.ru.zone"; };

Перечитываем конфигурацию named с помощью rndc :

# rndc reconfig

Добавление в bind slave zone

Если вы хотите на своем сервере держать копию какой-то зоны, взятой с другого dns сервера, то добавьте следующие настройки в конфиг.

Zone "site.ru" IN { type slave; masters { 10.1.3.4; }; file "site.ru.zone"; };

10.1.3.4 — ip адрес dns сервера, с которого мы берем зону. Не забудьте на нем разрешить передачу зоны на ваш dns сервер.

Нужно добавить группе named разрешение на запись, чтобы стало вот так:

После этого можно перезапустить bind и проверить, что создался файл слейв зоны. С указанными выше настройками, он будет располагаться по адресу /var/named/chroot/var/named/site.ru.zone . Если у bind не будет прав для создания файла, в логе вы получите ошибку:

Dumping master file: tmp-7Swr6EZpcd: open: permission denied

Гораздо интереснее и полезнее разобраться с подробным логированием работы сервера. Я долгое время поверхностно хватался за всякие рекомендации и куски примерных конфигов в интернете, пока в не решил разобраться сам с этой темой и не полез в оригинальный мануал .

Bind дает широкие возможности для ведения логов. Можно фиксировать практически все, что связано с работой сервера. Я сейчас на простых примерах покажу, как это работает.

Первым делом в конфигурации мы задаем канал, куда будут складываться логи по тем или иным событиям. Вот пример подобного канала:

Channel general { file "/var/log/named/general.log" versions 3 size 5m; severity dynamic; print-time yes;

Здесь указано название канала, которые мы придумываем сами — general, указан путь до файла, сказано, что хранить будем 3 версии лога размером не более 5 мегабайт. Параметр severity может принимать следующие значения:

Параметр print-time указывает на то, что в лог необходимо записывать время события. Помимо указанных мной настроек, в конфигурации канала могут быть добавлены следующие параметры:

print-severity yes | no — указывает, писать или нет параметр severity в лог
print-category yes | no — указывает писать или нет название категории логов

Я эти параметры не указал, так как по-умолчанию устанавливается значение no , которое лично меня устраивает.

Category general { general; };

Описание категорий логов в bind (named)

default	Сюда будут попадать события всех категорий из этой таблицы, если они не определены отдельно, за исключением категории queries, которую нужно включать специально. То есть если обозначить только категорию default, то в нее будут сыпаться события всех категорий.
general	Эта категория для всех логов, которые не включены ни в одну из перечисленных категорий.
database	Сообщения, относящиеся к хранению зон и кэшированию.
security	Подтверждение и отказ в выполнении запросов.
config	Все, что относится к чтению и выполнению файла конфигурация.
resolver	Разрешение имен, включая информацию о рекурсивных запросах, выполняемых от имени клиента кэширующим сервером.
xfer-in	Информация о получении зон.
xfer-out	Информация о передаче зон.
notify	Логирование операций протокола NOTIFY.
client	Выполнение клиентских запросов.
unmatched	Сообщения, которые named не смог отнести ни к одному классу или для которых не определено отображение.
network	Логирование сетевых операций.
update	Динамические апдейты.
update-security	Подтверждение или отклонение запросов на апдейт.
queries	Логирование запросов к ДНС серверу. Для включения этой категории необходимо отдельно задать параметр в конфигурации сервера. Это связано с тем, что эта категория генерирует очень много записей в лог файл, что может сказаться на производительности сервера.
query-errors	Ошибки запросов к серверу.
dispatch	Перенаправление входящих пакетов модулям сервера на обработку.
dnssec	Работа протоколов DNSSEC и TSIG.
lame-servers	Фиксируются ошибки, которые получает bind при обращении к удаленным серверам в попытке выполнить запрос на разрешение имени.
delegation-only	Логирование запросов, вернувших NXDOMAIN.
edns-disabled	Запросы, которые вынуждены использовать plain DNS из-за превышения timeouts.
RPZ	Все операции, связанные с выполнение Response Policy Zone (RPZ).
rate-limit	Операции связанные с одним или несколькими rate-limit statements в options или view.

Таким образом, чтобы вывести все категории логов в отдельные файлы, необходимо в конфиг named добавить следующую конструкцию:

Logging { channel default { file "/var/log/named/default.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel general { file "/var/log/named/general.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel database { file "/var/log/named/database.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel security { file "/var/log/named/security.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel config { file "/var/log/named/config.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel resolver { file "/var/log/named/resolver.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel xfer-in { file "/var/log/named/xfer-in.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel xfer-out { file "/var/log/named/xfer-out.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel notify { file "/var/log/named/notify.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel client { file "/var/log/named/client.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel unmatched { file "/var/log/named/unmatched.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel network { file "/var/log/named/network.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel update { file "/var/log/named/update.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel update-security { file "/var/log/named/update-security.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel queries { file "/var/log/named/queries.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel query-errors { file "/var/log/named/query-errors.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel dispatch { file "/var/log/named/dispatch.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel dnssec { file "/var/log/named/dnssec.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel lame-servers { file "/var/log/named/lame-servers.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel delegation-only { file "/var/log/named/delegation-only.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel edns-disabled { file "/var/log/named/edns-disabled.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel rpz { file "/var/log/named/rpz.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel rate-limit { file "/var/log/named/rate-limit.log" versions 3 size 5m; severity dynamic; print-time yes; }; category default { default; }; category general { general; }; category database { database; }; category security { security; }; category config { config; }; category resolver { resolver; }; category xfer-in { xfer-in; }; category xfer-out { xfer-out; }; category notify { notify; }; category client { client; }; category unmatched { unmatched; }; category network { network; }; category update { update; }; category update-security { update-security; }; category queries { queries; }; category query-errors { query-errors; }; category dispatch { dispatch; }; category dnssec { dnssec; }; category lame-servers { lame-servers; }; category delegation-only { delegation-only; }; category edns-disabled { edns-disabled; }; category rpz { rpz; }; category rate-limit { rate-limit; }; };

Если мы хотим собирать все логи запросов из категории queries , то в раздел options файла конфигурации необходимо добавить параметр, который это разрешает:

Querylog yes;

Перезапускаем bind :

# systemctl restart named-chroot.service

Проверка работы DNS Server

Первым делом пойдем в каталог с логами и проверим, что там у нас:

# cd /var/named/chroot/var/log/named # ls -l

Все файлы журнала созданы и начали наполняться. Можно проверить один из них. Например, посмотрим, как наш сервер centos (192.168.7.246) логирует запросы пользователей. Попробуем с компьютера 192.168.7.254 (windows) выполнить nslookup yandex.ru и посмотрим как это отразится в лог файле:

26-Sep-2015 19:25:30.923 client 192.168.7.254#56374 (yandex.ru): query: yandex.ru IN A + (192.168.7.246) 26-Sep-2015 19:25:31.013 client 192.168.7.254#56375 (yandex.ru): query: yandex.ru IN AAAA + (192.168.7.246)

Теперь выполним ping site1.ru, чтобы проверить, как сервер поддерживает нашу зону:

Смотрим, что в логах:

26-Sep-2015 19:28:01.660 client 192.168.7.254#49816 (site1.ru): query: site1.ru IN A + (192.168.7.246)

Таким образом очень удобно отследить, куда лезет компьютер. Например, можно поднять временно dns сервер, включить лог запросов. В клиенте указать единственный днс сервер, который мы настроили. Дальше можно отслеживать, к примеру, куда лезет винда после загрузки без нашего ведома. Или откуда грузится реклама в скайпе. Все запросы будут аккуратно складываться в файл, который потом можно спокойно анализировать, а затем, к примеру, .

Это все, что я хотел в данном материале рассказать. Тема настройки bind (named) достаточно обширная. Возможно я еще вернусь к ней.

Онлайн курсы по Mikrotik

Если у вас есть желание научиться работать с роутерами микротик и стать специалистом в этой области, рекомендую пройти курсы по программе, основанной на информации из официального курса MikroTik Certified Network Associate . Помимо официальной программы, в курсах будут лабораторные работы, в которых вы на практике сможете проверить и закрепить полученные знания. Все подробности на сайте. Стоимость обучения весьма демократична, хорошая возможность получить новые знания в актуальной на сегодняшний день предметной области. Особенности курсов:

Знания, ориентированные на практику;
Реальные ситуации и задачи;
Лучшее из международных программ.

Развертывание рекурсивного кэширующего сервиса dns пакет bind. Настройка кеширующего DNS сервера (BIND) для локальной сети

PDNSD

Пара моментов в конфиге

Результаты тестирования в NameBench