Свой dns сервер: Поднимаем свой DNS сервер на VDS / Sandbox / Habr

Поднимаем свой DNS сервер на VDS / Sandbox / Habr

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

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

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

Сервер для DNS → 91.197.130.49 (ns1.mydomain.com)
→ 91.197.130.63 (ns2.mydomain.com)
Зона —> mydomain.com
На виртуальном сервере установлена ОС — CentOS5.5

Установка BIND

Прежде всего, нам необходимо установить на сервер сам пакет BIND, а для этого нужно подсоединится к нашему VDS.

Тут есть два варианта в зависимости от того, какой ОС вы пользуетесь на своем персональном компьютере.

В linux системах все довольно просто. Нужно перейти в основной панели на вкладку Places — Connect to Server.., в Service type выбрать SSH соединение, ввести адрес вашего сервера, ваш логин, нажать кнопку «connect». В появившемся окошке ввести свой пароль и… вы уже в терминале операционной системы своего VDS.

Если вы пользуетесь Windows, то могу посоветовать вам скачать программу PuTTY. Программа распространяется бесплатно и без ограничений. Скачать и узнать, как ей пользоваться, можно здесь.

Итак, мы попали в терминал VDS. Чтобы установить последнюю версию пакета BIND, нужно ввести команду:

yum install bind

Жмем «Enter» и ждем успешного завершения установки.

Создание данных зоны

Следующим шагом на нашем пути будет создание данных для зоны.

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

Мы будем использовать следующие файлы:
1.Файл, содержащий данные преобразования имен хостов в адреса. Его имя для нашей зоны будет иметь вид db.mydomain.com.

Приступим непосредственно к созданию файлов.

Начнем с конфигурационного файла. Чтобы создать его, вводим в терминале VDS команду

vi /etc/named.conf

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

options {
directory "/var/named/";
dump-file "/var/run/named_dump.bd";
statistics-file "/var/run/named.stats";
};

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

zone "mydomain.com" IN {
type master;
file "db.mydomain.com";
};

Данная строка файла настройки предписывает чтение файла корневых указателей:

zone "." {
type hint;
file "db.cache";
};

Этот файл не содержит данные кэша, а только указатели (hints) корневых DNS-серверов, о чем будет сказано ниже.

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

options {
directory "/var/named/";
dump-file "/var/run/named_dump.bd";
statistics-file "/var/run/named.stats";
};

zone «mydomain.com» IN {
type master;
file «db.mydomain.com»;
};

zone «130.197.91.IN-ADDR.ARPA.» IN {
type master;
file «db.91.197.130.»;
};

zone «0.0.127.IN-ADDR.ARPA.» IN {
type master;
file «db.127.0.0»;
};

zone «.» {
type hint;
file «db.cache»;
};

Теперь рассмотрим, как создать файлы данных для mydomain.com., 91.197.130.0, 127.0.0 и cache. Вообще файлы db.127.0.0 и db.cache создаются автоматически, так что описывать их нет необходимости.

Вводим в терминале

vi /var/named/db.mydomain.com.

Теперь приступим к редактированию файла.

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

Для того, чтобы указать стандартное значение, нужно воспользоваться директивой $TTL. Для данного примера возьмем за стандартное значение 3 часа (3h). Первая строчка будет выглядеть так:

$TTL 3H

Теперь необходимо указать SOA- запись. Она должна находиться в каждом из файлов данных зоны. Она показывает, что наш DNS-сервер является самым надежным источником информации в пределах этой зоны.
Важно знать! В файле данных зоны может быть записана одна и только одна SOA-запись.

SOA-запись для данного примера будет иметь вид:

