Добавление вторичной зоны в bind. настройка вторичной зоны в dns-сервере bind

Windows серверов 2000 и Windows Server 2003

На Windows серверов-членов 2000 Server и Windows Server 2003 Корпорация Майкрософт рекомендует настроить параметры клиентов DNS в соответствии с этими спецификациями:

Настройте основные и вторичные параметры клиентов DNS, чтобы указать на локальные первичные и вторичные DNS-серверы (если доступны локальные DNS-серверы), на которые размещена зона DNS для домена Active Directory компьютера.
Если локальных DNS-серверов нет, указать на DNS-сервер для домена Active Directory этого компьютера, который можно связать с помощью надежной WAN-ссылки. Надежность определяется временем и пропускной способностью.
Не настраивайте параметры клиентских DNS для указать на DNS-серверы вашего isP. В этом случае могут возникнуть проблемы при попытке присоединиться к серверу Windows 2000 или Windows Server 2003 в домен или при попытке войти в домен с этого компьютера. Вместо этого внутренний DNS-сервер должен переадружать на DNS-серверы isP для разрешения внешних имен.

Вариант простой настройки «Локальный сервер DNS»

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

Для примера, предположим, что у нас есть

домен l
сервер DNS в этом домене с именем и адресом
компьютер host в этом домене с именем и адресом

Настройка конфигурации bind:

на сервере DNS файл конфигурации /etc/bind/named.conf.options используем из предыдущего примера:

forwarders {
	8.8.8.8;
	8.8.4.4;
};

listen-on {
	127.0.0.1;
	192.168.32.211;
};

dnssec-validation False;

внесём информацию о домене в файл конфигурации /etc/bind/named.conf.local. Исходно в этом файле содержатся только комментарии. Добавляем следующие строки:

zone "localnet.example.ru"    {                    # имя прямой зоны
    type master;                                    # тип master указывает, что запросы относительно этой зоны будут обрабатываться этим сервером, и перенаправляться не будут
    file "/etc/bind/zones/db.localnet.example.ru"; # путь к файлу данных прямой зоны
};

zone "32.168.192.in-addr.arpa" {                    # имя реверсивной зоны. Имя реверсивной зоны формируется из адреса сети, с обратным порядком чисел.
    type master;                                    # тип master указывает, что запросы, относящиеся к этой зоне, будут обрабатываться этим сервером, и перенаправляться не будут
    file "/etc/bind/zones/db.32.168.192";           # подсеть 192.168.32.0/24, путь к файлу данных
};

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

sudo mkdir /etc/bind/zonessudo cp /etc/bind/db.local /etc/bind/zones/db.localnet.example.rusudo cp /etc/bind/db.127 /etc/bind/zones/db.32.168.192sudo chown -R bind:bind /etc/bind/zones

вносим изменения в файл прямой зоны /etc/bind/zones/db.localnet.example.ru:

