Как поднять dns сервер

5

Записки IT специалиста

Настраиваем отказоустойчивый DNS-сервер на базе BIND 9

• Автор: Уваров А.С.
• 31.10.2022

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

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

BIND 9 — это полнофункциональный открытый DNS-сервер, имеющий широкое распространение, 10 из 13 корневых DNS-серверов работают именно на BIND. В данной статье мы будем рассматривать установку BIND в среде Debian или Ubuntu, все действия, если не указано иного, выполняются с правами суперпользователя (root). Также предполагается, что читатель имеет представление о назначении DNS-сервера и основных типах DNS-записей.

Установка и настройка BIND 9 на первичном сервере

Установка BIND и всех необходимых пакетов производится одной командой:

При этом обратите внимание, что несмотря на то, что имя пакета bind9 установленная служба имеет название named.

Затем откроем файл /etc/bind/named.conf.options и после строки:

Добавим следующие настройки:

Разберем их подробнее:

• listen-on port 53 — адреса на которых сервер будет принимать запросы, где 192.168.72.8 — адрес самого сервера
• allow-query — адреса сетей из которых принимаем запросы, указываем подсеть localhost и диапазон локальной сети
• allow-recursion — разрешаем рекурсивные запросы для localhost и локальной сети
• allow-transfer — кому можно предавать данные DNS-зон, по умолчанию никому
• forwarders — сервера пересылки, которым мы будем передавать запросы, которые не сможем разрешить самостоятельно, указываем любые внешние DNS

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

Теперь откроем файл /etc/bind/named.conf.local и добавим туда описание прямой зоны:

• zone — наименование зоны, которую будет обслуживать сервер, задается в виде доменного имени, в нашем случае interface31.lab
• type — тип зоны, в нашем случае — master — первичная
• file — файл с данными зоны, вы можете выбрать произвольное наименование, но в Debian принято соглашение называть эти файлы как db.имя_зоны, а хранить их в /var/lib/bind.
• allow-transfer — узел, которому разрешается передавать данные зоны, указываем адрес нашего вторичного DNS-сервера

Затем добавим туда же описание обратной зоны:

Название обратной зоны записывается как адрес сети без последнего октета (для сетей /24) наоборот и дополняется in-addr.arpa. Остальные параметры те же.

Настройка прямой зоны

Прямая зона отвечает за сопоставление доменных имен IP-адресам, при запросе к прямой зоне мы указываем доменное имя и получаем в ответ связанный с ним IP-адрес.

Создадим указанный нами в описании зоны файл:

И начнем его заполнять, прежде всего внесем начальная запись зоны — SOA:

Что означают эти записи?

TTL — время жизни DNS-записи, в нашем случае сутки, именно на это время клиент может поместить ее в собственный кеш, по истечении TTL клиент обязан запросить запись заново

@ IN SOA — основная запись домена, указывает его корневой DNS-сервер — dns-1.interface31.lab. и адрес ее администратора root.interface31.lab. (который следует понимать, как root@interface31.lab). Символ @ в начале строки указывает на текущий домен

Обратите внимание, что доменные имена внутри файлов зоны должны указываться в абсолютной форме записи, т.е. с точкой на конце. В противном случае окончание домена будет дополнено значением текущего. Т.е. вместо dns-1.interface31.lab вы получите dns-1.interface31.lab.interface31.lab

Ниже идут записи отвечающие за синхронизацию зоны со вторичными серверами:

• Serial — серийный номер зоны, при каждом изменении данных мы должны увеличивать серийный номер, по его изменению вторичные сервера понимают, что произошли изменения и начинают синхронизацию. Широко применяется следующий алгоритм формирования серийного номера: ГГГГ-ММ-ДД плюс две цифры указывающие на номер итерации, если в одну и ту же дату вносится несколько изменений.
• Refresh — период обновления данных вторичными серверами, по истечении данного времени они повторно запрашивают у основного сервера SOA-запись и анализируют серийный номер.
• Retry — периодичность повторного обращения к основному серверу, если предыдущая попытка завершилась неудачей
• Expire — максимальное время жизни зоны на вторичных серверах при отсутствии синхронизации с основным, по истечении этого времени вторичный сервер перестает обслуживать запросы
• Negative Cache TTL — время жизни негативного кеша или минимальное время жизни записи. Применяется для кеширования неудачного результата запроса со стороны клиента, например, обращение к несуществующему доменному имени.

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

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