mydomain.com. IN SOA ns1.mydomain.com. admin.mydomain.com. (


На первом месте указываем доменную зону нашего будущего NS, обязательно в конце домена ставим точку. Зачем это делается, я расскажу чуть позже. Далее следует класс сети, об этом уже было написано выше, его указывать не обязательно. SOA указывает на тип записи. ns1.mydomain.com. — это адрес первичного сервера DNS зоны mydomain.com. А admin.mydomain.com. — почтовый адрес владельца доменной зоны. Скобки позволяют указать несколько строк, относящихся к записи. Следующие в них значения по сути не нужны в данном примере, они используются в основном вторичными серверами, но все же я вкратце опишу, что они значат.

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

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

Обновление (refresh)
Интервал обновления инструктирует вторичный DNS-сервер, с какой частотой следует проверять актуальность информации для зоны.

Повторение попытки (retry)
Если вторичный сервер не может подключиться к первичному (который вполне возможно уже не работает), он повторяет попытки через равные интервалы времени, указанные данным значением.

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

TTL — это время жизни (time to live). Это значение относится ко всем отрицательным ответам DNS-серверов, авторитативных для данной зоны.

Документом RFC 1537 рекомендуются следующие значения для DNS серверов высшего уровня:
Обновление 24 hours
Повторение попытки 2 hours
Устаревание 30 days
Стандартное TTL 4 days

Следующие записи называются NS записями, они также добавляются к каждому файлу данных.

mydomain.com. IN NS ns1.mydomain.com.
mydomain.com. IN NS ns2.mydomain.com.

Теперь наши записи указывают на то, что для нашей DNS зоны существует якобы два различных DNS сервера. Для правильной работы NS записей необходимо указать IP адреса, на которых установлены сервера. Делается это с помощью A записей:

ns1.mydomain.com. IN A 91.197.130.49
ns2.mydomain.com. IN A 91.197.130.63

Файл db.mydomain.com. готов, перейдем к создания следующего файла. Вводим в терминале:

vi /var/named/chroot/var/named/db.

И редактируем данные как в предыдущем файле.
Сначала прописываем TTL и SOA запись.

$TTL 3H
130.197.91 IN SOA ns1.mydomain.com admin.mydomain.com (
1
3H
1H
1W
1H )

Далее NS записи:

пробел IN NS ns1.mydomain.com.
пробел IN NS ns2.mydomain.com.

А теперь указываем PTR записи — они служат для отображения имен, соответствующих IP адресам. Для данного примера записи будут выглядеть следующим образом:

49.130.197.91 PTR ns1.mydomain.com.
63.130.197.91 PTR ns2.mydomain.com.

Вот наш файл и готов.

Упрощаем код

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

Вернемся к нашему конфигурационному файлу. Поле директивы zone определяет доменное имя. Это имя является суффиксом по умолчанию (origin) для всей информации в файлах данных зоны. Суффикс по умолчанию добавляется в конец всех имен, которые не заканчиваются точкой (Помните я говорил о том, что не следует забывать ставить точку в конце имен). Так как каждый файл отвечает за свою зону, то и суффиксы по умолчанию в каждом файле свои.

Исходя из данного принципа сокращений, можно упростить код следующим образом:

Вместо строки: «ns1.mydomain.com. IN A 91.197.130.49» можно указать вот такую строку:

ns1 IN A 91.197.130.49

Запись «49.130.197.91 PTR ns1.mydomain.com.» можно записать так:

49 PTR ns1.mydomain.com.

Если доменное имя совпадает с суффиксом по умолчанию, его можно указывать в виде «@». Обычно такая запись используется в SOA-записях. Например:

@ IN SOA ns1.mydomain.com. admin.mydomain.com. (
1
3h
1h
1w
1h )

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

130.197.91 IN NS ns1.mydomain.com.
«пробел» IN NS ns2.mydomain.com.

Таким сокращением можно пользоваться даже при создании различных типов записей для одного имени.

Итог

Посмотрим теперь, как будут выглядеть наши файлы данных зоны с применением вышеописанных правил сокращения.
Файл db.mydomain.com.

$TTL 3H
@ IN SOA ns1.mydomain.com. admin.mydomain.com. (
1
3h
1h
1w
1h )

«пробел» IN NS ns1.mydomain.com.
«пробел» IN NS ns2.mydomain.com.

ns1 IN A 91.197.130.49
ns2 IN A 91.197.130.63

Файл db.91.197.130.

$TTL 3H
@ IN SOA ns1.mydomain.com admin.mydomain.com (
1
3H
1H
1W
1H )

«пробел» IN NS ns1.mydomain.com.
«пробел» IN NS ns2.mydomain.com.

49 PTR ns1.mydomain.com.
63 PTR ns2.mydomain.com.

Поздравляю! Мы закончили настройку нашего DNS сервера с двумя записями NS.

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

/etc/init.d/nammed start
/etc/init.d/nammed stop
/etc/init.d/nammed restart

Для тестирования серверов существует очень полезная программка — nslookup.

Бесплатный DNS-хостинг на быстрых DNS-server’ах

Address Record — IP-адрес, который соответствует доменному имени.
Например: example.com internet address = 217.69.139.202

Address Record IPv6 — IP-адрес, который соответствует доменному имени, по 6 версии интернет-протокола.
Например: example.com AAAA IPv6 address = 2a00:1148:db00:0:b0b0::1

Mail Exchange — MX-запись содержит доменное имя почтового сервера, принимающий почту для вашего домена.
Например: example.com MX preference = 10, mail exchanger = mxs.example.com.
при этом в DNS должна быть соответствующая запись типа «А», mxs.example.com internet address = 217.69.139.150

Point to Reverse — в противоположность записи типа «А», используется для получения доменного имени по IP-адресу.
Например: 217.69.139.150.in-addr.arpa. IN PTR example.com

Canonical Name Record — каноническая запись имени — отображает синоним (алиас) другого доменного имени (для перенаправления на него).
Например: www.example.com IN CNAME example.com

Name Server — NS-запись указывает на DNS-сервер, обслуживающий данное доменное имя.
Например: example.com nameserver = ns1.example.com
при этом в DNS должна быть соответствующая запись типа «А», ns1.example.com internet address = 217.69.139.112

Текстовая запись — может содержать произвольный текст.
Например: example.com text = «v=spf1 redirect=_spf.example.com»

Service Record — определяет доменное имя сервера определенных служб (IP-телефонии, системы мгновенных сообщений и т.п.).
Например: _sip._tcp.example.com 86400 IN SRV 0 5 5060 sipserver.example.com
при этом в DNS должна быть соответствующая запись типа «А», sipserver.example.com internet address = 217.69.139.112

Как настроить выделенный сервер: настройка DNS для Dedicated server

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

Первый способ

Если домен находится на обслуживании в компании REG.RU, вы можете воспользоваться бесплатными DNS-серверами: ns1.reg.ru и ns2.reg.ru:

1. 1. Авторизуйтесь на сайте REG.RU, перейдите в раздел «Мои домены и услуги» и кликните на имя домена.
2. 2.

   В блоке «Управление» выберите пункт DNS-серверы и управление зоной.

3. 3.

   Выберите пункт Добавить запись. Для привязки домена в поле «Subdomain» впишите @, в поле «IP Address» впишите IP-адрес сервера. Для привязки домена с префиксом www в поле «Subdomain» впишите www, а в поле «IP Address» впишите IP-адрес сервера.

Другой регистратор

Если домен находится у другого регистратора, пожалуйста, обратитесь к нему с вопросами настройки зоны на IP-адрес вашего сервера. Сообщите, что вам требуется добавить в зону домена следующие записи:
@ A IP-адрес выделенного сервера
www A IP-адрес выделенного сервера

Второй способ

Вы можете воспользоваться бесплатной поддержкой DNS, входящей в стандартный пакет услуг «Reg.Dedicated». Для этого вам предоставляется удобный интерфейс для управления зоной на базе ISPmanager и DNSmanager. При пользовании данной услугой у вашего регистратора для домена в качестве DNS-серверов необходимо прописывать: ns5.hosting.reg.ru и ns6.hosting.reg.ru.

Если вместе с услугой «Аренда сервера» вы заказали панель управления ISPmanager

1. 1.

   Зайдите в вашу панель управления ISPmanager с правами администратора.

2. 2.

   Перейдите в раздел Доменные имена.

3. 3.

   Нажмите на Вторичные серверы имен.

4. 4.

   Нажмите Зарегистрировать новый внешний сервер имен.

5. 5.

   В поле «URL панели управления» введите https://ns5.hosting.reg.ru/manager/dnsmgr.

6. 6.

   В поле «Пользователь» введите ваш логин вида d0000000.

7. 7.

   В поле «Пароль» введите ваш пароль для доступа к DNS (не следует путать его с паролем пользователя root).

8. 8.

   Нажмите ОК.

9. 9.

   Повторите операцию добавления вторичного сервера имён для адреса https://ns6.hosting.reg.ru/manager/dnsmgr.

10. 10.

    Нажмите на Настройки доменов по умолчанию.

11. 11.

    В поле «Серверы имён» введите ns5.hosting.reg.ru. и ns6.hosting.reg.ru..

12. 12.

    Поставьте галочку «Изменить для всех доменов».

13. 13.

    Нажмите ОК.

Теперь при создании домена в панели управления вашим сервером домен будет автоматически создан на вторичных серверах ns5.hosting.reg.ru и ns6.hosting.reg.ru, которые вы сможете прописать как DNS-сервера для данного домена у вашего регистратора.

Выделенный сервер в качестве первичного DNS-сервера

Если вы не заказывали панель управления ISPmanager и хотите, чтобы ваш выделенный сервер выступал в качестве первичного DNS-сервера, для вас предусмотрен интерфейс управления вторичными серверами имён:

1. 1. Зайдите в панель управления DNSmanager (https://ns5.hosting.reg.ru/manager/dnsmgr), используя логин вида d0000000 и пароль для доступа к DNS (не следует путать его с паролем пользователя root).
2. 2.

   Перейдите в раздел «Доменные имена».

3. 3.

   Нажмите на Создать новый домен.

4. 4.

   В поле «Имя домена» введите имя добавляемого вами домена.

5. 5.

   В поле «IP первичного NS» введите IP-адрес вашего выделенного сервера.

6. 6.

   Нажмите ОК.

7. 7. Повторите операцию добавления домена на втором сервере (https://ns6.hosting.reg.ru/manager/dnsmgr).

Интерфейс управления первичным сервером имён

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

1. 1. Зайдите в панель управления DNS Admin, используя логин вида d0000000 и пароль для доступа к DNS (не следует путать его с паролем пользователя root).
2. 2.

   Перейдите в раздел «Доменные имена».

3. 3.

   Нажмите на Создать новый домен.

4. 4.

   В поле «Доменное имя» введите имя добавляемого вами домена.

5. 5.

   В поле «IP-адрес» введите IP-адрес вашего выделенного сервера;

6. 6.

   Нажмите ОК.

Создать свои собственные DNS-серверы на базе домена:

а) необходимо иметь основной IP вашего выделенного сервера и дополнительный, полученный при подключении услуги «Дополнительный IP адрес на ваш выбор»;

b) необходимо настроить свои DNS-серверы в ISPManager:

1. org/HowToStep»> 1.

   Зайдите в вашу панель управления ISPmanager с правами администратора.

2. 2.

   Откройте раздел «Настройки DNS»:

3. 3.

   В поле «Серверы имён» укажите два DNS-сервера:
   ns1.yourdomain.ru., ns2.yourdomain.ru.:
   

4. 4.

   Сохраните изменения.

В первый раз при делегировании вашего основного домена на выделенный сервер нужно помимо имён серверов указать IP-адреса для каждого ns-сервера. В дальнейшем при делегировании новых доменов на выделенный сервер достаточно будет указывать только ns1.yourdomain.ru., ns2.yourdomain.ru..

c) У своего регистратора прописать для домена yourdomain.ru DNS-сервера: ns1.yourdomain.ru и ns2.yourdomain.ru, а также IP-адреса для каждого ns-сервера.

