Редактируем файл /etc/resolv.conf: первый DNS сервер это закольцовывание на ваш локальный сервер DNS (127.0.0.1), вторым ближайший к вам DNS сервер (обычно предоставляется вашим провайдером интернета), список остальных DNS на ваше усмотрение (они не являются обязательными). Файл resolv.conf, говорит нам о том, что в случае неудачного DNS запроса к вашему серверу (127.0.0.1), запрос будет автоматически переадресован ко второму по списку DNS серверу и т.д..

> ee /etc/resolv.conf domain your.domen nameserver 127.0.0.1 #DNS your ISP nameserver x.x.x.x nameserver x.x.x.x

Резолвер(resolver) - это набор подпрограмм в библиотеке C, которые предоставляют доступ к Internel Что такое DNS (Domain Name System) (Системе Доменных Имен Интернет) (прим. пер. – DNS обеспечивает возможность преобразования символьных имен машин в IP-адреса и наоборот, IP-адресов в символьные имена). Файл с настройками /etc/resolv.conf для резолвера содержит информацию, которую первым делом читают подпрограммы резолвера, вызванные каким-либо процессом. Данный файл устроен так, чтобы его мог читать человек и содержит список ключевых слов и значений, которые предоставляют резолверу различную информацию.

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

Параметры конфигурации:

адрес сервера имен в Интернет (в нотации xxx.xxx.xxx.xxx), который будет обрабатывать запросы от резолвера. Серверов имен может быть максимум 3 (остальные игнорируются), по одному на каждой строке. Если задано несколько серверов, то библиотека резолвера опрашивает их в порядке перечисления. Если записей nameserver нет, то по умолчанию используется сервер имен на локальной машине. (Используемый алгоритм пытается подключиться к серверу имен и, если запрос не был обработан через некоторый промежуток времени, делается попытка подключиться к следующему серверу имен, и так до тех пор пока не будет обработан весь список серверов, затем повторить процедуру, пока не будет достигнуто максимальное количество повторов).