Под ними уже располагаем записи относящиеся непосредственно к узлам, например:

Внимательный читатель заметит, что у нас есть две записи, указывающие на один и тот же адрес. Первая из них, содержащая вместо имени узла символ @ относится к текущему домену, т.е. определяет какой адрес вернет сервер если будет запрошено имя домена, т.е. просто interface31.lab, вторая запись уже относится к реальному узлу — роутеру.

Кроме A — записей зона может содержать и другие, все зависит от текущих потребностей. Например, мы добавили запись псевдонима — CNAME, которая указывает на то, что при запросе proxmox.interface31.lab нужно вернуть результат для имени pve7.interface31.lab. Чем это удобно? Тем что мы можем присвоить сетевым службам красивые имена, которые не будут привязаны к определенным узлам. Скажем переместили службу с srv-1 на srv-2 — просто поменяли CNAME.

Заканчиваться файл зоны должен пустой строкой.

Настройка обратной зоны

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

Точно также создадим файл зоны:

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

Затем начнем заполнять его записями, для показанной выше прямой зоны обратная будет выглядеть так:

Что обозначают эти записи? Начнем с того, что если имя узла указано без точки, то оно дополняется именем текущего домена, поэтому для указанной нами в записи цифры 8 это будет 8.72.168.192.in-addr.arpa, т.е. обратная запись для узла с адресом 192.168.72.8. Также обратите внимание, что доменные имена узлов следует указывать полностью, с точкой на конце.

Проверка работы первичного DNS-сервера

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

Затем проверим зоны, для этого указываем их наименования и пути к файлам данных:

Если ошибок не зафиксировано, то перезапускаем службу и проверяем ее работу:

Теперь можно попробовать направить запрос, начнем с прямого:

Затем проверим обратный

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

В обоих случаях вы должны получить правильные ответы, после чего можно переходить к настройке вторичного DNS-сервера.

Установка и настройка BIND 9 на вторичном сервере

Точно также установим пакет на второй сервер:

И сразу перейдем к /etc/bind/named.conf.options, настройки которого полностью аналогичны первичному серверу, за исключением строки:

В которой следует указать IP-адрес второго сервера, у нас это 192.168.72.9.

Теперь откроем /etc/bind/named.conf.local и пропишем зоны:

• type — тип зоны, в нашем случае вторичная — slave
• file — имя файла зоны, указываем без путей, файлы вторичных зон хранятся в /var/cache/bind
• masters — адрес нашего первичного сервера с которого вторичный будет забирать изменения

После чего проверяем правильность конфигурации:

И перезапускаем сервер:

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал:

Поднимаем свой DNS

В один «прекрасный момент» Руцентр сделал услугу Управление ДНС платной, что повлекло за собой трудности, например, с настройкой почты для домена от Яндекса.

Для себя я решил эту проблему, подняв свой DNS сервер на linux. Настройки будут для Centos 7, но отличие от других систем только в процессе установки пакетов и их именах.

Легенда

Сразу определимся с «легендой», что бы примеры понятными:

NAME.site — домен, который и нужно припарковать.

1.1.1.1 — белый IP сервера, к которому паркуем домен (Сервер, на котором будет работать сайт).

2.2.2.2 — белый IP сервера, на котором будет установлен DNS сервер.

OLD.site — уже существующий и работающий домен которому нужно будет создать пару поддоменов: ns1.OLD.site и
ns2.OLD.site — про это расскажу ниже.

Установка и настройка «bind9» AKA «named»

Сам DNS поднимем на bind9 также известном как named:

После установки нужно внести в конфиг (/etc/named.conf) пару изменений:

Также, в этом же файле, создаем зону:

Настраиваем зону:

Теперь нужно создать конфигурационный файл, для нашего домена: /var/named/NAME.site.zone

По хорошему, нужно создавать два NS сервера (один мастер, а второй слейв), для отказоустойчивости, но для текущей задачи это не нужно, т.к. данный ДНС будет использоваться только до момента подтверждения прав на домен у Яндекса.

Но если все же решите настроить еще и слейв, то стоит учесть, что число в строчке Serial нужно увеличивать при каждом изменении в файле, иначе slave сервер обновлять данные не будет.

Тестирование:

Для проверки нужно выполнить в консоли:

— в ответе должен придти IP адрес 1.1.1.1 (адрес к которому паркуем домен).

Как настроить простой DNS-сервер для локальной сети

Если вы впервые столкнулись с необходимостью поднять DNS-сервер для локальной сети под Linux, то эта статья – для вас. Преимущество предлагаемого способа – простота: сервер можно настроить буквально за несколько минут. Но этот способ, скорее всего, не подойдёт для продакшн серверов.

Автор статьи провёл несколько часов в борьбе с ошибками, багами и непонятным поведением системы прежде чем получил стабильный результат.

Далее будем считать, что имеется локальная сеть, состоящая из нескольких хостов. Локальная сеть настроена, сетевой доступ между хостами имеется. На хостах установлен Ubuntu 18.04.4 LTS (для других версий не проверялось).

Шаг 1. Установка необходимых пакетов

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

Установите Dnsmasq:

sudo apt-get install dnsmasq

При установке выведутся следующие ошибки:

failed to create listening socket for port 53: Address already in use
FAILED to start up
Failed to start dnsmasq — A lightweight DHCP and caching DNS server.

Это нормально! Мы ещё не настроили сервер – ошибка происходит из-за этого.

Установите resolvconf:

sudo apt-get install resolvconf

При установке ошибки о невозможности запуска Dnsmasq отобразятся ещё раз. Это нормально.

Пакет resolvconf устанавливается для того, чтобы в файл /etc/resolv.conf при перезапуске компьютера автоматически записывалась строчка nameserver 127.0.0.1 . Эта строчка показывает, по какому адресу необходимо выполнить DNS-запросы для определения IP адресов доменов.

Почему просто не прописать нужный адрес вручную

При рестарте системы файл /etc/resolv.conf автоматически пересоздаётся. Поэтому если прописать в него нужный адрес вручную, то изменения окажутся стёртыми после перезапуска.

По умолчанию после перезапуска в этот файл прописывается адрес 127.0.0.53 , который используется сервисом systemd-resolve . Этот сервис осуществляет определение IP-адресов доменов для приложений, работающих на том же хосте, на котором запущен сервис. Но мы планируем перестать использовать этот сервис и начать использовать dnsmasq .

Необязательный шаг. Установите net-tools:

sudo apt-get install net-tools

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

Шаг 2. Настройка пакетов

Отредактируйте файл /etc/dnsmasq.conf :

sudo nano /etc/dnsmasq.conf

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

Эта настройка выключает загрузку настроек из /etc/resolv.conf . Все настройки будут браться из редактируемого файла /etc/dnsmasq.conf . Это сильно упрощает конфигурацию Dnsmasq’а, поскольку файл /etc/resolv.conf автоматически пересоздаётся при рестарте системы.

8.8.8.8 — это адрес DNS-сервера Гугл. Этот адрес можно заменить на любой другой адрес публичного DNS-сервера. Например, на адрес DNS-сервера вашего провайдера или ранее используемого DNS-сервера.

Запросы, которые не сможет обработать Dnsmasq будут направлены на этот сервер.

Эта настройка позволит осуществлять запросы к Dnsmasq’у с других хостов.

Задаёт режим, при котором Dnsmasq не осуществляет привязку к интерфейсам, по которым не должна осуществляться обработка запросов. Без этой настройки в предлагаемом варианте конфигурации сервер не работает.

Добавьте в файл /etc/hosts необходимые домены и их IP адреса.

sudo nano /etc/hosts