Как добавить домен на выделенный сервер (Dedicated)

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

• Если для вашего домена указаны ns1.reg.ru и ns2.reg.ru, управление зоной происходит на странице домена в Личном кабинете. Посмотрите инструкцию: Настройка ресурсных записей DNS для домена;

• Если для вашего домена указаны ns5.hosting.reg.ru и ns6.hosting.reg.ru, управление зоной домена на Dedicated сервере происходит или в панели управления ISPmanager, или в панели DNSadmin.
  

Если домен был добавлен в панели управления ISPmanager 5

В этом случае управление зоной домена происходит в ISPmanager: откройте панель управления — и перейдите в раздел Доменные имена. Затем нажмите кнопку Записи. Там вы сможете создавать, редактировать и удалять ресурсные записи для домена:

Если домен был добавлен в панели DNSadmin

В этом случае управление зоной домена происходит в панели DNSadmin. Чтобы войти в панель, используйте логин и пароль для доступа к DNS. Их можно узнать, воспользовавшись инструкцией: Где можно увидеть доступы к Dedicated (выделенному серверу).

Управление ресурсными записями происходит в разделе Доменные имена — Записи:

Если домен был добавлен в панели DNSmanager

Это два сервера: https://ns5.hosting.reg.ru и https://ns6.hosting.reg.ru. Через них управлять зоной можно только в том случае, если домен был добавлен как «master» (Dedicated выступает в качестве вторичного DNS):