$TTL    604800
@       IN      SOA     dns.localnet.example.ru. admin.localnet.example.ru. (
                              3         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
; name servers - NS records - определяем имена DNS-серверов
        IN      NS      dns.localnet.example.ru.
; name servers - A records - определяем адреса компьютеров, сначала сервер(ы) DNS
dns.localnet.example.ru.           IN      A      192.168.32.211
; 192.168.32.0/24 - A records - а потом все остальные компьютер(ы) сети
host.localnet.example.ru.          IN      A      192.168.32.96

вносим измения в файл /etc/bind/zones/db.32.168.192 реверсивной зоны:

$TTL    604800
@       IN      SOA     localnet.example.ru. admin.localnet.example.ru. (
                              3         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL ;

; name servers
      IN      NS      dns.localnet.example.ru.
; PTR Records
211 IN      PTR     dns.localnet.example.ru.    ; 192.168.32.211
96  IN      PTR     host.localnet.example.ru.   ; 192.168.32.96

проверяем созданную конфигурацию с помощью соответствующих инструментов :

named-checkconfnamed-checkzone localnet.example.ru /etc/bind/zones/db.localnet.example.runamed-checkzone 32.168.192.in-addr.arpa /etc/bind/zones/db.32.168.192

и перезапускаем службу:

systemctl restart bind9

Проверить работу сервера можно выполнив на сервере команду:

dig @localhost host.localnet.example.ru

Setting up the Secondary DNS Servers

Install Windows, name the box and give it an IP address.

Next add the DNS Server role to the server, once it is added, open the DNS console. This should be familiar as these are the steps we’ve already completed with setting up the master DNS server:

Figure 13: Step 13 of migrating a Linux BIND name server to a Windows Server DNS server.

Right-click on Forward Lookup Zones and then add the first domain. Again, in my example, I am using carttan.ca:

Figure 14: Step 14 of migrating a Linux BIND name server to a Windows Server DNS server.

Click Next:

Figure 15: Step 15 of migrating a Linux BIND name server to a Windows Server DNS server.

Click on Secondary Zone and click Next. The steps to follow are identical to what we first completed when we setup the first Windows Server prior to making it a master server.

Check that the records are coming across properly. Repeat these steps for each domain that needs to be migrated.

Create a new record for your external DNS servers. These need to be addresses that are externally routable (which I have not used in my example here), next add them into your DNS servers in the Name Servers tab removing the one server that is listed for internal. In my example I only have one server showing up now:

Figure 16: Step 16 of migrating a Linux BIND name server to a Windows Server DNS server.

As you can see in the above example, there is no mention of ns1.carttan.ca which is the master server for these domains. Next let’s turn off DNS resolution for any domain which we do not host. Right click on the name of the server and go to the advanced tab. Check Disable recursion:

Figure 17: Step 17 of migrating a Linux BIND name server to a Windows Server DNS server.

The final steps to complete are changing your internet registration files so that the DNS servers are pointed to the new external servers.

Проверка работы dnscrypt-proxy

Я уже упоминал, что благодаря кэшированию, повторные DNS запросы обрабатываются быстрее. Для проверки можно выполнить два раза подряд команду:

time dig kali.tools +short

Первый ответ получен через 0,047s, а второй всего через 0,006s. Конечно, это только доли секунды, но всё равно хорошо. К тому же, вы реже будете сталкиваться с ситуацией, когда браузер «задумался» во время запроса из-за того, что по какой-то причине некоторые DNS ответы идут слишком долго или вовсе потеряны.

Можно проверить, сколько идёт запрос «напрямую», без DoH:

time dig kali.tools +short @8.8.8.8

В моём случае это 0,058s-0,094s с периодическими таймаутами, видимо, задержка на СОРМ. Видимо, зашифрованный трафик пропускается «как есть», а незашифрованный проходит какую-то обработку, вроде как проверку доменов/IP по реестру запрещённых сайтов и т. п. Больше шифрования — больше скорости!

Запустите Wireshark и начните захват трафика. Через некоторое время проверьте с использованием фильтра

dns

Там должно быть пусто, совсем.

Также с помощью фильтра посмотрим на пакеты, которые уходят к DNS серверу и возвращаются от него:

ip.addr == 8.8.8.8

Как можно увидеть на скриншоте, всё зашифровано, теперь у Интернет-провайдера и других посредников нет никакой возможности узнать или изменить содержимое DNS запросов и ответов.

Как настроить dnscrypt-proxy

Настройка dnscrypt-proxy выполняется с помощью файла dnscrypt-proxy.toml. В Windows этот файл расположен по пути C:\dnscrypt-proxy\dnscrypt-proxy.toml, а в Linux это файл /etc/dnscrypt-proxy/dnscrypt-proxy.toml. Независимо от операционной системы, настройка делается одинаково.

Откройте этот файл любым текстовым редактором, например, в Linux:

sudo gedit /etc/dnscrypt-proxy/dnscrypt-proxy.toml

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

Чтобы после редактирования файла dnscrypt-proxy.toml изменения вступили в силу, выполните следующую команду.

Для Windows:

C:\dnscrypt-proxy\dnscrypt-proxy -service restart

Для Linux:

sudo systemctl restart dnscrypt-proxy.service

Чтобы понять, что настраивать, немного информации о том, как работает dnscrypt-proxy. Для преобразования имён в IP адреса dnscrypt-proxy скачивает большой список DNS серверов и в фоне проверяет их доступность и скорость отклика. Запросы делаются к разным DNS серверам в зависимости от скорости отклика и алгоритмов балансировки нагрузки. Это можно изменить — например, можно выбрать определённое имя или несколько имён и указать его (или их) в директиве server_names. Если директива server_names пустая, то будут использоваться все сервера. Если в директиве server_names указано одно или более имён DNS серверов, то будут использоваться только эти сервера.

К примеру, я предпочитаю DNS сервер Google, тогда значение моей директивы:

server_names =

Если хотите сразу несколько DNS серверов, то укажите их используя следующий синтаксис:

server_names =

Чтобы узнать, какие сервера выбраны для использования, выполните команду.

В Windows:

C:\dnscrypt-proxy\dnscrypt-proxy -list

В Kali Linux:

/usr/sbin/dnscrypt-proxy -list -config /etc/dnscrypt-proxy/dnscrypt-proxy.toml

В Arch Linux, BlackArch:

dnscrypt-proxy -list -config /etc/dnscrypt-proxy/dnscrypt-proxy.toml

Директива listen_addresses устанавливает порт и IP адрес для прослушивания. Обычно, нет необходимости здесь что-то менять. Для работы с сокетами устанавливается следующее значение:

listen_addresses = []

Установите fallback_resolvers на

fallback_resolvers =

Если вам зачем-то нужно вести журнал сделанных запросов, то найдите и раскомментируйте следующие строки:


file = '/var/log/dnscrypt-proxy/query.log'

Как добавить DNS сервер в исключение

Предположим, вы хотите использовать полный список DNS серверов, но хотите исключить некоторые из них. К примеру, как написали в комментарии, в данный момент у сервера rdns.faelix.net просрочен сертификат, что приводит к выводу предупреждений от антивирусного ПО. По этой причине мы хотим исключить данный сервер из списка используемых.

Это можно сделать с помощью директивы disabled_server_names, в качестве её значения нужно перечислить имена серверов, которые нужно избегать даже если они удовлетворяют всем критериям.

В первую очередь нам нужно знать имя проблемного DNS сервера. Для этого перейдите на страницу https://dnscrypt.info/public-servers

Внизу найдите выпадающий список «Rows per page» (Строк на страницу) и выберите там «All» (Все).

Нажмите в веб-браузере Ctrl+f для поиска по странице. Мы знаем, что проблемный адрес rdns.faelix.net, попробуем поискать по части имени «faelix»:

Итак, имена IPv4 DNS серверов это faelix-ch-ipv4 и faelix-uk-ipv4.

В файле настроек найдите disabled_server_names и добавьте имена туда:

disabled_server_names =

Если вы используете IPv6 подключение, то также добавьте в список исключений и IPv6 имена.

Сохраните файл настроек и перезапустите службу dnscrypt-proxy.

Документация по настройке dnscrypt-proxy на русском

На странице карточки программы размещён пример конфигурационного файла dnscrypt-proxy с объяснением всех опций и переводом комментариев на русский язык: https://kali.tools/?p=5964

Упаковка

Сервер	Создатель	Стоимость ( долл. США )	Открытый исходный код	Лицензия на программное обеспечение
СВЯЗЫВАТЬ	Консорциум Интернет-систем	Бесплатно	да	BSD , MPL 2.0 для 9.11+
Microsoft DNS	Microsoft	Входит в состав Windows Server	Нет	Лицензия Clickwrap
djbdns	Дэниел Дж. Бернштейн	Бесплатно	да	Всеобщее достояние
Dnsmasq	Саймон Келли	Бесплатно	да	GPL
Простой DNS Plus	Программное обеспечение JH	79–379 долларов	Нет	Лицензия Clickwrap
НРД	NLnet Labs	Бесплатно	да	Вариант BSD
Узел DNS	CZ.NIC	Бесплатно	да	GPL
Узел резольвер	CZ.NIC	Бесплатно	да	GPL
PowerDNS	PowerDNS.COM BV / Берт Хьюберт	Бесплатно	да	GPL
MaraDNS	Сэм Тренхолм	Бесплатно	да	Вариант BSD
pdnsd	Томас Моэстл и Пол Ромбоутс	Бесплатно	да	GPL
Посадис	Мейлоф Вининген	Бесплатно	да	GPL
Несвязанный	NLnet Labs	Бесплатно	да	BSD
ЯДИФА	EURid	Бесплатно	да	BSD
Secure64 DNS Authority	Secure64	Неопубликованная цена	Нет	Лицензия Clickwrap
Secure64 DNS-кеш	Secure64	Неопубликованная цена	Нет	Лицензия Clickwrap
DNS-сервер Technitium	Технитум	Бесплатно	да	GPL

windows XP — Настройка DNS

2. В открывшимся окне «Панели управления» выберите «Сетевые подключения»

3. Выберите подключение, которое вы используете для выхода в Интернет.

4. Нажмите кнопку свойства.

5. Выберите «Протокол Интернета (TCP/IP)» и нажмите кнопку «Свойства».

6. В нижней части окна, выберите пункт «Использовать следующие адреса DNS-серверов«, введите наши адреса и нажмите кнопку «Ок».

1. Нажмите кнопку «Пуск», выберите «Панель управления».

2. В открывшимся окне «Панели управления» выберите «Сетевые подключения»

3. Выберите подключение, которое вы используете для выхода в Интернет.

4. Нажмите кнопку свойства.

5. Выберите «Протокол Интернета (TCP/IP)» и нажмите кнопку «Свойства».

6. В нижней части окна, выберите пункт «Использовать следующие адреса DNS-серверов», введите наши адреса и нажмите кнопку «Ок».

Добавление записи для подтверждения владения доменом, если это еще не сделано

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

Примечание

Эта запись используется только для проверки принадлежности домена. Она не используется для других целей.

Сбор сведений из Корпорации Майкрософт.
В Центре администрирования перейдите на страницу Settings (Параметры) > Domains (Домены).
На странице Домены в столбце Действия для проверяемой области выберите настройку Начните.
На странице Добавление домена в Microsoft выберите Начните шаг 1.
На странице Подтверждение того, что у вас есть страница домена, в инструкции см. инструкции по выполнению этого шага со списком drop-down выберите Общие инструкции.
Из таблицы скопируйте значение Destination или Points to Address. Он понадобится для следующего шага. Рекомендуется скопировать и вклеить это значение, чтобы все интервалы оставались правильными.

Добавьте запись TXT.

На странице Диспетчер DNS для домена перейдите в текст действия > (TXT).
В диалоговом окне Запись новых ресурсов выберите Изменить.
В области Настраиваемые имена хостов в диалоговом окне Запись новых ресурсов убедитесь, что поля задают точно следующие значения.

Важно!

В некоторых версиях Windows DNS Manager домен может быть настроен таким образом, что при создании записи txt домашнее имя по умолчанию передается в родительский домен. В этой ситуации при добавлении записи TXT установите имя хозяина пустым (без значения), а не настроив его на @ или доменное имя.

Имя хозяина: @
Тип: TXT
Адрес: вклеить значение Destination или Points to Address, которое вы только что скопировали из Microsoft здесь.
Выберите ОК > Готово.

Проверка домена в Microsoft.

Важно!

Подождите около 15 минут, прежде чем сделать это, так что запись, созданная вами, может обновляться через Интернет.

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

В центре администрирования перейдите на страницу Setup > Domains.
На странице Домены в столбце Действие для проверяемой области выберите Начните настройку.
На странице Подтверждение того, что у вас есть страница домена, выберите сделано, проверьте сейчас, а затем в диалоговом окне подтверждения выберите Готово.

Примечание

Обычно на вступление изменений DNS в силу требуется около 15 минут. Однако иногда распространение внесенного изменения в системе DNS по всему Интернету занимает больше времени. Если после добавления записей DNS возникла проблема с потоком обработки почты или другие неполадки, см. статью Устранение неполадок после смены имени домена или записей DNS.

Проверка

Чтобы проверить, отдает ли наш сервер bind ответы с цифровыми подписями, вводим команду:

dig mail.dmosk.ru +dnssec

* в данном примере мы запросили IP-адрес для записи mail.dmosk.ru. +dnssec означает, что также клиент запрашивает RRSIG для этой записи.

Мы должны увидеть записи вместе с их RRSIG, например:

mail.dmosk.ru. 14400 IN A 192.168.1.5
mail.dmosk.ru. 14400 IN RRSIG A 5 3 14400 20171101123749 20170927123749 24195 dmosk.ru. JfR+P1GYYA0r9OGVE43WJfK9ByIODN8pKAcoEGHdWlaGAEJK8/toFEBX ODDuYM83N7jptZUXzv7MR5RQyRZb+t5/l+umQ4FSHtOc2PcrJA1mvY7j EGSccsWPv9k3XdzN1v9ies+eINE9tr7ObvS4CUN97t80SzhWSP6AIvsR 0152zUAIs3yQYfumbo6oV62oUGp4bYnj0VXJ2096hRP8NRGPjxoG/Spj fEzmlmiA4tzYJhdEKNcNtw04Z8NPP5+UcnHBNrqm0la0opqSR6SXQiSV CL5OfMxOBeK3XuRtMobbB/2iPFRr+muclB9YT/5nt9elEl6RtegBpefh gfZ44A==

С Windows можно проверить с помощью Powershell:

* где 192.168.0.15 — адрес сервера bind с настроенным dnssec.

Подпись зоны

Копируем содержимое ключей в файл зоны:

cat Kdmosk.ru.*key >> /var/named/master/dmosk.ru

* где Kdmosk.ru.*key — все ключи для домена dmosk.ru; /var/named/master/dmosk.ru — путь к файлу с настройкой зоны.

Переходим в каталог, где хранится наша зона.

CentOS / Red Hat:

cd /var/named/master

Ubuntu / Debian:

cd /etc/bind/master

Подписываем зону:

dnssec-signzone -e +3mo -N INCREMENT -K /var/named/keys dmosk.ru

* где:

-e +3mo — время действия RRSIG (3 месяца).
-N INCREMENT — использовать формат серийного номера SOA из файла.
-K /var/named/keys — путь хранения сгенерированных ключей.
dmosk.ru — домен, который подписываем.

Система должна вернуть, примерно, следующее:

Verifying the zone using the following algorithms: RSASHA1.
Zone fully signed:
Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoked

В каталоге хранения зон мы должны увидеть dmosk.ru.signed — это файл подписанной зоны.

Проверка неполадок DNS-сервера

Проверьте следующие журналы, чтобы узнать, есть ли записанные ошибки:

Приложение
Система
DNS-сервер

Тестирование с помощью запроса nslookup

Выполните следующую команду и проверьте, доступен ли DNS-сервер с клиентских компьютеров.

Если сопоставитель возвращает IP-адрес клиента, у сервера нет проблем.
Если сопоставитель возвращает ответ «сбой сервера» или «Запрос отклонен», зона может быть приостановлена или сервер может быть перегружен. Чтобы узнать, приостановлен ли он, перейдите на вкладку Общие окна свойств зоны в консоли DNS.

Если сопоставитель возвращает ответ «запрос на превышение времени ожидания сервера» или «нет ответа от сервера», возможно, служба DNS не запущена. Попробуйте перезапустить службу DNS-сервера, введя следующую команду в командной строке на сервере:

Если проблема возникает при запуске службы, сервер может не прослушивать IP-адрес, который использовался в запросе nslookup. На вкладке интерфейсы страницы свойств сервера консоли DNS администраторы могут ограничить DNS-сервер прослушиванием только выбранных адресов. Если DNS-сервер настроен для ограничения службы указанным списком настроенных IP-адресов, то возможно, что IP-адрес, используемый для связи с DNS-сервером, отсутствует в списке. Можно попробовать использовать другой IP-адрес в списке или добавить IP-адрес в список.

В редких случаях DNS-сервер может иметь расширенную конфигурацию безопасности или брандмауэра. Если сервер расположен в другой сети, доступной только через промежуточный узел (например, маршрутизатор фильтрации пакетов или прокси-сервер), DNS-сервер может использовать нестандартный порт для прослушивания и получения клиентских запросов. По умолчанию программа nslookup отправляет запросы на DNS-серверы через порт UDP 53. Поэтому, если DNS-сервер использует любой другой порт, запросы nslookup завершатся ошибкой. Если вы считаете, что это может быть проблема, проверьте, используется ли промежуточный фильтр для блокировки трафика на хорошо известных портах DNS. Если это не так, попробуйте изменить фильтры пакетов или правила портов в брандмауэре, чтобы разрешить трафик через порт UDP/TCP 53.

Добавление MX-записи

Добавьте запись MX, чтобы сообщение электронной почты для домена пришло в Корпорацию Майкрософт.

Запись MX, которую вы добавим, включает значение (значение Points to address), которое выглядит так: .mail.protection.outlook.com, где это значение, как <MX token> <MX token> MSxxxxxx.
Из строки MX в разделе Exchange Online страницы Записи добавить DNS в Microsoft скопируйте значение, перечисленное в разделе Пункты для адреса. Это значение будет использоваться в записи, которую вы создаете в этой задаче.
На странице Диспетчер DNS для домена перейдите к exchanger почты действий > (MX). Чтобы найти эту страницу для домена, см. в этой странице Найти записи DNS в Windows
В диалоговом окне Запись новых ресурсов убедитесь, что поля задают следующие значения:
- Host Name (Имя узла):
- @Address: вклеить пункты для адреса значения, которое вы только что скопировали из Microsoft здесь.
- Преф:
Нажмите кнопку Сохранить изменения.
Удалите устаревшие записи MX. Если у вас есть какие-либо старые записи MX для этого домена, маршрут электронной почты в другом месте, выберите контрольный ящик рядом с каждой старой записью, а затем выберите Удалить > ОК.

Создание файла зоны и настройка записей

Создаем каталог master (если он отсутствует).

В CentOS / Red Hat:

mkdir /var/named/master

В Ubuntu / Debian:

mkdir /var/cache/bind/master

И создаем файл зоны (в нашем примере test.local).

CentOS / Red Hat:

vi /var/named/master/test.local

Ubuntu / Debian:

vi /var/cache/bind/master/test.local

Приводим его к следующему виду:

$TTL 14400
test.local. IN SOA ns1.test.local. admin.test.local. (
2017082401 ; Serial
10800 ; Refresh
3600 ; Retry
604800 ; Expire
604800 ; Negative Cache TTL
)
IN NS ns1.test.local.
IN NS ns2.test.local.
IN MX 10 mx.test.local.
IN MX 20 mx2.test.local.
@ IN A 192.168.1.1
localhost IN A 127.0.0.1
ns1 IN A 192.168.1.2
ns2 IN A 192.168.1.3
mx IN A 192.168.1.4
mail IN A 192.168.1.5
www IN CNAME test.local.

Формат записей: <имя узла> <класс (всегда ставится IN)> <тип записи> <значение>.

Немного подробнее:

Параметр	Описание
$TTL	Время актуальности записей в секундах. Необходим, чтобы указать другим DNS-серверам, как долго стоит хранить запись у себя в кэше. Слишком малое значение увеличит нагрузку на сервер, а большое приведет к слишком длительному процессу изменения записи.
SOA-запись	В данном примере эта запись идет сразу после параметра TTL. Ее стоит описать отдельно. Она хранит общие настройки для зоны. Serial — порядковый номер изменения. Его необходимо каждый раз менять вручную при редактировании файла. С помощью него вторичный сервер (если такой есть), может определить, что были изменения и начать процесс копирования настроек. Refresh указывает вторичным серверам, через какой промежуток времени они должны сделать запрос на обновление зоны. Retry говорит вторичным серверам, как часто повторять попытки на обновление зоны, если первичный сервер не смог дать ответ (сервис был недоступен). Expire — время в секундах, которое может работать вторичный сервер, если недоступен первичный. Если данный период истечет, а вторичный сервер так и не смог обновить зону, он должен прекратить отвечать на запросы.
<имя узла>	Собственно доменное имя хоста. Может записываться без домена (как в данном примере) — он будет дописан автоматически. Также может быть записан полностью с доменом — в таком случае необходимо поставить точку на конце, например, mail.test.local. Если не указывается или обозначается знаком собаки (@), запись создается для имени зоны (в данном случае, test.local).
<класс>	Всегда используется IN (Internet). Указывает на тип сети.
<тип записи>	Основные типы записей, использующиеся в DNS: A — сопоставляет имени узла соответствующий IP-адрес. NS — указатель на DNS-сервера, которые обслуживают данную зону. MX — почтовая запись. Указывает на почтовые сервера, которые обслуживают домен. Поддерживает приоритизацию — при указании нескольких записей, клиент будет ориентироваться на значение той, для которой указано меньшее число. CNAME — aliase или псевдоним. Перенаправляет запрос на другую запись. TXT — произвольная запись. Чаще всего используется для настройки средств повышения качества отправки почтовых сообщений.
<значение>	Используется IP-адрес, имя узла, текстовая запись.

Чтобы зона начала работать, перечитываем ее:

rndc reload

На сервере Slave

Открываем на редактирование конфигурационный файл bind.

CentOS:

vi /etc/named.conf

Ubuntu:

vi /etc/bind/named.conf.local

И дописываем туда следующее:

zone «dmosk.ru» {
type slave;
file «slaves/dmosk.ru»;
masters { 192.168.0.10; };
};

* где dmosk.ru — зона (домен); slave — указание, что эта зона вторичная; slave/dmosk.ru — файл с записями зоны

Стоит обратить внимание, что используется относительный путь до файла — это значит, что каталог slave должен находиться в рабочей папке bind (ее путь определяется опцией directory). Можно также прописать абсолютный путь, например, /etc/bind/slave/dmosk.ru; 192.168.0.10 — IP-адрес первичного сервера, с которого будут вытянуты записи для созданной зоны

Создаем каталог для хранения вторичных зон.

CentOS:

mkdir /var/named/slaves

Ubuntu:

mkdir /var/cache/bind/slaves

* используемые в нашем примере каталоги применяются по умолчанию, но в Вашем случае они могут быть другими. Сверяйте данные по опции directory.

Чтобы настройки применились, необходимо перезапустить вторичный bind-сервер одной из команд:

systemctl reload named

systemctl reload bind

service bind9 reload

и перечитать информацию о настроенных DNS-зонах:

rndc reload

Проверяем, что файл с записями появился в базе bind:

CentOS:

ls /var/named/slaves/

Ubuntu:

ls /var/cache/bind/slaves

* команда выведет список файлов, среди которых должен быть наш (в конкретном примере, dmosk.ru).

Чтобы проверить работоспособность вторичного сервера BIND, запускаем консоль на любом компьютере в сети и вводим команду:

nslookup dmosk.ru 192.168.0.15

* где dmosk.ru — домен, который мы создали; 192.168.0.15 — IP-адрес резервного DNS-сервера, на котором мы и создавали slave-зону (в моем примере).

Устанавливаем 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

У меня не установлен, так как во время инсталляции centos выбрал минимальный пакет программ. Сервер имен у нас будет работать в 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

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

Формирование ключей

Создаем каталог, в котором будем хранить ключи и сразу переходим в него.

На CentOS / Red Hat:

mkdir /var/named/keys

cd /var/named/keys

На Ubuntu / Debian:

mkdir /etc/bind/keys

cd /etc/bind/keys

* месторасположение каталога может быть любым. Если в системе активирован SELinux, необходимо также настроить контексты безопасности или отключить его.

Генерируем мастер ключ (KSK):

dnssec-keygen -f KSK -a RSASHA1 -b 2048 -n ZONE -r /dev/urandom dmosk.ru

* где:

-f KSK — флаг, который говорит, что формируется мастер ключ.
-a RSASHA1 — используемый алгоритм шифрования.
-b 2048 — размер ключа в битах.
-n ZONE — для DNS-зоны.
-r /dev/urandom — путь к файлу со случайными данными. В различных версиях системы путь может отличаться. Если упустить этот ключ в CentOS, процесс генерации сертификата может зависнуть.
dmosk.ru — домен, для которого предназначен ключ.

* подробное описание ключей можно посмотреть командой dnssec-keygen -help или man dnssec-keygen.

Генерируем ключ для зоны (ZSK):

dnssec-keygen -a RSASHA1 -b 2048 -n ZONE -r /dev/urandom dmosk.ru

Задаем владельца для сгенерированных файлов.

На CentOS / Red Hat:

chown -R named:named /var/named/keys

На Ubuntu / Debian:

chown -R bind:bind /etc/bind/keys

Preparing the Linux box

On the Linux box we need to ensure that zone transfers to the new Windows boxes are allowed.

Edit the named.conf file, which in this server’s case is located in /etc/named. For each of the domains that we wish to migrate to the new server we should check that there is a line, which is written like this example:

allow-transfer { 192.168.1.8; };

Figure 1: Step 1 of migrating a Linux BIND name server to a Windows Server DNS server.

This grants permission to this DNS server to allow a zone transfer to another box. Any current secondary servers will need to be here and we need to add the IP of our server. Once we have added the IP address of our new Windows Server 2012 R2 server for each domain, we are ready to move on to the next step of preparing the Windows Server.

Проверка работы 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) достаточно обширная. Возможно я еще вернусь к ней.

Онлайн курс по Linux

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с онлайн-курсом «Administrator Linux. Professional» в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров.

Что даст вам этот курс:

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

Проверьте себя на вступительном тесте и смотрите подробнее программу по .