Обратите внимание, что доменные имена, состоящие из одного имени без точки (например, myserver ), по умолчанию не передаются в DNS-сервер. Запросы по таким именам по умолчанию обрабатываются только через локальный файл /etc/hosts . Поэтому если в файле /etc/hosts на хосте с сервисом Dnsmasq прописать следующую строку: 2.3.4.5 myserver , то IP-адрес домена myserver будет определяться только на хосте с сервисом Dnsmasq. На других хостах IP-адрес данного домена определяться не будет, поскольку запросы на хост с Dnsmasq’ом отправляться не будут.

Опциональный шаг. Если вы не хотите, чтобы systemd-resolve слушал адрес 127.0.0.53:53 , то выполните команду:

sudo nano /etc/systemd/resolved.conf

В открывшемся файле пропишите строчку:

Адрес 127.0.0.53:53 в предлагаемом варианте конфигурации не используется и его можно выключить.

Шаг 3. Настройка используемых DNS-серверов

Данная настройка выполняется на всех хостах-клиентах, с которых будут отправляться запросы на хост с сервисом Dnsmasq.

Проще всего настроить используемые DNS-сервера в графическом интерфейсе. Укажите адрес хоста, на котором установлен Dnsmasq, первым в списке:

Шаг 4. Локальное тестирование DNS-сервера

Проверку настроек можно и не делать. Но если вам интересно узнать, всё ли работает правильно, то выполните следующие команды на хосте с сервисом Dnsmasq.

Проверьте, что в файле /etc/resolve.conf прописан адрес 127.0.0.1 :

sudo netstat -tulpen

Вы должны увидеть, что адрес 0.0.0.0:53 занят Dnsmasq’ом, а адрес 127.0.0.53:53 не фигурирует в списке.

Вы должны получить вывод, в котором присутствует примерно такая строчка. В начале строки не должно быть символов ; .

ya.ru. 220 IN A 87.250.250.242

Вы должны получить вывод, в котором присутствует примерно такая строчка:

myserver.tst. 0 IN A 1.2.3.4

Шаг 5. Тестирование DNS-сервера с других хостов

Теперь можно проверить работу DNS-сервера с других хостов.

Выполните пункты 3 и 4 из предыдущего раздела. Вывод в консоль должен быть аналогичен результатам, указанным в предыдущем разделе.

Дополнительная информация

Следующая команда в режиме реального времени выводит в консоль все запросы, выполняемые на порт 53. Это помогает определить факт выполнения запросов.

sudo tcpdump -l port 53

Данную команду логично выполнять в другом терминале – не в том, в который вводятся команды, подлежащие проверке.

Обратите внимание, что DNS-запросы кэшируются и сервисом systemd-resolved, и сервисом dnsmasq. Для сброса кэша проще всего перезапустить используемый сервис:

sudo systemctl restart dnsmasq (на серверном хосте)

sudo systemctl restart systemd-resolved (на клиентских хостах)

Заключение

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

Настройка BIND в качестве DNS-сервера частной сети на базе Ubuntu 18.04

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

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

Версию CentOS, используемую в данном руководстве, можно найти здесь.

Предварительные требования

Для выполнения данного руководства вам потребуется следующая инфраструктура. Создайте каждый сервер **в одном центре обработки данных **с активированной опцией частной сети:

• Свежий сервер Ubuntu 18.04, который будет использоваться в качестве основного DNS-сервера, ns1.
• (Рекомендуется) Второй сервер Ubuntu 18.04, который используется в качестве дополнительного DNS-сервера, ns2.
• Дополнительные серверы в одном центре обработки данных, которые будут использовать ваши DNS-серверы.

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

Если вы не знакомы с концепцией DNS, рекомендуем ознакомиться минимум с первыми тремя частями нашего руководства Введение в управление DNS.

Пример инфраструктуры и целей

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