Если кликнуть на Записи, вы попадёте на страницу редактирования записей домена:

Если же домен был добавлен как «slave», то это означает, что Dedicated выступает в качестве первичного DNS, и редактировать зону необходимо непосредственно на нём.

Вы не помните, как привязывали домен к Dedicated

Если вы не помните, где именно добавляли домен, то просто проверьте поочерёдно:

• панель управления DNSmanager. Войдите в неё, используя логин и пароль для доступа к DNS:

18 раз уже помогла

Настройка 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:

sudo apt-get install bind9 bind9utils bind9-doc

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

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

sudo nano /etc/default/bind9

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

/etc/default/bind9

. . .
OPTIONS="-u bind -4"

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

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

sudo systemctl restart bind9

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

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

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

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

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

sudo nano /etc/bind/named.conf.options

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

/etc/bind/named.conf.options — 1 of 3

acl "trusted" {
        10.128.10.11;    # ns1 - can be set to localhost
        10.128.20.12;    # ns2
        10.128.100.101;  # host1
        10.128.200.102;  # host2
};

options {

        . . .

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

/etc/bind/named.conf.options — 2 of 3

        . . .
};

options {
        directory "/var/cache/bind";
        . . .
}

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

/etc/bind/named. conf.options — 3 of 3

        . . .

};

