Введение

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

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

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

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

bind illustration for: Предварительные требования

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

  • Свежий сервер 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. Соответствующую информацию см. в следующей таблице:

Хост Роль Частное FQDN Частный IP-адрес

—|—|—|—

ns1 Основной DNS-сервер ns1.nyc3.example.com 10.128.10.11
ns2 Дополнительный DNS-сервер ns2.nyc3.example.com 10.128.20.12
host1 Стандартный хост 1 host1.nyc3.example.com 10.128.100.101
host2 Стандартный хост 2 host2.nyc3.example.com 10.128.200.102

Примечание: существующая настройка будет отличаться, примеры имен и 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 с помощью следующей команды:

				
					
sudo apt-get update

				
			

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

				
					
sudo apt-get install bind9 bind9utils bind9-doc

				
			

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

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

				
					
sudo nano /etc/default/bind9

				
			

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

				
					
[label /etc/default/bind9]

. . .

OPTIONS="-u bind &lt;^&gt;-4&lt;^&gt;"

				
			

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

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

				
					
sudo systemctl restart bind9

				
			

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

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

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

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

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

				
					
[environment second]

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

				
			

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

				
					
[label /etc/bind/named.conf.options — 1 of 3]

[environment second]

acl "trusted" {

 &lt;^&gt;10.128.10.11&lt;^&gt;; # ns1 - can be set to localhost

 &lt;^&gt;10.128.20.12&lt;^&gt;; # ns2

 &lt;^&gt;10.128.100.101&lt;^&gt;; # host1

 &lt;^&gt;10.128.200.102&lt;^&gt;; # host2

};



options {



 . . .

				
			

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

				
					
[label /etc/bind/named.conf.options — 2 of 3]

[environment second]

 . . .

};



options {

 directory "/var/cache/bind";

 . . .

}

				
			

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

				
					
[label /etc/bind/named.conf.options — 3 of 3]

[environment second]

 . . .



};



options {

 directory "/var/cache/bind";



 &lt;^&gt;recursion yes;&lt;^&gt; # enables resursive queries

 &lt;^&gt;allow-recursion { trusted; };&lt;^&gt; # allows recursive queries from "trusted" clients

 &lt;^&gt;listen-on { 10.128.10.11; };&lt;^&gt; # ns1 private IP address - listen on private network only

 &lt;^&gt;allow-transfer { none; };&lt;^&gt; # disable zone transfers by default



 &lt;^&gt;forwarders {&lt;^&gt;

 &lt;^&gt;8.8.8.8;&lt;^&gt;

 &lt;^&gt;8.8.4.4;&lt;^&gt;

 &lt;^&gt;};&lt;^&gt;



 . . .

};

				
			

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

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

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

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

				
					
[environment second]

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

				
			

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

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

				
					
[label /etc/bind/named.conf.local — 1 of 2]

[environment second]

zone "&lt;^&gt;nyc3.example.com&lt;^&gt;" {

 type master;

 file "/etc/bind/zones/db.&lt;^&gt;nyc3.example.com&lt;^&gt;"; # zone file path

 allow-transfer { &lt;^&gt;10.128.20.12&lt;^&gt;; }; # ns2 private IP address - secondary

};

				
			

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

				
					
[label /etc/bind/named.conf.local — 2 of 2]

[environment second]

 . . .

};



zone "&lt;^&gt;128.10&lt;^&gt;.in-addr.arpa" {

 type master;

 file "/etc/bind/zones/db.&lt;^&gt;10.128&lt;^&gt;"; # 10.128.0.0/16 subnet

 allow-transfer { &lt;^&gt;10.128.20.12&lt;^&gt;; }; # ns2 private IP address - secondary

};

				
			

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

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

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

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

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

				
					
[environment second]

sudo mkdir /etc/bind/zones

				
			

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

				
					
[environment second]

sudo cp /etc/bind/db.local /etc/bind/zones/db.&lt;^&gt;nyc3.example.com&lt;^&gt;

				
			

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

				
					
[environment second]

sudo nano /etc/bind/zones/db.&lt;^&gt;nyc3.example.com&lt;^&gt;

				
			

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

				
					
[label /etc/bind/zones/db.nyc3.example.com — original]

[environment second]

$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". Теперь файл должен выглядеть примерно следующим образом:

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

[environment second]