• У нас есть два сервера, которые будут назначены в качестве наших серверов имен DNS. В этом руководстве мы будем использовать наименования ns1 и ns2.
• У нас есть два дополнительных клиентских сервера, которые будут использовать созданную нами инфраструктуру DNS. В этом руководстве мы будем использовать наименования host1 и host2. Вы можете добавить любое количество, которое захотите, для вашей инфраструктуры.
• Все эти серверы существуют в одном центре обработки данных. Мы полагаем, что это центр обработки данных nyc3.
• Для всех этих серверов активирована опция частной сети (и в подсети 10.128.0.0/16 ; вам, возможно, нужно будет отредактировать эти параметры для ваших серверов).
• Все серверы подключены к проекту, который запущен на example.com. Поскольку наша система DNS будет полностью внутренней и частной, вам не нужно будет приобретать доменное имя. Однако использование собственного домена может помочь избежать конфликтов с доменами с публичной маршрутизацией.

С учетом этих предположений мы решили, что будет полезно использовать схему именования, которая использует nyc3.example.com для обращения к нашей частной подсети или зоне. Таким образом, частным полным доменным именем (FQDN) для host1 будет host1.nyc3.example.com. Соответствующую информацию см. в следующей таблице:

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

К концу данного руководства мы получим основной DNS-сервер, ns1, и, в качестве опции, дополнительный DNS-сервер, ns2, который будет служит в качестве резервного сервера.

Давайте начнем с установки нашего основного DNS-сервера, ns1.

Установка BIND на DNS-серверах

Примечание: красным цветом выделяется важная информация! Он часто будет использоваться для чего-то, что необходимо заменить на собственные настройки или того, что нужно изменить или добавить в файл конфигурации. Например, если вы увидите что-то вроде host1.nyc3.example.com , замените эти данные на FQDN вашего сервера. Аналогичным образом, если вы увидите host1_private_IP , замените эти данные на частный IP-адрес вашего сервера.

На обоих DNS-серверах, ns1 и ns2, обновите кэш пакета apt с помощью следующей команды:

Теперь можно переходить к установке BIND:

Настройка режима IPv4 для Bind

Прежде чем продолжить, давайте настроим режим IPv4 в BIND, так как наша частная сеть использует исключительно IPv4. На обоих серверах отредактируйте файл настроек по умолчанию bind9 с помощью следующей команды:

Добавьте “-4” в конец параметра OPTIONS . Результат будет выглядеть следующим образом:

Сохраните файл и закройте его после завершения.

Перезапустите BIND для вступления изменений в силу:

Теперь, после установки BIND, давайте настроим основной DNS-сервер.

Настройка основного DNS-сервера

Конфигурация BIND состоит из множества файлов, которые включены в основной файл конфигурации, named.conf . Эти имена файлов начинаются с named , потому что это имя процесса, который запускает BIND (сокращение от “domain name daemon”). Мы начнем с настройки файла параметров.

Настройка файла параметров

На сервере ns1 откройте файл named.conf.options для редактирования:

Над существующим блоком options создайте новый блок ACL (список контроля доступа) под названием “trusted”. Именно здесь мы создадим список клиентов, для которых мы будем разрешать рекурсивные DNS-запросы (т. е. запросы от ваших серверов, находящихся в том же центре обработки данных, что и ns1). С помощью нашего примера частных IP-адресов мы добавим ns1, ns2, host1 и host2 в наш список надежных клиентов:

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

Под директивой directory добавьте выделенные цветом строки конфигурации (и замените в соответствующем IP-адресе ns1), чтобы результат выглядел примерно следующим образом:

После завершения редактирования сохраните и закройте файл named.conf.options . Согласно конфигурация выше, только ваши собственные серверы (т. е. доверенные) смогут запрашивать у вашего DNS-сервера внешние домены.

Далее мы настроим локальный файл, чтобы задать ваши DNS-зоны.

Настройка локального файла

На сервере ns1 откройте файл named.conf.local для редактирования:

Файл должен содержать только несколько комментариев. Здесь мы зададим наши зоны. DNS-зоны определяют конкретную область для управления и определения записей DNS. Поскольку наши домены будут находиться в субдомене nyc3.example.com, мы будем использовать его в качестве зоны прямого просмотра. Поскольку частные IP-адреса нашего сервера находятся в пространстве IP-адресов 10.128.0.0/16 , мы создадим зону обратного просмотра, чтобы мы могли определять обратный просмотр в этом диапазоне.