options {
        directory "/var/cache/bind";

        recursion yes;                 # enables resursive queries
        allow-recursion { trusted; };  # allows recursive queries from "trusted" clients
        listen-on { 10.128.10.11; };   # ns1 private IP address - listen on private network only
        allow-transfer { none; };      # disable zone transfers by default

        forwarders {
                8.8.8.8;
                8.8.4.4;
        };

        . . .
};

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

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

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

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

sudo nano /etc/bind/named.conf.local

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

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

/etc/bind/named.conf.local — 1 of 2

zone "nyc3.example.com" {
    type master;
    file "/etc/bind/zones/db.nyc3.example.com"; # zone file path
    allow-transfer { 10.128. 20.12; };           # ns2 private IP address - secondary
};

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

/etc/bind/named.conf.local — 2 of 2

    . . .
};

zone "128.10.in-addr.arpa" {
    type master;
    file "/etc/bind/zones/db.10.128";  # 10.128.0.0/16 subnet
    allow-transfer { 10.128.20.12; };  # ns2 private IP address - secondary
};

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

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

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

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

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

sudo mkdir /etc/bind/zones

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

sudo cp /etc/bind/db.local /etc/bind/zones/db. nyc3.example.com

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

sudo nano /etc/bind/zones/db.nyc3.example.com

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

/etc/bind/zones/db.nyc3.example.com — original