@ IN SOA &lt;^&gt;ns1.nyc3.example.com&lt;^&gt;. &lt;^&gt;admin&lt;^&gt;.&lt;^&gt;nyc3.example.com&lt;^&gt;. (

 &lt;^&gt;3&lt;^&gt; ; Serial



 . . .

				
			

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

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

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

[environment second]

. . .



; name servers - NS records

 IN NS ns1.&lt;^&gt;nyc3.example.com&lt;^&gt;.

 IN NS ns2.&lt;^&gt;nyc3.example.com&lt;^&gt;.

				
			

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

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

[environment second]

. . .



; name servers - A records

ns1.&lt;^&gt;nyc3.example.com&lt;^&gt;. IN A &lt;^&gt;10.128.10.11&lt;^&gt;

ns2.&lt;^&gt;nyc3.example.com&lt;^&gt;. IN A &lt;^&gt;10.128.20.12&lt;^&gt;



; 10.128.0.0/16 - A records

&lt;^&gt;host1.nyc3.example.com&lt;^&gt;. IN A &lt;^&gt;10.128.100.101&lt;^&gt;

&lt;^&gt;host2.nyc3.example.com&lt;^&gt;. IN A &lt;^&gt;10.128.200.102&lt;^&gt;

				
			

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

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

				
					
[label /etc/bind/zones/db.nyc3.example.com — updated]

[environment second]

$TTL 604800

@ IN SOA &lt;^&gt;ns1.nyc3.example.com&lt;^&gt;. admin.&lt;^&gt;nyc3.example.com&lt;^&gt;. (

 &lt;^&gt;3&lt;^&gt; ; Serial

 604800 ; Refresh

 86400 ; Retry

 2419200 ; Expire

 604800 ) ; Negative Cache TTL

;

; name servers - NS records

 IN NS ns1.&lt;^&gt;nyc3.example.com&lt;^&gt;.

 IN NS ns2.&lt;^&gt;nyc3.example.com&lt;^&gt;.



; name servers - A records

ns1.&lt;^&gt;nyc3.example.com&lt;^&gt;. IN A &lt;^&gt;10.128.10.11&lt;^&gt;

ns2.&lt;^&gt;nyc3.example.com&lt;^&gt;. IN A &lt;^&gt;10.128.20.12&lt;^&gt;



; 10.128.0.0/16 - A records

&lt;^&gt;host1.nyc3.example.com&lt;^&gt;. IN A &lt;^&gt;10.128.100.101&lt;^&gt;

&lt;^&gt;host2.nyc3.example.com&lt;^&gt;. IN A &lt;^&gt;10.128.200.102&lt;^&gt;

				
			

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

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

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

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

				
					
[environment second]

sudo cp /etc/bind/db.127 /etc/bind/zones/db.&lt;^&gt;10.128&lt;^&gt;

				
			

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

				
					
[environment second]

sudo nano /etc/bind/zones/db.&lt;^&gt;10.128&lt;^&gt;

				
			

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

				
					
[label /etc/bind/zones/db.10.128 — original]

[environment second]

$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. Он должен выглядеть следующим образом:

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

[environment second]

@ IN SOA &lt;^&gt;ns1.nyc3.example.com&lt;^&gt;. &lt;^&gt;admin&lt;^&gt;.&lt;^&gt;nyc3.example.com&lt;^&gt;. (

 &lt;^&gt;3&lt;^&gt; ; Serial



 . . .

				
			

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

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

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

[environment second]

. . .



; name servers - NS records

 IN NS ns1.&lt;^&gt;nyc3.example.com&lt;^&gt;.

 IN NS ns2.&lt;^&gt;nyc3.example.com&lt;^&gt;.

				
			

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

				
					
[label /etc/bind/zones/db.10.128 — updated 3 of 3]

[environment second]

. . .



; PTR Records

&lt;^&gt;11.10&lt;^&gt; IN PTR ns1.&lt;^&gt;nyc3.example.com&lt;^&gt;. ; 10.128.10.11

&lt;^&gt;12.20&lt;^&gt; IN PTR ns2.&lt;^&gt;nyc3.example.com&lt;^&gt;. ; 10.128.20.12

&lt;^&gt;101.100&lt;^&gt; IN PTR &lt;^&gt;host1.nyc3.example.com&lt;^&gt;. ; 10.128.100.101

&lt;^&gt;102.200&lt;^&gt; IN PTR &lt;^&gt;host2.nyc3.example.com&lt;^&gt;. ; 10.128.200.102

				
			

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

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

				
					
[label /etc/bind/zones/db.10.128 — updated]

[environment second]

$TTL 604800

@ IN SOA &lt;^&gt;nyc3.example.com&lt;^&gt;. admin.nyc3.example.com. (

 &lt;^&gt;3&lt;^&gt; ; Serial

 604800 ; Refresh

 86400 ; Retry

 2419200 ; Expire

 604800 ) ; Negative Cache TTL

; name servers

 IN NS ns1.&lt;^&gt;nyc3.example.com&lt;^&gt;.

 IN NS ns2.&lt;^&gt;nyc3.example.com&lt;^&gt;.



; PTR Records

&lt;^&gt;11.10&lt;^&gt; IN PTR ns1.&lt;^&gt;nyc3.example.com&lt;^&gt;. ; 10.128.10.11

&lt;^&gt;12.20&lt;^&gt; IN PTR ns2.&lt;^&gt;nyc3.example.com&lt;^&gt;. ; 10.128.20.12

&lt;^&gt;101.100&lt;^&gt; IN PTR &lt;^&gt;host1.nyc3.example.com&lt;^&gt;. ; 10.128.100.101

&lt;^&gt;102.200&lt;^&gt; IN PTR &lt;^&gt;host2.nyc3.example.com&lt;^&gt;. ; 10.128.200.102

				
			

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

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

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

				
					
[environment second]

sudo named-checkconf

				
			

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

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

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

				
					
[environment second]

sudo named-checkzone &lt;^&gt;nyc3.example.com&lt;^&gt; db.&lt;^&gt;nyc3.example.com&lt;^&gt;

				
			

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

				
					
[environment second]

sudo named-checkzone &lt;^&gt;128.10&lt;^&gt;.in-addr.arpa /etc/bind/zones/db.&lt;^&gt;10.128&lt;^&gt;

				
			

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

Перезапуск BIND

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

				
					
[environment second]

sudo systemctl restart bind9

				
			

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

				
					
[environment second]

sudo ufw allow Bind9

				
			

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

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

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

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

				
					
[environment third]

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

				
			

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

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

[environment third]

acl "trusted" {

 &lt;^&gt;10.128.10.11&lt;^&gt;; # ns1

 &lt;^&gt;10.128.20.12&lt;^&gt;; # ns2 - can be set to localhost

 &lt;^&gt;10.128.100.101&lt;^&gt;; # host1

 &lt;^&gt;10.128.200.102&lt;^&gt;; # host2

};



options {



 . . .

				
			

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

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

[environment third]

 recursion yes;

 allow-recursion { trusted; };

 listen-on { &lt;^&gt;10.128.20.12&lt;^&gt;; }; # 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:

				
					
[environment third]

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

				
			

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

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

[environment third]

zone "&lt;^&gt;nyc3.example.com&lt;^&gt;" {

 type slave;

 file "db.&lt;^&gt;nyc3.example.com&lt;^&gt;";

 masters { &lt;^&gt;10.128.10.11&lt;^&gt;; }; # ns1 private IP

};



zone "&lt;^&gt;128.10&lt;^&gt;.in-addr.arpa" {

 type slave;

 file "db.&lt;^&gt;10.128&lt;^&gt;";

 masters { &lt;^&gt;10.128.10.11&lt;^&gt;; }; # ns1 private IP

};

				
			

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

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

				
					
[environment third]

sudo named-checkconf

				
			

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

				
					
[environment third]

sudo systemctl restart bind9

				
			

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

				
					
[environment third]

sudo ufw allow Bind9

				
			

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

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

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

Клиенты Ubuntu 18.04

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

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

				
					
[environment fourth]

ip address show to &lt;^&gt;10.128.0.0/16&lt;^&gt;

				
			
				
					
[secondary_label Output]

[environment fourth]

3: &lt;^&gt;eth1&lt;^&gt;: &lt;BROADCAST,MULTICAST,UP,LOWER_UP&gt; mtu 1500 qdisc fq_codel state UP group default qlen 1000

 inet 10.128.100.101/16 brd 10.128.255.255 scope global eth1

 valid_lft forever preferred_lft forever

				
			

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

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

				
					
[environment fourth]

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

				
			

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

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

				
					
[label /etc/netplan 00-private-nameservers.yaml]

[environment fourth]

network:

 version: 2

 ethernets:

 &lt;^&gt;eth1&lt;^&gt;:									# Private network interface

 nameservers:

 addresses:

 - &lt;^&gt;10.128.10.11&lt;^&gt;				# Private IP for ns1

 - &lt;^&gt;10.132.20.12&lt;^&gt;				# Private IP for ns2

 search: [ &lt;^&gt;nyc3.example.com&lt;^&gt; ]	# DNS zone



				
			

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

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

				
					
[environment fourth]

sudo netplan try

				
			
				
					
[secondary_label Output]

[environment fourth]

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:

				
					
[environment fourth]

sudo systemd-resolve --status

				
			

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

				
					
[secondary_label Output]

[environment fourth]

. . .

Link 3 (eth1)

 Current Scopes: DNS

 LLMNR setting: yes

MulticastDNS setting: no

 DNSSEC setting: no

 DNSSEC supported: no

 DNS Servers: &lt;^&gt;10.128.10.11&lt;^&gt;

 &lt;^&gt;10.128.20.12&lt;^&gt;

 67.207.67.2

 67.207.67.3

 DNS Domain: &lt;^&gt;nyc3.example.com&lt;^&gt;

. . .

				
			

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

Клиенты Ubuntu 16.04 и Debian

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

				
					
[environment fourth]

sudo nano /etc/network/interfaces

				
			

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

				
					
[label /etc/network/interfaces]

[environment fourth]

 . . .



 dns-nameservers &lt;^&gt;10.128.10.11&lt;^&gt; &lt;^&gt;10.128.20.12&lt;^&gt; 8.8.8.8

 &lt;^&gt;dns-search nyc3.example.com&lt;^&gt;



 . . .

				
			

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

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

				
					
[environment fourth]

sudo ifdown --force &lt;^&gt;eth0&lt;^&gt; &amp;&amp; sudo ip addr flush dev &lt;^&gt;eth0&lt;^&gt; &amp;&amp; sudo ifup --force &lt;^&gt;eth0&lt;^&gt;

				
			

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

				
					
[secondary_label Output]

[environment fourth]

RTNETLINK answers: No such process

Waiting for DAD... Done

				
			

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

				
					
[environment fourth]

cat /etc/resolv.conf

				
			

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

				
					
[secondary_label Output]

[environment fourth]

# 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 на имя вашего основного сетевого интерфейса:

				
					
[environment fourth]

sudo nano /etc/sysconfig/network-scripts/ifcfg-&lt;^&gt;eth0&lt;^&gt;

				
			

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

				
					
[label /etc/sysconfig/network-scripts/ifcfg-eth0]

[environment fourth]

. . .

DNS1=&lt;^&gt;10.128.10.11&lt;^&gt;

DNS2=&lt;^&gt;10.128.20.12&lt;^&gt;

&lt;^&gt;DOMAIN='nyc3.example.com'&lt;^&gt;

. . .

				
			

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

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

				
					
[environment fourth]

sudo systemctl restart network

				
			

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

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

				
					
[environment fourth]

cat /etc/resolv.conf

				
			

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

				
					
[label /etc/resolv.conf]

[environment fourth]

nameserver 10.128.10.11

nameserver 10.128.20.12

search nyc3.example.com

				
			

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

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

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

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

				
					
[environment fourth]

sudo yum install bind-utils

				
			

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

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

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

				
					
[environment fourth]

nslookup host1

				
			

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

				
					
[secondary_label Output]

[environment fourth]

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:

				
					
[environment fourth]

nslookup 10.128.100.101

				
			

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

				
					
[secondary_label Output]

[environment fourth]

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)

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

				
					
[environment second]

sudo named-checkconf

sudo named-checkzone &lt;^&gt;nyc3.example.com&lt;^&gt; db.&lt;^&gt;nyc3.example.com&lt;^&gt;

sudo named-checkzone &lt;^&gt;128.10&lt;^&gt;.in-addr.arpa /etc/bind/zones/db.&lt;^&gt;10.128&lt;^&gt;

				
			

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

				
					
[environment second]

sudo systemctl reload bind9

				
			

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

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

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

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

				
					
[environment third]

sudo named-checkconf

				
			

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

				
					
[environment third]

sudo systemctl reload bind9

				
			

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

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

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

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

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

Заключение

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

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