Добавьте зону прямого просмотра со следующими строками, заменив имя зоны на собственное, и закрытый IP-адрес дополнительного DNS сервера в директиве allow-transfer :

Если, согласно нашему предположению, нашей частной подсетью является 10.128.0.0/16 , добавьте зону обратного просмотра с помощью следующих строк (обратите внимание, что имя зоны обратного просмотра начинается с “128.10”, что представляет собой битное преобразование "10.128"​):

Если ваши серверы охватывают несколько частных подсетей, но находятся в одном центре обработки данных, обязательно указывайте дополнительную зону и файл зоны для каждой отдельной подсети. После добавления всех необходимых зон сохраните и закройте файл named.conf.local .

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

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

Файл зоны прямого просмотра — это место, где мы будем определять DNS-записи для прямого просмотра DNS. Т. е., когда DNS получает запрос имени, например, “host1.nyc3.example.com”, будет выполняться поиск в файле зоны прямого просмотра для получения соответствующего частного IP-адреса для host1.

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

При создании нашего файла зоны для прямого просмотра мы будем опираться в качестве примера на файл зоны db.local . Скопируйте его в надлежащее место с помощью следующих команд:

Теперь необходимо отредактировать наш файл зоны для прямого просмотра:

Первоначально он будет выглядеть примерно следующим образом:

Во-первых, вам необходимо отредактировать запись SOA. Замените первую запись “localhost” на полное доменное имя (FQDN) ns1, а затем замените “root.localhost” на “admin.nyc3.example.com”. При каждом изменении файла зоны вам нужно будет увеличивать значение serial, прежде чем перезапускать процесс named . Мы увеличим значение до “3”. Теперь файл должен выглядеть примерно следующим образом:

Далее удалите три записи в конце файла (после записи SOA). Если вы уверены, какие строки следует удалить, удаляйте строки с комментарием “delete this line”.

В конце файла добавьте записи для имени сервера со следующими строками (замените имена на собственные). Обратите внимание, что во втором столбце указывается, что это записи “NS”.

Теперь добавьте записи A для ваших хостов, которые принадлежат к этой зоне. Это может быть любой сервер, имя которого будет заканчиваться на “.nyc3.example.com” (замените имена и частные IP-адреса). Используя приведенные в качестве примера имена и частные IP-адреса, мы добавим записи A для ns1, ns2, host1 и host2 примерно таким образом:

Сохраните и закройте файл db.nyc3.example.com .

Полученный нами в итоге пример файла зоны для прямого просмотра выглядит следующим образом:

Теперь пришло время перейти к файлу (файлам) зоны для обратного просмотра.

Создание файла (файлов) зоны для обратного просмотра

Файлы зоны для обратного просмотра служат местом, где мы будем определять PTR записей DNS для обратного просмотра DNS. Т. е., когда DNS получает запрос для IP-адреса, например, “10.128.100.101”, она будет выполнять поиск по файлу (файлам) зоны для обратного просмотра, чтобы получить соответствующее полное доменное имя, в нашем случае это “host1.nyc3.example.com”.

В ns1 для каждой зоны обратного просмотра, заданной в файле named.conf.local, необходимо создать файл зоны для обратного просмотра. При создании нашего файла (или файлов) зоны для обратного просмотра мы будем опираться в качестве примера на файл зоны db.local. Скопируйте его в надлежащее место с помощью следующих команд (замените имя файла назначения, чтобы оно соответствовало определению вашей зоны для обратного просмотра):

Отредактируйте файл зоны для обратного просмотра, который соответствует зоне(-ам), определенной(-ым) в named.conf.local:

Первоначально он будет выглядеть примерно следующим образом:

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

Теперь удалите две записи в конце файла (после записи SOA). Если вы уверены, какие строки следует удалить, удаляйте строки с комментарием “delete this line”.

В конце файла добавьте записи для имени сервера со следующими строками (замените имена на собственные). Обратите внимание, что во втором столбце указывается, что это записи “NS”.