$TTL    604800
@       IN      SOA     localhost. root.localhost. (
                              2         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
@       IN      NS      localhost.      ; delete this line
@       IN      A       127.0.0.1       ; delete this line
@       IN      AAAA    ::1             ; delete this line

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

/etc/bind/zones/db.nyc3.example.com — updated 1 of 3

@       IN      SOA     ns1.nyc3.example.com. admin.nyc3.example.com. (
                              3         ; Serial

                              . . .

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

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

/etc/bind/zones/db.nyc3.example.com — updated 2 of 3

. . .

; name servers - NS records
    IN      NS      ns1. nyc3.example.com.
    IN      NS      ns2.nyc3.example.com.

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

/etc/bind/zones/db.nyc3.example.com — updated 3 of 3

. . .

; name servers - A records
ns1.nyc3.example.com.          IN      A       10.128.10.11
ns2.nyc3.example.com.          IN      A       10.128.20.12

; 10.128.0.0/16 - A records
host1.nyc3.example.com.        IN      A      10.128.100.101
host2.nyc3.example.com.        IN      A      10.128.200.102

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

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

/etc/bind/zones/db.nyc3.example.com — updated

$TTL    604800
@       IN      SOA     ns1.nyc3.example.com. admin.nyc3.example.com. (
                  3     ; Serial
             604800     ; Refresh
              86400     ; Retry
            2419200     ; Expire
             604800 )   ; Negative Cache TTL
;
; name servers - NS records
     IN      NS      ns1.nyc3.example.com.
     IN      NS      ns2.nyc3.example.com.

; name servers - A records
ns1.nyc3.example.com.          IN      A       10.128.10.11
ns2.nyc3.example.com.          IN      A       10.128.20.12

; 10.128.0.0/16 - A records
host1.nyc3.example.com.        IN      A      10.128.100.101
host2.nyc3.example.com.        IN      A      10.128.200.102

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

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

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

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

sudo cp /etc/bind/db.127 /etc/bind/zones/db.10.128

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

sudo nano /etc/bind/zones/db.10.128

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

/etc/bind/zones/db.10.128 — original

$TTL    604800
@       IN      SOA     localhost. root.localhost. (
                              1         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
@       IN      NS      localhost.      ; delete this line
1.0.0   IN      PTR     localhost.      ; delete this line

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

/etc/bind/zones/db.10.128 — updated 1 of 3

@       IN      SOA     ns1.nyc3.example.com. admin.nyc3.example.com. (
                              3         ; Serial

                              . . .

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

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

/etc/bind/zones/db.10.128 — updated 2 of 3

. . .

; name servers - NS records
      IN      NS      ns1.nyc3.example.com.
      IN      NS      ns2.nyc3.example.com.

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

/etc/bind/zones/db.10.128 — updated 3 of 3

. . .

; PTR Records
11.10   IN      PTR     ns1.nyc3.example.com.    ; 10.128.10.11
12.20   IN      PTR     ns2.nyc3.example.com.    ; 10.128.20.12
101.100 IN      PTR     host1.nyc3.example.com.  ; 10.128.100.101
102.200 IN      PTR     host2.nyc3.example.com.  ; 10.128.200.102

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

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

/etc/bind/zones/db.10.128 — updated

$TTL    604800
@       IN      SOA     nyc3.example.com. admin.nyc3.example.com. (
                              3         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
; name servers
      IN      NS      ns1.nyc3.example.com.
      IN      NS      ns2.nyc3.example.com.

; PTR Records
11.10   IN      PTR     ns1.nyc3.example.com.    ; 10.128.10.11
12.20   IN      PTR     ns2.nyc3.example.com.    ; 10.128.20.12
101.100 IN      PTR     host1.nyc3.example.com.  ; 10.128.100.101
102.200 IN      PTR     host2.nyc3.example.com.  ; 10.128.200.102

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

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

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

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

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

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

sudo named-checkzone nyc3.example.com db.nyc3.example.com

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

sudo named-checkzone 128.10.in-addr.arpa /etc/bind/zones/db.10.128

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

Перезапуск BIND

Перезапустите BIND:

sudo systemctl restart bind9

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

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

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

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

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

sudo nano /etc/bind/named.conf.options

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

/etc/bind/named.conf.options — updated 1 of 2 (secondary)

acl "trusted" {
        10.128.10.11;   # ns1
        10.128.20.12;   # ns2 - can be set to localhost
        10.128.100.101;  # host1
        10.128.200.102;  # host2
};

options {

        . . .

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

/etc/bind/named.conf.options — updated 2 of 2 (secondary)

        recursion yes;
        allow-recursion { trusted; };
        listen-on { 10.128.20.12; };      # ns2 private IP address
        allow-transfer { none; };          # disable zone transfers by default

        forwarders {
                8.8.8.8;
                8.8.4.4;
        };

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

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

sudo nano /etc/bind/named.conf.local

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

/etc/bind/named.conf.local — updated (secondary)

zone "nyc3.example.com" {
    type slave;
    file "db.nyc3.example.com";
    masters { 10.128.10.11; };  # ns1 private IP
};

zone "128.10.in-addr.arpa" {
    type slave;
    file "db.10.128";
    masters { 10.128.10.11; };  # ns1 private IP
};

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

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

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

sudo systemctl restart bind9

Разрешите подключение 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:

ip address show to 10.128.0.0/16

Output
3: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    inet 10.128.100.101/16 brd 10.128.255.255 scope global eth2
           valid_lft forever preferred_lft forever

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

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

sudo nano /etc/netplan/00-private-nameservers.yaml

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

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


/etc/netplan 00-private-nameservers.yaml

network:
    version: 2
    ethernets:
        eth2:                                 # Private network interface
            nameservers:
                addresses:
                - 10.128.10.11                # Private IP for ns1
                - 10.132.20.12                # Private IP for ns2
                search: [ nyc3.example.com ]  # DNS zone

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

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

Output
Warning: Stopping systemd-networkd.service, but it can still be activated by:
  systemd-networkd.socket
Do you want to keep these settings?


Press ENTER before the timeout to accept the new configuration


Changes will revert in 120 seconds

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

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

sudo systemd-resolve --status

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

Output
. . .
Link 3 (eth2)
      Current Scopes: DNS
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: 10.128.10.11
                      10.128.20.12
                      67.207.67.2
                      67.207.67.3
          DNS Domain: nyc3.example.com
. . .

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

Клиенты Ubuntu 16.04 и Debian

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

sudo nano /etc/network/interfaces

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

/etc/network/interfaces

    . . .

    dns-nameservers 10.128.10.11 10.128.20.12 8.8.8.8
    dns-search nyc3.example.com

    . . .

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

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

sudo ifdown --force eth0 && sudo ip addr flush dev eth0 && sudo ifup --force eth0

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

Output
RTNETLINK answers: No such process
Waiting for DAD... Done

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

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

Output
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 10.128.10.11
nameserver 10.128.20.12
nameserver 8.8.8.8
search nyc3.example.com

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

Клиенты CentOS

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

sudo nano /etc/sysconfig/network-scripts/ifcfg-eth0

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

/etc/sysconfig/network-scripts/ifcfg-eth0

. . .
DNS1=10.128.10.11
DNS2=10.128.20.12
DOMAIN='nyc3.example.com'
. . .

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

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

sudo systemctl restart network

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

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

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

/etc/resolv.conf

nameserver 10.128.10.11
nameserver 10.128.20.12
search nyc3.example.com

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

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

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

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

sudo yum install bind-utils

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

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

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

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

Output
Server:     127.0.0.53
Address:    127.0.0.53#53

Non-authoritative answer:
Name:   host1.nyc3.example.com
Address: 10.128.100.101

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

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

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

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

Output
11.10.128.10.in-addr.arpa   name = host1.nyc3.example.com.

Authoritative answers can be found from:

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

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

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

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

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

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

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

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

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

sudo named-checkconf
sudo named-checkzone nyc3.example.com db.nyc3.example.com
sudo named-checkzone 128.10.in-addr.arpa /etc/bind/zones/db.10.128

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

sudo systemctl reload bind9

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

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

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

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

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

sudo systemctl reload bind9

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

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

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

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

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

Заключение

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

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

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

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

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

Легенда

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

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

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

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

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

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

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

 
yum install -y bind bind-utils

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

 
    listen-on port 53 { 127.0.0.1;185.20.20.2; };
    allow-query { any; };

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

 
zone "NAME.site" IN {
    type master;
    file "NAME.site.zone";
    allow-update { none; };
};

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

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

 
$TTL 86400
@   IN  SOA     ns1.NAME.site. root.NAME.site (
        2014130401  ;Serial 
        3600        ;Refresh
        1800        ;Retry
        604800      ;Expire
        86400       ;Minimum TTL
)
; Указываем два name сервера
		IN	NS		ns1.NAME.site.
		IN	NS		ns2.NAME.site.
; Определяем IP адреса name серверов
ns1		IN	A		185.20.20.2
ns2		IN	A		185.20.20.2

; Define hostname -> IP нашего сервера для этого домена
@		IN	A		185.10.10.1
www		IN	A		185.10.10.1

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

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

Запускаем сервис:

 
systemctl enable named
systemctl start named

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

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

 
dig @185.20.20.2 NAME.site. axfr

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

Если dig в системе нет, то устанавливаем:

 
yum -y install bind-utils

Финал:

Руцент не хочет принимать вместо адреса ДНС сервера IP, поэтому нужно будет настроить два поддомена ns1.OLD.site и ns1.OLD.site (Обычные записи типа A), ссылающиеся на 185.10.10.1 (сервер, на котором поднят bind 9)

Настройка сервера имен (DNS-сервер) на сервере без ISPmanager

Статья давно не обновлялась, поэтому информация могла устареть.

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

Для работы серверов имен требуется два IP-адреса (это требование регистраторов доменов) и, следовательно, необходимо заказать второй адрес в биллинге для вашего сервера. Заказ выполняется в разделе Виртуальные серверы кнопка IP-адреса.

Настройка DNS в системе Debian

В шаблоне debian следует установить пакет bind

# apt-get install bind9

Отредактируйте файл /etc/bind/named.conf добавив в него описание вашей зоны (предположим, что домен называется example.com)

zone "example.com" {
        type master;
        file "/etc/bind/example.com";
};

Отредактируйте файл /etc/bind/example.com добавив в него строки

$TTL    3600
@  IN      SOA     ns1.example.com. root.example.com. (2012000001 10800 3600 604800 86400)

@  IN      NS      ns1
@  IN      NS      ns2

ns1     IN      A       10.10.10.10
ns2     IN      A       192.168.1.1

@       IN      A       10.10.10.10
www     IN      A       10.10.10.10

После чего можно перечитать конфигурацию DNS-сервера

# rndc reload

После приведенной настройки можно указывать сервера имен ns1.example.com/10.10.10.10 и ns2.example.com/192.168.1.1 у регистратора. В биллинге BILLmanager следует указывать записи через символ /, у регистраторов может быть меню Child Nameservers где указывается данное соответствие

Настройка DNS в системе Ubuntu

Пакет bind9 уже установлен в шаблоне ubuntu, его необходимо запустить и добавить в автозапуск

# /etc/init.d/bind9 start
# update-rc.d bind9 start 15 2 3 4 5 .  stop 70 0 1 6 .

Дальнейшая настройка выполняется точно также как в случае настройки на Debian

Настройка DNS в системе CentOS

DNS сервер уже предустановлен в шаблоне ПО centos. Его следует настроить и запустить.

Отредактируйте /etc/named.conf и удалите или закоментируйте символами // строки

listen-on port 53 { 127.0.0.1; };
allow-query     { localhost; };

Следующий шаг (создание и настройка использование rndc.key) можно пропустить если не будете пользоваться командой rndc — в таком случае перезапускайте DNS-сервер командой /etc/init.d/named restart

Создайте ключ /etc/rndc.key командой

# rndc-confgen -a

Добавьте в /etc/named.conf

key "rndc-key" {
      algorithm hmac-md5;
      secret "sUUony71pdPDHSZjNrkDFQ==";
};

controls {
       inet 127.0.0.1 port 953
       allow { 127.0.0.1; } keys { "rndc-key"; };
};

Строку secret

secret "sUUony71pdPDHSZjNrkDFQ==";

следует брать из файла /etc/rndc.key


Запустите named и добавьте его в автозапуск

/etc/init.d/named start
# chkconfig named --level 2345 on


Настройка зоны производится аналогично настройке на Debian / Ubuntu со следующими отличиями:

Файл конфигурации DNS-сервера /etc/named.conf

Зоны расположены в каталоге /var/named/

Настройка DNS в Windows 2008

Зайдите в Server manager — Roles и добавьте там (Add roles) DNS-сервер.

Далее в Start — Administrative Tools — DNS Manager — Forward Lookup Zones добавьте зону и в мастере создания зоны выберите Primary zone — Do not allow dynamic updates

После чего в том же приложении настраивается зона — создаются записи NS (вначале добавляется в форме IP-адрес, затем запись) и создаются записи типа A ns1 и ns2 на соответствующие IP-адреса

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

Проверить работоспособность полученной конфигурации можно используя команду dig. В Debian/Ubuntu устанавливается через apt-get пакет dnsutils

# apt-get install dnsutils

В CentOS Linux установка dig производится через менеджер пакетов yum — пакет bind-utils

# yum install bind-utils

# dig @10.10.10.10 example.com

; <<>> DiG 9.7.3 <<>> @10.10.10.10 example.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60489
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;example.com.                   IN      A

;; ANSWER SECTION:
example.com.            3600    IN      A       10.10.10.10

;; AUTHORITY SECTION:
example.com.            3600    IN      NS      ns2.example.com.
example.com.            3600    IN      NS      ns1.example.com.

;; ADDITIONAL SECTION:
ns1.example.com.        3600    IN      A       10.10.10.10
ns2.example.com.        3600    IN      A       192.168.1.1

;; Query time: 2 msec
;; SERVER: 10.10.10.10#53(10.10.10.10)
;; WHEN: Sat May 19 16:08:05 2012
;; MSG SIZE  rcvd: 113

Данной утилитой проверяется ответ сервера, то что ему известно про существование зоны и записи в ней.

что происходит, когда вы меняете IP-адрес сайта

Похоже, что на этом DNS-сервере запись 1.2.3.4 всё еще кэшируется в течение 144 секунд. Интересно, что если запросить 8.8.8.8 несколько раз, вы получите противоречивые результаты — иногда он выдает новый IP, а иногда старый. Вероятно, 8.8.8.8 на самом деле распределяет нагрузку на кучу разных бэкендов, у каждого из которых собственный кэш.

После пяти минут ожидания все кэши 8.8.8.8 обновились и всегда возвращали новую запись 5.6.7.8. Потрясающе. Это довольно быстро!

Не всегда можно полагаться на TTL

Как и в большинстве интернет-протоколов, не всё подчиняется спецификации DNS. Некоторые DNS-серверы интернет-провайдеров будут кэшировать записи дольше, чем указано в TTL. Например, в течение двух дней вместо пяти минут. И люди всегда могут жестко закодировать старый IP-адрес в своем файле /etc/hosts.

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

Вариант 2: обновление ваших серверов имен

Итак, мы видели, что когда вы обновляете IP-адрес, не меняя свои серверы имен, многие DNS-серверы довольно быстро получают новый IP-адрес. Отлично. Но что произойдет, если вы измените свои серверы имен? Давайте попробуем!

Я не хотела обновлять серверы имен для своего блога, поэтому вместо этого взяла другой свой домен и использовала его в примерах для журнала по HTTP: это examplecat.com.

Раньше мои серверы были установлены на dns1.p01.nsone.net. Я решила изменить их на серверы Google с адресами ns-cloud-b1.googledomains.com и так далее.

Когда я внесла изменения, мой доменный регистратор несколько зловеще высветил сообщение: «Изменения в examplecat.com сохранены. Они вступят в силу в течение ближайших 48 часов». Затем я установила новую запись A для домена, чтобы она указывала на 1.2.3.4.

Ладно, давайте посмотрим, изменилось ли что-нибудь:

Какой у меня DNS-сервер?

Этот сайт активно определяет DNS-серверы, которые использует ваш компьютер, наблюдая, как ваши DNS-запросы обрабатываются в Интернете.

Нажмите кнопку ниже, чтобы узнать, какие DNS-серверы использует ваш компьютер.

  ipconfig / registerdns
ipconfig / release
ipconfig / обновить  

  dscacheutil -flushcache  

  настройка сети -listallnetworkservices  

  networksetup -setv6off Wi-Fi  

  настройка сети -setv6off Ethernet