Локальное имя домена. Большинство запросов на имена машин в этом домене смогут использовать лишь краткие имена, без указания имени домена. Если записей domain нет, то домен определяется из имени локальной машины, которое возвращается функцией gethostname(); доменной частью имени считается все, что следует после первой точки `.". Наконец, если имя машины не содержит доменной части, назначается корневой домен.

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

Разрешает сортировку адресов, которые возвращаются вызовом gethostbyname(). Опция sortlist задается с помощью пары: IP адрес/маска сети. Маска сети является необязательной, по умолчанию используется текущая маска сети. Пары из IP-адреса и необязательной маски сети разделяются прямой косой чертой. Может быть задано до 10 пар. пример: sortlist 130.155.160.0/255.255.240.0 130.155.0.0

Данная опция разрешает изменение определенных переменных резолвера. Синтаксис такой:

Options опция... где опция может принимать одно из следующих значений: debug --- устанавливает RES_DEBUG в _res.options. ndots:n --- устанавливает порог для количества точек, которое должно быть в имени, заданном в res_query (см. resolver(@LIB_NETWORK_EXT@)) перед тем как будет создан начальный абсолютный запрос (initial absolute query). По умолчанию, n ``1"", означает, что если в имени есть хоть одна точка, будет попытка считать это имя абсолютным перед добавлением к нему элементов из списка search.

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

Ключевое слово и значение должны быть в одной строке, и кроме того, ключевое слово (например, nameserver), должно быть первым в строке. Значение должно отделяться от ключевого слова пробелом.

Сегодня поговорим о создании локальной доменной зоны внутри локальной сети. Для чего нужна локальная доменная зона и DNS-сервер? Чтобы расшарить (сделать доступными) свои локальные сайты для всех пользователей сети.

Я создам сеть, где все устройства моей локальной сети смогут пользоваться ресурсами формата site.lan. В моем случае устройства локальной сети подключаются к интернету через роутер. Серверная машина - на Linux Mint (desktop), клиенты: ПК под управлением Windows, Linux, телевизор со Smart TV, а также смартфоны и планшет. Для начала убедитесь, что в роутере для сервера (машины, на которой будет установлен DNS сервер) зарезервирован статический внутренний IP адрес. Это очень важно, чтобы потом указать всем сетевым устройствам, где именно находится наш DNS сервер.

Установка DNS неймсервера:

Для начала необходимо установить пакет Bind:

Sudo apt-get install bind

Кроме того, для нормальной работы веб-сайтов нам потребуется LAMP (Linux Apache MySQL PHP). О том как установить LAMP в Ubuntu читайте в моей статье . А также по ссылке внизу статьи можете настроить локальный сайт. Единственное, что не прописывайте в /etc/hosts адрес сайта, т.к. этими вопросами будет заниматься неймсервер. На этом этап подготовки окончен.

Настройка Bind

Входим в директорию Bind и делаем резервные копии конфигурируемых файлов:

Cd /etc/bind/ cp named.conf.local named.conf.local.back cp named.conf.options named.conf.options.back

Создаём локальную доменную зону.lan:

Nano named.conf.local

И дописываем в конец файла следующие строки:

Zone "lan" { type master; file "/etc/bind/db.lan"; };

Теперь создаем соответствующий файл для доменной зоны.lan и открываем его на редактирование:

Touch db.lan nano db.lan

Наполняем его содержимым:

@ IN SOA lan. root.lan. (201605019 ;Serial 4h 1h 1w 1d @ IN NS ns1.lan. @ IN A 192.168.0.100 ns1 IN A 192.168.0.100 slicks IN A 192.168.0.100 site IN A 192.168.0.100 * IN CNAME @

Обратите внимание на Serial 201605019. Это значение нужно увеличивать каждый раз при редактировании файла доменной зоны. Я пишу YY-MM-DD + наращиваю порядковый номер на 1. 192.168.0.100 - IP адрес сервера. Запись формата "slicks IN A" означает, что в зоне.lan существует доменное имя slicks и что этот сайт расположен по IP адресу 192.168.0.100. В apache2 создан, соответственно веб-сайт с ServerName slicks.lan . Если бы сайт располагался на ином IP, чем DNS сервер, то запись бы имела вид slicks IN A _IP-ПК-с-сайтом_ Редактируем named.conf.options :

Nano named.conf.options

В него нужно дописать выделенные строки:

Acl "home" {192.168.0.0/24; 127.0.0.1;}; options { directory "/var/cache/bind"; dnssec-validation auto; allow-recursion {127.0.0.1/32; 192.168.0.0/24; 192.168.1.0/24; }; allow-transfer { none; }; auth-nxdomain no; # conform to RFC1035 listen-on-v6 { none; }; allow-query {"home";}; };

Первая строка создаёт локальную DNS группу home, с диапазоном IP адресов от 192.168.0.0 до 192.168.0.255, а также 127.0.0.1. Вторая добавляемая строка содержит параметр allow-query (разрешить запросы) и мы указываем, что нужно разрешить запросы от группы home. С конфигурацией закончили, можем перезапустить сервер

Sudo /etc/init.d/bind9 restart

Указываем локальный DNS в роутере

Чтобы не было нужды редактировать сетевое подключение на каждом клиенте и вручную прописывать DNS-сервер, мы можем указать IP локального DNS в настройках маршрутизатора. И все запросы пользователей сети будут отправляться последним сперва на локальный DNS, а потом уже уходить в Интернет. У меня:

Для указания локального DNS сервера в моем случае я вхожу в Setup -> Network Settings -> Manual Internet Connection Setup и в поле Primary DNS Address прописываю IP адрес сервера локальной доменной зоны 192.168.0.100, он же будет теперь выступать основным DNS сервером в локальной сети. А в качестве Secondary DNS адреса пишем 8.8.8.8. Это адреса DNS Google. На скрине у меня Primary и Secondary DNS адреса ведут на мой сервер. Почему-то вначале казалось, что роутер не перенаправлял запросы на мой DNS и прописал так. Вторым DNS лучше указать гугловский сервер, чтобы в случае если локальный сервер 192.168.0.100 будет выключен - не пропадал интернет у всех остальных устройств!

Проверка работоспособности

Запускаю клиентский ПК под управлением Windows Xp и тестирую подключение. Первым делом нужно очистить DNS кеш. Заходим в командндую строку виндовс и пишем:

Ipconfig /flushdns

1. Теперь уже проверяю видимость в сети сервера DNS, ping 192.168.0.100 :

C:\\Documents and Settings\\www>ping 192.168.0.100 Обмен пакетами с 192.168.0.100 по 32 байт: Ответ от 192.168.0.100: число байт=32 время<1мс TTL=64 Ответ от 192.168.0.100: число байт=32 время<1мс TTL=64 Ответ от 192.168.0.100: число байт=32 время<1мс TTL=64 Ответ от 192.168.0.100: число байт=32 время<1мс TTL=64 Статистика Ping для 192.168.0.100: Пакетов: отправлено = 4, получено = 4, потеряно = 0 (0% потерь), Приблизительное время приема-передачи в мс: Минимальное = 0мсек, Максимальное = 0 мсек, Среднее = 0 мсек

Проверяю локальный сайт: nslookup slicks.lan :

C:\\Documents and Settings\\www>nslookup slicks.lan *** Can"t find server name for address 192.168.0.1: Non-existent domain *** Default servers are not available Server: UnKnown Address: 192.168.0.1 Name: slicks.lan Address: 192.168.0.100

ping slicks.lan :

C:\\Documents and Settings\\www>ping slicks.lan Обмен пакетами с slicks.lan по 32 байт: Ответ от 192.168.0.100: число байт=32 время<1мс TTL=64 Ответ от 192.168.0.100: число байт=32 время<1мс TTL=64 Ответ от 192.168.0.100: число байт=32 время<1мс TTL=64 Ответ от 192.168.0.100: число байт=32 время<1мс TTL=64 Статистика Ping для 192.168.0.100: Пакетов: отправлено = 4, получено = 4, потеряно = 0 (0% потерь), Приблизительное время приема-передачи в мс: Минимальное = 0мсек, Максимальное = 0 мсек, Среднее = 0 мсек

Наслаждаемся результатами!

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

Общие сведения

Named - это демон, входящий в состав пакета bind9 и являющийся сервером доменных имен . Демон named может реализовывать функции серверов любого типа: master, slave, cache . На приведенной схеме я постарался максимально прозрачно отобразить основной принцип работы DNS сервера BIND . Бинарник, который выполняет основную работу, расположен в /usr/sbin/named . Он берет настройки из основного конфигурационного файла, который называется named.conf и расположен в каталоге /etc/bind . В основном конфиге описывается рабочий каталог асервера , зачастую это каталог /var/cache/bind , в котором лежат файлы описания зон и другие служебные файлы. Соответствие названия зоны и файла описания зоны задает раздел zone с параметром file . Раздел zone так же задает тип ответственности данного сервера за зону (master, slave и др.), а так же определяет особые параметры для текущей зоны (например, на каком интерфейсе обрабатывать запросы для текущей зоны). В файлах описания зон содержатся параметры зон и записи ресурсов (пути, указанные в данном абзаце могут отличаться, это зависит от дистрибутива Linux или параметров ).

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

Формат файла конфигурации для 4-ой версии программы отличается от того, который применяется в восьмой и девятой версиях BIND . Учитывая, что я рассчитываю на установку нового DNS сервера, а старую версию смысла ставить не вижу, посему буду рассматривать конфиг новой версии.

Исходные данные

Для корректной работы DNS нем необходимо иметь . DNS в текущей статье будет настроен на дистрибутиве Debian, особенности других дистрибутивов тоже будут отмечены. Конфиг сети стенда следующий:

Dns:~# cat /etc/network/interfaces auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 10.0.0.152 netmask 255.255.255.0 gateway 10.0.0.254 auto eth1 iface eth1 inet static address 192.168.1.1 netmask 255.255.255.0

где 10.0.0.152/24 - внешний интерфейс (подсеть, выделенная провайдером), 192.168.1.1/24 - внутренний (Локальная сеть). Настраиваемая зона будет иметь имя example.com. В примере со slave сервером , вторичный сервер будет расположен на IP 10.0.0.191 .

Установка BIND9

Для работы DNS сервера необходимо bind9 (в некоторых дистрибутивах - bind ). Как отмечено на схеме - основным конфигурационным файлом BIND является файл named.conf (данный файл может быть размещен в каталоге /etc , иногда в /etc/bind ).

Параметры (синтаксис) named.conf

Синтаксис файла named.conf придерживается следующих правил:

IP-адреса - список IP должен быть разделен символом ";" , возможно указывать подсеть в формате 192.168.1.1/24 или 192.168.1.1/255.255.255.0, (для исключения IP перед ним нужно поставить знак!), возможно указывать имена "any", "none", "localhost" в двойных кавычках.

Комментарии - строки начинающиеся на #, // и заключенные в /* и */ считаются комментариями.

В файлах описания зон - символ @ является "переменной" хранящей имя зоны, указанной в конфигурационном файле named.conf или в директиве @ $ORIGIN текущего описания зоны.

Каждая завершенная строка параметров должна завершаться символом; .

Раздел Acl

Acl (access control list) - позволяет задать именованный список сетей. Формат раздела: acl "имя_сети" {ip; ip; ip; };

Раздел Options

Раздел Options задает глобальные параметры конфигурационного файла, управляющие всеми зонами. Данный раздел имеет формат: options {операторы_раздела_Options}; . Options может быть "вложен" в раздел Zone , при этом он переопределяет глобальные параметры. Часто используемые операторы options :

  • allow-query {список_ip } - Разрешает ответы на запросы только из список_ip . При отсутствии - сервер отвечает на все запросы.
  • allow-recursion {список_ip } - На запросы из список_ip будут выполняться рекурсивные запросы. Для остальных - итеративные. Если не задан параметр, то сервер выполняет рекурсивные запросы для всех сетей.
  • allow-transfer {список_ip } - Указывает список серверов, которым разрешено брать зону с сервера (в основном тут указывают slave сервера)
  • directory /path/to/work/dir - указывает абсолютный путь к рабочему каталогу сервера. Этот оператор допустим только в разделе options.
  • forwarders {ip порт, ip порт.. .} - указывает адреса хостов и если нужно порты, куда переадресовывать запросы (обычно тут указываются DNS провайдеров ISP).
  • forward ONLY или forward FIRST - параметр first указывает, DNS-серверу пытаться разрешать имена с помощью DNS-серверов, указанных в параметре forwarders, и лишь в случае, если разрешить имя с помощью данных серверов не удалось, то будет осуществлять попытки разрешения имени самостоятельно.
  • notify YES|NO - YES - уведомлять slave сервера об изменениях в зоне, NO - не уведомлять.
  • recursion YES|NO - YES - выполнять рекурсивные запросы, если просит клиент, NO - не выполнять (только итеративные запросы). Если ответ найден в кэше, то возвращается из кэша. (может использоваться только в разделе Options)

Раздел Zone

Определяет описание зон(ы). Формат раздела: zone {операторы_раздела_zone }; Операторы , которые наиболее часто используются:

  • allow-update {список_ip } - указывает системы, которым разрешено динамически обновлять данную зону.
  • file "имя_файла " - указывает путь файла параметров зоны (должен быть расположен в каталоге, определенном в разделе options оператором directory)
  • masters {список_ip } -указывает список мастер-серверов. (допустим только в подчиненных зонах)
  • type "тип_зоны " - указывает тип зоны, описываемой в текущем разделе,тип_зоны может принимать следующие значения:
    • forward - указывает зону переадресации, которая переадресовывает запросы, пришедшие в эту зону.
    • hint - указывает вспомогательную зону (данный тип содержит информацию о корневых серверах, к которым сервер будет обращаться в случае невозможности найти ответ в кэше)
    • master - указывает работать в качестве мастер сервера для текущей зоны.
    • slave - указывает работать в качестве подчиненного сервера для текущей зоны.

Дополнительные параметры конфигурации

Значения времени в файлах зон по умолчанию указывается в секундах, если за ними не стоит одна из следующих букв: S - секунды, M - минуты, H- часы, D - дни, W - недели. Соответственно, запись 2h20m5s будет иметь значение 2 часа 20 минут 5 секунд и соответствовать 8405 секунд.

Любое имя хоста/записи, не оканчивающиеся точкой считается неFQDN именем и будет дополнено именем текущей зоны. Например, запись domen в файле зоны examle.com будет развернуто в FQDN-имя domen.examle.com. .

В конфигурационных файлах BIND могут применяться следующие директивы :

  • $TTL - определяет TTL по-умолчанию для всех записей в текущей зоне.
  • $ORIGIN - изменяет имя зоны с указанного в файле named.conf. При этом, область действия данной директивы не распространяется "выше" (то есть если файл включен директивой $INCLUDE, то область действия$ORIGN не распространяется на родительский)
  • $INCLUDE - включает указанный файл как часть файла зоны.

Отдельно хочется описать параметр allow-transfer { 10.0.0.191; }; . Данный параметр описывает серверы, которым разрешено скачивать копию зоны - т.н. slave серверА . В следующем примере мы разберем настройку slave DNS .

Для корректной работы логирования необходимо создать соответствующий каталог и присвоить необходимые права:

Dns:~# mkdir /var/log/bind/ dns:~# chmod 744 /var/log/bind/ dns:~# ps aux | grep named bind 4298 0.0 3.4 46792 13272 ? Ssl Jul05 0:00 /usr/sbin/named -u bind root 4815 0.0 0.1 3304 772 pts/4 S+ 18:19 0:00 grep named dns:~# chown bind /var/log/bind/ dns:~# ls -ld /var/log/bind/ drwxr--r-- 2 bind root 4096 Июл 6 18:18 /var/log/bind/

Dns:~# cat /var/cache/bind/example.com $TTL 3D @ IN SOA ns.example.com. root.example.com. (2011070601 ; serial 8H ; refresh 2H ; retry 2W ; expire 1D) ; minimum @ IN NS ns.example.com. @ IN NS ns2.example.com. @ IN A 10.0.0.152 @ IN MX 5 mx.example.com. ns IN A 10.0.0.152 ns2 IN A 10.0.0.191 mx IN A 10.0.0.152 www IN CNAME @

а так же в домене in-addr.arpa.

Dns:~# cat /var/cache/bind/0.0.10.in-addr.arpa $TTL 3600 @ IN SOA ns.examle.com. root.example.com. (2007042001 ; Serial 3600 ; Refresh 900 ; Retry 3600000 ; Expire 3600) ; Minimum IN NS ns.examle.com. IN NS ns2.example.com. 152 IN PTR examle.com. 191 IN PTR ns.example.com. * IN PTR examle.com. dns:~# cat /var/cache/bind/1.168.192.in-addr.arpa $TTL 3600 @ IN SOA ns.examle.com. root.example.com. (2007042001 ; Serial 3600 ; Refresh 900 ; Retry 3600000 ; Expire 3600) ; Minimum IN NS ns.examle.com. IN NS ns2.example.com. * IN PTR examle.com.

Наша сеть небольшая, предполагается, что в сети совсем мало машин. Все сервисы сети размещены на одном хосте example.com., поэтому и master DNS (ns.example.com.) и почтовый сервер (mx.example.com.) указывает на одну машину (10.0.0.152).

Вторичный (secondary, slave) авторитетный сервер зоны

Основная функция slave сервера - автоматическая синхронизация описания зоны с master сервером. Данная задача регламентируется документом RFC 1034 в разделе 4.3.5. Согласно данному документу обмен данными между серверами рекомендовано производить по , посредством запроса AXFR. По этому запросу за одно TCP соединение должна передаваться вся зона целиком (RFC 1035).

Так же, slave DNS-сервер делит нагрузку с master сервером или принимает на себя всю нагрузку в случае аварии па первом сервере.

Прежде чем приступить к настройке slave DNS сервера , необходимо проверить возможность получения зоны вручную со вторичного сервера с помощью следующей команды:

Root@debian:~# dig @10.0.0.152 example.com. axfr ; <<>> DiG 9.7.3 <<>> @10.0.0.152 example.com. axfr ; (1 server found) ;; global options: +cmd example.com. 259200 IN SOA ns.example.com. root.example.com. 2011070801 28800 7200 1209600 86400 example.com. 259200 IN NS ns.example.com. example.com. 259200 IN NS ns2.example.com. example.com. 259200 IN A 10.0.0.152 example.com. 259200 IN MX 5 mx.example.com. mx.example.com. 259200 IN A 10.0.0.152 ns.example.com. 259200 IN A 10.0.0.152 ns2.example.com. 259200 IN A 10.0.0.191 www.example.com. 259200 IN CNAME example.com. example.com. 259200 IN SOA ns.example.com. root.example.com. 2011070801 28800 7200 1209600 86400 ;; Query time: 14 msec ;; SERVER: 10.0.0.152#53(10.0.0.152) ;; WHEN: Fri Jul 8 15:33:54 2011 ;; XFR size: 11 records (messages 1, bytes 258)

  1. Скопировать конфигурационный файл named.conf с master сервера;
  2. Заменить параметр type master на type slave
  3. Параметр allow-transfer { 10.0.0.191; }; заменить на masters { 10.0.0.152;}; в тех зонах, для которых он будет вторичным;
  4. Удалить зоны , которые не будет обслуживать текущий сервер , в том числе и корневую, если slave не будет отвечать на рекурсивные запросы;
  5. Создать каталоги для логов, как в предыдущем примере.

Итого, мы получаем конфиг slave сервера:

Root@debian:~# cat /etc/bind/named.conf options { directory "/var/cache/bind"; allow-query { any; }; // отвечать на запросы со всех интерфейсов recursion no; // запретить рекурсивные запросы auth-nxdomain no; // для совместимости RFC1035 listen-on-v6 { none; }; // IPv6 нам не нужен version "unknown"; // не отображать версию DNS сервера при ответах }; // нижеописанные зоны определяют сервер авторитетным для петлевых // интерфейсов, а так же для броадкаст-зон (согласно RFC 1912) zone "localhost" { type master; file "localhost"; }; zone "127.in-addr.arpa" { type master; file "127.in-addr.arpa"; }; zone "0.in-addr.arpa" { type master; file "0.in-addr.arpa"; }; zone "255.in-addr.arpa" { type master; file "255.in-addr.arpa"; }; // описание основной зоны zone "example.com" { type slave; file "example.com"; masters { 10.0.0.152; }; }; //описание обратной зоны zone "0.0.10.in-addr.arpa" { type slave; file "0.0.10.in-addr.arpa"; masters { 10.0.0.152; }; }; // настройки логирования logging { channel "misc" { file "/var/log/bind/misc.log" versions 4 size 4m; print-time YES; print-severity YES; print-category YES; }; channel "query" { file "/var/log/bind/query.log" versions 4 size 4m; print-time YES; print-severity NO; print-category NO; }; category default { "misc"; }; category queries { "query"; }; };

после перезапуска наш slave сервер благополучно скопирует необходимую ему информацию с главного сервера, о чем будет говорить наличие файлов в каталоге:

Root@debian:~# ls -la /var/cache/bind/ итого 28 drwxrwxr-x 2 root bind 4096 Июл 8 18:47 . drwxr-xr-x 10 root root 4096 Июл 8 15:17 .. -rw-r--r-- 1 bind bind 416 Июл 8 18:32 0.0.10.in-addr.arpa ...... -rw-r--r-- 1 bind bind 455 Июл 8 18:32 example.com ........

В принципе,/stroallow-transfer {pngp slave сервер может не хранить копию зоны у себя в файловой системе. Эта копия нужна только в момент старта DNS. Наличие копии зоны в файловой системе может избавить от сбоя при недоступности master сервера во время запуска slave DNS. Если не указать опцию file в разделе zone, то копия не создается.

Настройка netfilter () для DNS BIND

Собственно, настроив работу сервера, неплохо было бы его защитить. Мы знаем, что сервер работает на 53/udp порту. Почитав статью о том, и ознакомившись с , можно создать правила фильтрации сетевого трафика:

Dns ~ # iptables-save # типовые правила iptables для DNS *filter:INPUT DROP :FORWARD DROP :OUTPUT DROP -A INPUT -i lo -j ACCEPT -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -m conntrack --ctstate INVALID -j DROP # разрешить доступ локальной сети к DNS серверу: -A INPUT -s 192.168.1.1/24 -d 192.168.1.1/32 -p udp -m udp --dport 53 -m conntrack --ctstate NEW -j ACCEPT -A OUTPUT -o lo -j ACCEPT -A OUTPUT -p icmp -j ACCEPT -A OUTPUT -p udp -m udp --sport 32768:61000 -j ACCEPT -A OUTPUT -p tcp -m tcp --sport 32768:61000 -j ACCEPT -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT # разрешить доступ DNS серверу совершать исходящие запросы -A OUTPUT -p udp -m udp --dport 53 -m conntrack --ctstate NEW -j ACCEPT COMMIT

Это типовой пример! Для задания правил iptables под Ваши задачи и конфигурацию сети, необходимо понимать принцип работы netfilter в Linux, почитав вышеуказанные статьи.

Устранение неполадок

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

Jul 5 18:12:43 dns-server named: starting BIND 9.7.3 -u bind Jul 5 18:12:43 dns-server named: built with "--prefix=/usr" "--mandir=/usr/share/man" "--infodir=/usr/share/info" "--sysconfdir=/etc/bind" "--localstatedir=/var" "--enable-threads" "--enable-largefile" "--with-libtool" "--enable-shared" "--enable-static" "--with-openssl=/usr" "--with-gssapi=/usr" "--with-gnu-ld" "--with-dlz-postgres=no" "--with-dlz-mysql=no" "--with-dlz-bdb=yes" "--with-dlz-filesystem=yes" "--with-dlz-ldap=yes" "--with-dlz-stub=yes" "--with-geoip=/usr" "--enable-ipv6" "CFLAGS=-fno-strict-aliasing -DDIG_SIGCHASE -O2" "LDFLAGS=" "CPPFLAGS=" Jul 5 18:12:43 dns-server named: adjusted limit on open files from 1024 to 1048576 Jul 5 18:12:43 dns-server named: found 1 CPU, using 1 worker thread Jul 5 18:12:43 dns-server named: using up to 4096 sockets Jul 5 18:12:43 dns-server named: loading configuration from "/etc/bind/named.conf" Jul 5 18:12:43 dns-server named: reading built-in trusted keys from file "/etc/bind/bind.keys" Jul 5 18:12:43 dns-server named: using default UDP/IPv4 port range: Jul 5 18:12:43 dns-server named: using default UDP/IPv6 port range: Jul 5 18:12:43 dns-server named: listening on IPv4 interface lo, 127.0.0.1#53 Jul 5 18:12:43 dns-server named: listening on IPv4 interface eth1, 192.168.1.1#53 Jul 5 18:12:43 dns-server named: generating session key for dynamic DNS Jul 5 18:12:43 dns-server named: could not configure root hints from "/etc/bind/db.root": file not found Jul 5 18:12:43 dns-server named: loading configuration: file not found # файл не найден Jul 5 18:12:43 dns-server named: exiting (due to fatal error) Jul 5 18:15:05 dns-server named: starting BIND 9.7.3 -u bind Jul 5 18:15:05 dns-server named: built with "--prefix=/usr" "--mandir=/usr/share/man" "--infodir=/usr/share/info" "--sysconfdir=/etc/bind" "--localstatedir=/var" "--enable-threads" "--enable-largefile" "--with-libtool" "--enable-shared" "--enable-static" "--with-openssl=/usr" "--with-gssapi=/usr" "--with-gnu-ld" "--with-dlz-postgres=no" "--with-dlz-mysql=no" "--with-dlz-bdb=yes" "--with-dlz-filesystem=yes" "--with-dlz-ldap=yes" "--with-dlz-stub=yes" "--with-geoip=/usr" "--enable-ipv6" "CFLAGS=-fno-strict-aliasing -DDIG_SIGCHASE -O2" "LDFLAGS=" "CPPFLAGS=" Jul 5 18:15:05 dns-server named: adjusted limit on open files from 1024 to 1048576 Jul 5 18:15:05 dns-server named: found 1 CPU, using 1 worker thread Jul 5 18:15:05 dns-server named: using up to 4096 sockets Jul 5 18:15:05 dns-server named: loading configuration from "/etc/bind/named.conf" Jul 5 18:15:05 dns-server named: using default UDP/IPv4 port range: Jul 5 18:15:05 dns-server named: using default UDP/IPv6 port range: Jul 5 18:15:05 dns-server named: listening on IPv4 interface lo, 127.0.0.1#53 Jul 5 18:15:05 dns-server named: listening on IPv4 interface eth1, 192.168.1.1#53 Jul 5 18:15:05 dns-server named: automatic empty zone: 254.169.IN-ADDR.ARPA Jul 5 18:15:05 dns-server named: automatic empty zone: 2.0.192.IN-ADDR.ARPA Jul 5 18:15:05 dns-server named: automatic empty zone: 100.51.198.IN-ADDR.ARPA Jul 5 18:15:05 dns-server named: automatic empty zone: 113.0.203.IN-ADDR.ARPA Jul 5 18:15:05 dns-server named: automatic empty zone: 255.255.255.255.IN-ADDR.ARPA Jul 5 18:15:05 dns-server named: automatic empty zone: 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA Jul 5 18:15:05 dns-server named: automatic empty zone: 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA Jul 5 18:15:05 dns-server named: automatic empty zone: D.F.IP6.ARPA Jul 5 18:15:05 dns-server named: automatic empty zone: 8.E.F.IP6.ARPA Jul 5 18:15:05 dns-server named: automatic empty zone: 9.E.F.IP6.ARPA Jul 5 18:15:05 dns-server named: automatic empty zone: A.E.F.IP6.ARPA Jul 5 18:15:05 dns-server named: automatic empty zone: B.E.F.IP6.ARPA Jul 5 18:15:05 dns-server named: automatic empty zone: 8.B.D.0.1.0.0.2.IP6.ARPA Jul 5 18:15:05 dns-server named: zone 0.in-addr.arpa/IN: loaded serial 1 Jul 5 18:15:05 dns-server named: zone 127.in-addr.arpa/IN: loaded serial 1 Jul 5 18:15:05 dns-server named: zone 255.in-addr.arpa/IN: loaded serial 1 Jul 5 18:15:05 dns-server named: zone localhost/IN: loaded serial 2 Jul 5 18:15:05 dns-server named: running # запуск прошел удачно

Отличным инструментом для диагностики являются .

Резюме

В текущей статье я описал настройку основных конфигураций DNS сервера BIND. Целью статьи было - дать представление о работе сервера BIND в UNIX. Я практически не затронул вопросы безопасности ДНС и мало затронул такие специфичные настройки, как работа сервера в пограничном режиме, когда в разные сети отдается разная информация о зоне(нах). Для более глубокого освоения я предоставлю список дополнительных источников, в которых, я надеюсь, удастся получить нужную информацию. На этом ставлю точку. До новых встреч.

Система доменных имен : http://citforum.ru/internet/dns/khramtsov/
RFC 1034 - Domain Names - Concepts and Facilities: http://tools.ietf.org/html/rfc1034
RFC 1035 - Domain Names - Implementation and Specification: http://tools.ietf.org/html/rfc1035
RFC 1537 - Common DNS Data File Configuration Errors: http://tools.ietf.org/html/rfc1537
RFC 1591 - Domain Name System Structure and Delegation: http://tools.ietf.org/html/rfc1591
RFC 1713 - Tools for DNS Debugging: http://tools.ietf.org/html/rfc1713
RFC 2606 - Reserved Top Level DNS Names: http://tools.ietf.org/html/rfc2606
Безопасность DNS (DNSSEC): http://book.itep.ru/4/4/dnssec.htm
BIND 9 Administrator Reference Manual : http://www.bind9.net/manual/bind/9.3.2/Bv9ARM.html
Secure BIND Template : http://www.cymru.com/Documents/secure-bind-template.html
Хорошо расписаны параметры конфига на русском : http://www.bog.pp.ru/work/bind.html
Автоматическое создание файла зоны : http://www.zonefile.org/?lang=en#zonefile

Рассмотрим примерный конфигурационный файл кеширующего DNS -сервера для отдельно стоящего сервера. Кэширующий сервер имён – это сервер имён, не отвечающий ни за какую зону. Он просто выполняет запросы от своего имени и сохраняет результаты для своего последующего использования.
О сетевом сервисе DNS и настройке BIND9 еще можно почитать в Главе 25 Руководства FreeBSD . По умолчанию во FreeBSD используется одна из версий программы BIND (Berkeley Internet Name Domain), являющейся самой распространенной реализацией протокола DNS .

DNS – это протокол, при помощи которого имена преобразуются в IP-адреса и наоборот. FreeBSD в настоящее время поставляется с сервером DNS – BIND9, предоставляющим расширенные настройки безопасности, новую схему расположения файлов конфигурации и автоматические настройки для chroot(8). К тому же BIND9 считается наименее уязвимой для внешних атак (FreeBSD автоматически запускает named в ограниченном окружении (chroot(8))). Эта версия DNS -сервера поддерживает списки управления доступом для запросов, передачи зон подчиненным (вторичным) DNS -серверам, а также динамические обновления своих зон с вышестоящих (первичных) DNS -серверов. Этой версией поддерживается стандарт динамических обновлений и уведомления об изменениях зоны, а так же он использует механизм инкрементальной передачи зоны, позволяющий подчиненным DNS -серверам запрашивать у вышестоящих DNS -серверов только изменения зональных данных. Это позволяет намного ускорить передачу зон.

На момент написания статьи я настраивал BIND 9.6.1-P1 на сервере под управлением FreeBSD 7.2-RELEASE .

# cat /etc/namedb/named.conf // так выглядит комментарий acl self { 127.0.0.1; }; // задаем переменную self, в которой перечислим ip-адреса нашего сервера,\ на которых будет работать bind acl trust { self; }; // задаем переменную, в которой перечислим ip-адреса, с которых будет разрешено\ посылать запросы через наш DNS-сервер // секция глобальных параметров options { directory "/etc/namedb"; // рабочий каталог bind, относительно которого ниже мы будем обозначать\ остальные каталоги pid-file "/var/run/named/pid"; // pid-файл dump-file "/var/dump/named_dump.db"; // расположение dump-файла корневой зоны при временной потере\ доступа ко всем корневым серверам statistics-file "/var/stats/named.stats"; // расположение файла статистики listen-on { self; }; // указываем bind на каких интерфейсах работать listen-on-v6 { none; }; // запрещаем использовать IPv6 version "Hello, pal!"; // здесь вы можете указать версию вашего bind (для безопасности рекомендуют\ этого не делать) allow-query { self; }; // от кого разрешаем принимать запросы forwarders { 12.34.56.78; }; // для снижения нагрузки на свой сервер вы можете указать тут DNS-сервера\ своего провайдера }; ...

Теперь предлагаю немного отвлечься от настройки файла named.conf . Предлагаю вам рассмотреть интересный способ удаленного администрирования вашим DNS -сервером – утилита rndc . Для того, чтобы начать ей пользоваться, вам необходимо создать для нее конфигурационный файл и секретный ключ, с помощью которых она будет взаимодействовать с вашим bind. Для это задачи существует команда rndc-confgen .
Выполняя команду:

# rndc-confgen

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

# Start of rndc.conf key "rndc-key" { algorithm hmac-md5; secret "34f88008d07deabbe65bd01f1d233d47"; }; options { default-key "rndc-key"; default-server 127.0.0.1; default-port 953; }; # End of rndc.conf # # Use with the following in named.conf, adjusting the allow list as needed: # key "rndc-key" { # algorithm hmac-md5; # secret "34f88008d07deabbe65bd01f1d233d47"; # }; # # controls { # inet 127.0.0.1 port 953 # allow { 127.0.0.1; } keys { "rndc-key"; }; # }; # End of named.conf

Незакомментированную часть вывода помещаете в файл /etc/namedb/rndc.conf

# cat /etc/namedb/rndc.conf key "rndc-key" { algorithm hmac-md5; secret "34f88008d07deabbe65bd01f1d233d47"; }; options { default-key "rndc-key"; default-server 127.0.0.1; default-port 953; };

Закомментированную часть вывода команды rndc-confgen помещаете в конфигурационный файл /etc/namedb/named.conf :

Key "rndc-key" { algorithm hmac-md5; secret "34f88008d07deabbe65bd01f1d233d47"; }; controls { inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { "rndc-key"; }; }; ...

В результате работы команды rndc-confgen в каталоге /etc/namedb/ должен появиться файл rndc.key , со следующим содержимым:

# cat /etc/namedb/rndc.key key "rndc-key" { algorithm hmac-md5; secret "34f88008d07deabbe65bd01f1d233d47"; };

Если у вас уже существовал там ключ, удалите его и замените новым.
Во всех случаях строчка secret “34f88008d07deabbe65bd01f1d233d47”; у вас должна быть одинаковой! Значение secret сгенерировала команда rndc-confgen .
Проверить сделанную вами работу вы сможете, когда полностью настроите свой DNS -сервер и запустите его. Тогда, при выполнении команды:

# rndc status

если вы увидите что-то похожее на:

Version: 9.6.1-P1 (Hello, pal!) CPUs found: 2 worker threads: 2 number of zones: 14 debug level: 0 xfers running: 0 xfers deferred: 0 soa queries in progress: 0 query logging is OFF recursive clients: 0/0/1000 tcp clients: 0/100 server is up and running

— значит утилита rndc успешно подключилась к вашему bind, авторизовалась с помощью ключа, который мы только что создали, и запросила у bind статус DNS -сервера, что вам и показали.

Существует множество полезных ключей, с помощью которых данная утилита позволит вам мониторить и управлять вашим DNS -сервером. Достаточно запустить ее без аргументов и вы увидите доступные команды и помощь по ним. (Советую сразу же создать дамп-файл командой rndc dumpdb ).

Продолжим пояснения по конфигурационному файлу /etc/namedb/named.conf :

Zone "." { type hint; file "named.root"; //как получить актуальный файл корневой зоны написано ниже }; zone "0.0.127.in-addr.arpa" { type master; file "master/localhost.rev"; notify no; }; ...

Файл localhost.rev выглядит примерно так:

# cat /etc/namedb/master/localhost.rev $TTL 3600 @ IN SOA host.your_domain.ru. root.host.your_domain.ru. (2009110601 ; Serial 3600 ; Refresh 900 ; Retry 3600000 ; Expire 3600) ; Minimum IN NS host.your_domain.ru. 1 IN PTR localhost.your_domain.ru.

Следующими настройками мы будем собирать и записывать логи bind в различные фалы. Формат секции записи логов по каналам имеет вид:

Channel имя-канала { (file имя-файла [ versions (число | unlimited) ] [ size максимальный-размер ] | syslog syslog_facility | stderr | null); // мы тут будем указывать имя файла, в который будем писать логи этого канала (относительно\ рабочего каталога); количество версий файлов логов; размер файла, при котором\ происходит перенумерация файла лога. если количество версий указано не будет, логирование\ прекратиться по достижению указанного размера файла. [ severity (critical | error | warning | notice | info | debug [ уровень ] | dynamic); ] // фильтр логов, кукую именно информацию мы будем заносить\ в этот канал [ print-category yes-или-no; ] // заносим или нет в лог тип категории события [ print-severity yes-или-no; ] // заносим или нет в лог тип "серьезности" собфтия [ print-time yes-или-no; ] // заносим или нет в лог время события };

Итак – это мои настройки в файле /etc/namedb/named.conf :

Logging { // параметры логирования channel default_ch { // обозначаем канал логирования default_ch file "/var/log/named.log" versions 3 size 800k; severity info; print-time yes; print-category yes; }; channel security_ch { // обозначаем канал логирования security_ch file "/var/log/security.log" versions 3 size 800k; severity info; print-time yes; print-category yes; }; channel transfer_ch { // обозначаем канал логирования transfer_ch file "/var/log/transfer.log" versions 3 size 800k; severity info; print-time yes; print-category yes; }; channel lame-ch { // обозначаем канал логирования lame-ch file "/var/log/lamers.log" versions 3 size 800k; severity info; print-time yes; print-category yes; }; category lame-servers { lame-ch; }; // пишем в канал lame-ch события от "кривых" DNS-серверов category default { default_ch; }; // пишем в канал default_ch все, для чего нет собственного канала category security { security_ch; }; // пишем в канал security_ch о событиях безопасности category xfer-in { transfer_ch; }; // пишем в канал transfer_ch об отдаче зон category xfer-out { transfer_ch; }; // пишем в канал transfer_ch о приеме зон category notify { transfer_ch; }; // пишем в канал transfer_ch уведомления и факты регистрации };

Теперь, после окончания настройки bind, вам осталось только с помощью команды wget или fetch получить актуальный файл корневой зоны (named.root) с сервера:

# fetch ftp://ftp.internic.net/domain/named.root

и положить его в каталог /etc/namedb/ с заменой существующего. Желательно периодически повторять эту процедуру, или настроить эту операцию через cron.

Теперь настало время запустить наш DNS -сервер:

/etc/rc.d/named start

Проверяем работу утилитой rndc , как было описано выше.

Для начала выполните команду:

# ps -ax | grep named 476 ?? Is 0:01,19 /usr/sbin/syslogd -l /var/run/log -l /var/named/var/run/log -s 704 ?? Is 0:00,04 /usr/sbin/named -t /var/named -u bind 1022 p0 R+ 0:00,00 grep named

Если вы видите примерно это же – то процесс запущен.
Для пущей уверенности можно выполнить следующую команду (если она у вас есть):

# lsof -i tcp | grep LISTEN | grep named named 704 bind 20u IPv4 0xc845a000 0t0 TCP localhost:domain (LISTEN) named 704 bind 21u IPv4 0xc449a740 0t0 TCP localhost:rndc (LISTEN) named 704 bind 20u IPv4 0xc845a000 0t0 TCP localhost:domain (LISTEN) named 704 bind 21u IPv4 0xc449a740 0t0 TCP localhost:rndc (LISTEN) named 704 bind 20u IPv4 0xc845a000 0t0 TCP localhost:domain (LISTEN) named 704 bind 21u IPv4 0xc449a740 0t0 TCP localhost:rndc (LISTEN) named 704 bind 20u IPv4 0xc845a000 0t0 TCP localhost:domain (LISTEN) named 704 bind 21u IPv4 0xc449a740 0t0 TCP localhost:rndc (LISTEN) named 704 bind 20u IPv4 0xc845a000 0t0 TCP localhost:domain (LISTEN) named 704 bind 21u IPv4 0xc449a740 0t0 TCP localhost:rndc (LISTEN)

Теперь надо настроить наш сервер на работу с только что установленным DNS -сервером. Для этого вам необходимо внести изменения в файл /etc/resolv.conf . Приведите его к следующему виду:

# cat /etc/resolv.conf domain your_domain.ru nameserver 127.0.0.1

В комплекте с сервером BIND9 поставляются утилиты DNS dig , host и nslookup для исследования доменного пространства. С их помощью мы проверим, как работает только что настроенный и запущенный вами DNS -сервер.

Утилита host позволяет получать значения RR указанного типа для указанного доменного имени. Формат вызова:
host [ -управляющие-ключи ] [ -ключи-запроса ] доменное-имя-или-адрес [ опрашиваемый-сервер ] .

По умолчанию, используется сервер, описанный при настройке клиентской библиотеки. Доменные имена считаются абсолютными и список поиска не используется. Более подробная информация на man host .

Утилита dig позволяет получать значения RR указанного типа для указанного доменного имени в формате файла зоны. В виде комментариев выдается масса вспомогательной информации, в т.ч. интерпретация пакета, полученного в ответ на запрос. Формат вызова:
dig [ @опрашиваемый-сервер ] [ -опции-dig ] доменное-имя [ тип-записи ] [ класс-записи ] [ +опции-запроса ]

По умолчанию, используется сервер, описанный при настройке клиентской библиотеки. Доменные имена считаются абсолютными и список поиска не используется. В качестве требуемого типа записи можно использовать также псевдотипы AXFR (зона передается только от уполномоченного сервера), ixfr=опорный-номер-версии и ANY , по умолчанию: A. В одной командной строке можно сделать несколько запросов.

Утилита nslookup объявлена устаревшей и навязчиво напоминает об этом при каждом запуске (даже документация не поставляется, отсутствует команда help и некоторые другие). Формат вызова:
nslookup [ -ключи ] доменное-имя [ опрашиваемый-сервер ]

Выполните команду:

# dig @127.0.0.1 ya.ru ; <<>> DiG 9.6.1-P1 <<>> @127.0.0.1 ya.ru ; (1 server found) ;; global options: +cmd ;; Got answer: ;; >>HEADER<< opcode: QUERY, status: NOERROR, id: 51090 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;ya.ru. IN A ;; ANSWER SECTION: ya.ru. 2843 IN A 213.180.204.8 ya.ru. 2843 IN A 77.88.21.8 ya.ru. 2843 IN A 93.158.134.8 ;; AUTHORITY SECTION: ya.ru. 2843 IN NS ns1.yandex.ru. ya.ru. 2843 IN NS ns5.yandex.ru. ;; ADDITIONAL SECTION: ns1.yandex.ru. 79700 IN A 213.180.193.1 ns5.yandex.ru. 79701 IN A 213.180.204.1 ;; Query time: 2 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Dec 4 14:04:11 2009 ;; MSG SIZE rcvd: 146

Если в результате ее работы вы видите примерно тоже самое – значит вам DNS -сервер отработал команду правильно.

Теперь выполните команду:

# host ya.ru ya.ru has address 77.88.21.8 ya.ru has address 93.158.134.8 ya.ru has address 213.180.204.8 ya.ru mail is handled by 10 mx.yandex.ru.

Если ваш DNS -сервер ответил примерно таким образом – значит он работает правильно!

Если данные команды не вернули никаких результатов, надо смотреть лог /var/log/messages на предмет ошибок, которые заносит туда ваш bind. Анализируя их, постарайтесь понять, с чем связана некорректная работа DNS -севера. Основным недосмотром является неправильная настройка сетевых файерволов.

В заключении хочу сказать о некоторых встроенных в bind командах диагностики.

  • named-checkzone – проверяет синтаксис и целостность файлов зон. Такие же проверки выполняются каждый раз перед их загрузкой bind’ом. Но считаю полезным все-таки это делать перед их загрузкой сервером имен.
  • named-compilezone – выполняет более строгие проверки, чем named-checkzone, т.к. в результате ее работы сформируется дамп актуальных зон, который в свою очередь будут использоваться named.
  • named-checkconf – утилита проверки файла-конфигурации named.conf

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

Итак, планы на сегодня!

  1. Настройка зоны мастер.
  2. Подключение зон в слейве.
  3. Каждому свое. Настраиваем параметры в зависимости от адреса клиента, с которого пришел запрос.
  4. Подключаем внешний DNS-фильтр.

Интро

Когда я устроился на работу, количество сервисов в нашей сети можно было пересчитать по пальцам одной руки. Время шло, число сервисов росло. Обслуживающий DNS-сервер был один и выступал мастером для одной зоны (назовем ее xak.ru). Все остальные запросы он просто пересылал на DNS-сервер Google (8.8.8.8). А, чуть не забыл добавить: сервер этот был виртуальным. Потом в один прекрасный день сервер рухнул физически. После замены систему подняли, виртуализацию прикрутили. Поставили свежеустановленный Debian и к нему BIND 9. Присвоили тот же IP, что был у DNS-сервера до падения. Настройки восстановили из бэкапа. После успешного старта стали думать, как «закручивать болты».

Параллельно с этой работой был установлен хостинг, который держал на себе зону (например) xaker.ru. Само собой, центральный DNS должен о ней знать, а еще лучше быть slave DNS-сервером для этой зоны. Далее возникла необходимость перенаправлять DNS-запросы от центрального сервера к редиректору в зависимости от того, из какой сети пришел запрос. Делалось это ради подключения внешних DNS-фильтров, но не для всех. А только для тех, кому надо, а именно образовательных городских сетей - территории образовательных учреждений! Обо всем этом и пойдет речь ниже.

Немного теории

Если хочешь познакомиться с «новым» BIND, то рекомендую к чтению . В двух словах: версия 9 была последней, с 10-й версии права передают сообществу, и это ПО ныне известно как Bundy.

Быстрая установка, или еще раз об одном и том же

Итак, как установить BIND 9 в Debian/Ubuntu, в Сети очень и очень много материала. Так что быстро пройдемся по этому пункту, не вдаваясь в подробности. Для начала необходимо установить BIND 9 в систему. Для пользователей MS Windows есть версия BIND 9 под их платформу.

$ sudo apt install bind9

Для других дистрибутивов руководств по сборке из исходных кодов на просторах Сети предостаточно, забирай быстрее, переписывай в блокноты, пока новый «суперполезный» закон не накрыл весь интернет или пока тебя не отругали за то, что ты ходишь или ходил на сайт с запрещенной литературой. 😉

После установки переходим в каталог /etc/bind9/ и видим там основной файл конфигурации named.conf , внутри подключены остальные файлы named.conf.* . Как настраивать мастер-зону, опустим, поскольку в Сети информация изложена очень подробно. Добавим в файл named.conf строку

Include "/etc/bind/named.conf.acl";

чем подключим новый файл в конфиг для правил подсетей. Далее создаем файл /etc/bind/named.conf.acl и добавляем правила:

Acl "lan" { 192.168.181.0/24; }; acl "do" { 10.0.0.0/24; 192.168.253.0/24; }; acl "srv" { 192.168.254.0/24; }; acl "alls" { 10.10.0.0/16; }; acl "dou" { 192.168.201.0/24; 192.168.202.0/24; 192.168.203.0/24; 192.168.204.0/24; 192.168.205.0/24; }; acl "school" { 172.16.0.0/24; };

Здесь мы разделили сети на группы для дальнейшей обработки. Прежде чем продолжим, уточню один момент. Для корректной обработки зон необходимо в каждую группу правил добавлять все зоны. Можно это делать в одном файле или вынести настройки зоны в отдельный файл и потом просто подключать в нужных местах. Итак, в файл /etc/bind/named.conf.local вносим изменения:

View "edu" { match-clients { school; }; recursion yes; allow-query { school; }; forwarders { 77.88.8.7; }; zone "xaker.ru" { type master; file "/etc/bind/xaker.ru_loc"; }; zone "254.168.192.in-addr.arpa." { type master; file "/etc/bind/xaker.rev"; }; zone "zone2.ru" { type slave; file "/etc/bind/db.zone2.ru"; masters { 192.168.254.5; }; }; };

Здесь мы обозначаем группу, с которой будет работать BIND. Добавляем сюда клиенты из правил, которые мы определили выше. Назначаем вышестоящий сервер, на который будут пересылаться запросы, пришедшие из сетей, согласно описанным правилам. Здесь это единственная группа адресов School. В качестве вышестоящего DNS задал DNS-сервер Яндекс, который фильтрует «плохой» контент. Можно аналогично использовать другие DNS-сервисы, такие как SkyDNS.

Продолжение доступно только подписчикам

Вариант 1. Оформи подписку на «Хакер», чтобы читать все материалы на сайте

Подписка позволит тебе в течение указанного срока читать ВСЕ платные материалы сайта. Мы принимаем оплату банковскими картами, электронными деньгами и переводами со счетов мобильных операторов.