Затем добавьте записи PTR для всех ваших серверов, чей IP-адрес соответствует подсети файла зоны, который вы редактируете. В нашем примере это будут все наши хосты, поскольку все они находятся в подсети 10.128.0.0/16 . Обратите внимание, что первый столбец включает два последних байта частных IP-адресов ваших серверов в обратном порядке. Обязательно замените имена и частные IP-адреса согласно данным ваших серверов:

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

Полученный нами в итоге пример файла зоны для обратного просмотра выглядит следующим образом:

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

Проверка синтаксиса конфигурации BIND

Запустите следующую команду для проверки синтаксиса файлов named.conf* :

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

Команда named-checkzone может использоваться для проверки корректности ваших файлов зоны. Первый аргумент команды указывает имя зоны, а второй аргумент определяет соответствующий файл зоны, оба из которых определены в named.conf.local​​​ .

Например, чтобы проверить конфигурацию зоны для прямого просмотра “ nyc3.example.com ”, запустите следующую команду (измените на ваши имена зоны для прямого просмотра и файла):

А чтобы проверить конфигурацию зоны для обратного просмотра “ 128.10 .in-addr.arpa”, запустите следующую команду (замените на данные, соответствующие вашей зоне для обратного просмотра и файлу):

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

Перезапуск BIND

Если у вас есть настроенный брандмауэр UFW, откройте доступ к BIND с помощью следующей команды:

Теперь ваш основной DNS-сервер настроен и может отвечать на запросы DNS. Давайте перейдем к созданию дополнительного DNS-сервера.

Настройка дополнительного DNS-сервера

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

На сервере ns2 отредактируйте файл named.conf.options :

В верхней части файла добавьте ACL с частными IP-адресами всех ваших доверенных серверов:

Под директивой directory добавьте следующие строки:

Сохраните и закройте файл named.conf.options . Этот файл должен выглядеть так же, как файл named.conf.options сервера ns1, за исключением того, что его необходимо настроить на прослушивание частного IP-адреса ns2.

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

Определите slave-зоны, соответствующие master-зонам основного DNS-сервера. Обратите внимание, что в качестве типа используется slave, в файле отсутствует путь, и существует директива masters , которая должна быть настроена на частный IP-адрес основного DNS-сервера. Если вы определили несколько зон для обратного просмотра на основном DNS-сервере, обязательно проверьте, что все они были добавлены на этом этапе:

Сохраните и закройте файл named.conf.local .

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

После выполнения проверки перезапустите BIND:

Разрешите подключение DNS к серверу, внеся изменения в правила брандмауэра UFW:

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

Настройка DNS-клиентов

Прежде чем все ваши серверы в доверенном ACL смогут отправлять запросы на ваши DNS-серверы, вы должны настроить для каждого из них использование ns1 и ns2 в качестве сервера имен. Этот процесс варьируется в зависимости от операционной системы, но для большинства дистрибутивов Linux он подразумевает добавление ваших серверов доменных имен в файл /etc/resolv.conf .

Клиенты Ubuntu 18.04

На Ubuntu 18.04 настройка сетевого взаимодействия выполняется с помощью Netplan, абстракции, которая позволяет вам записывать стандартную конфигурацию сети и применять ее к несовместимому сетевому ПО, отвечающему за бекэнд. Для настройки DNS нам потребуется записать файл конфигурации Netplan.

Во-первых, найдите устройство, связанное с вашей частной сетью, отправив частной подсети команду ip address :

В этом примере используется частный интерфейс eth1 .

Далее необходимо создать новый файл в /etc/netplan с именем 00-private-nameservers.yaml :

Вставьте в файл следующее содержимое. Вам потребуется изменить интерфейс частной сети, адреса ваших DNS-серверов ns1 и ns2, а также зону DNS:

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

Сохраните файл и закройте его после завершения.

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

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

Теперь проверьте DNS-преобразователь системы, чтобы определить, применены ли изменения в конфигурацию DNS:

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

Ваш клиент должен быть настроен на использование ваших внутренних DNS-серверов.

Клиенты Ubuntu 16.04 и Debian

В серверах Ubuntu 16.04 и Debian вы можете изменить файл /etc/network/interfaces :

Внутри найдите строку dns-nameservers и добавьте ваши серверы доменных имен в начало списка, который уже добавлен в файл. Под этой строкой добавьте опцию dns-search , указывающую на базовый домен вашей инфраструктуры. В нашем случае это будет “nyc3.example.com”:

Сохраните файл и закройте его после завершения.

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

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

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

Вы должны увидеть ваши серверы доменных имен в файле /etc/resolv.conf , а также ваш домен поиска:

Ваш клиент настроен для использования ваших DNS-серверов.

Клиенты CentOS

В CentOS, RedHat и Fedora Linux отредактируйте файл /etc/sysconfig/network-scripts/ifcfg- eth0 . Возможно, вам придется заменить eth0 на имя вашего основного сетевого интерфейса:

Найдите опции DNS1 и DNS2 и задайте для них частные IP-адреса ваших основного и дополнительного серверов доменных имен. Добавьте параметр DOMAIN , используя базовый домен вашей инфраструктуры. В этом руководстве это будет “nyc3.example.com”:

Сохраните файл и закройте его после завершения.

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

Команда может зависнуть на несколько секунд, но через короткое время вы должны вернуться в командную строку.

Убедитесь, что изменения вступили в силу, введя следующую команду:

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

Ваш клиент теперь может подключиться и использовать ваши DNS-серверы.

Тестирование клиентов

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

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

Мы можем начать выполнять прямой просмотр.

Прямой просмотр

Например, мы можем выполнить прямой просмотр для получения IP-адреса host1.nyc3.example.com с помощью следующей команды:

Запрос “host1” расширяется до “host1.nyc3.example.com”, потому что опция search задана для вашего частного субдомена, а запросы DNS будут пытаться просмотреть этот субдомен перед поиском по всему хосту. Результат описанной выше команды будет выглядеть следующим образом:

Теперь мы можем проверить обратный просмотр.

Обратный просмотр

Чтобы протестировать обратный просмотр, отправьте DNS-серверу запрос на частный IP-адрес host1:

Результат будет выглядеть следующим образом:

Если все имена и IP-адреса будут передавать правильные значения, это означает, что ваши файлы зоны настроены надлежащим образом. Если вы получите неожиданные значения, обязательно проверьте файлы зоны на вашем основном DNS-сервере (например, db.nyc3.example.com и db.10.128 ).

Поздравляем! Ваши внутренние DNS-серверы настроены надлежащим образом! Теперь мы перейдем к сохранению записей зоны.

Сохранение DNS-записей

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

Добавление хоста в DNS

При добавлении хоста в вашу среду (в одном центре обработки данных) вам нужно добавить его в DNS. Здесь представлен список шагов, которые вам нужно предпринять:

Основной сервер доменных имен

• Файл зоны для прямого просмотра: добавьте запись A для нового хоста, увеличив значение “Serial”
• Файл зоны для обратного просмотра: добавьте запись PTR для нового хоста, увеличив значение “Serial”
• Добавьте частный IP-адрес вашего нового хоста в доверенный ACL ( named.conf.options )

Протестируйте ваши файлы конфигурации:

Затем перезагрузите BIND:

Ваш основной сервер должен быть настроен для использования нового хоста.

Дополнительный сервер доменных имен

• Добавьте частный IP-адрес вашего нового хоста в доверенный ACL ( named.conf.options )

Проверьте синтаксис конфигурации:

Затем перезагрузите BIND:

Ваш вторичный сервер теперь будет принимать подключения с нового хоста.

Настройка нового хоста для использования вашей DNS

• Настройте /etc/resolv.conf для использования ваших DNS-серверов
• Выполните проверку с помощью nslookup

Удаление хоста из DNS

Если вы удалите хост из вашей среды или захотите просто убрать его из DNS, просто удалите все данные, которые были добавлены при добавлении сервера в DNS (т. е. выполните описанные выше шаги в обратно порядке).

Заключение

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

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

Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.