Как настроить BIND в качестве DNS-сервера частной сети в Ubuntu 22.04

Введение

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

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

Предпосылки

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

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

На каждом из этих серверов настройте администратора sudo и настройте брандмауэр, следуя нашему руководству по первоначальной настройке сервера Ubuntu 22.04.

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

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

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

Для целей данной статьи будем исходить из следующего:

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

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

Host	Role	Private FQDN	Private IP Address
ns1	Primary DNS Server	`ns1.nyc3.example.com`	`10.128.10.11`
ns2	Secondary DNS Server	`ns2.nyc3.example.com`	`10.128.20.12`
host1	Generic Host 1	`host1.nyc3.example.com`	`10.128.100.101`
host2	Generic Host 2	`host2.nyc3.example.com`	`10.128.200.102`

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

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

По мере того, как вы будете следовать этому руководству, будут моменты, когда вам придется запускать определенные команды на определенном сервере в этой настройке. Любые команды, которые должны выполняться на ns1, будут иметь синий фон, например:

Точно так же любые команды, которые должны выполняться на ns2, будут иметь красный фон:

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

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

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

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

Шаг 1 — Установка BIND на DNS-серверах

На обоих DNS-серверах, ns1 и ns2, обновите кэш пакетов apt, введя:

sudo apt update

Затем установите BIND на каждую машину:

sudo apt install bind9 bind9utils bind9-doc

Частная сеть DigitalOcean использует исключительно IPv4. Если это ваш случай, установите BIND в режим IPv4. На обоих серверах отредактируйте файл настроек по умолчанию named с помощью предпочитаемого вами текстового редактора. В следующем примере используется nano:

sudo nano /etc/default/named

Добавьте -4 в конец параметра OPTIONS:

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

Сохраните и закройте файл, когда закончите. Если вы использовали nano для редактирования файла, вы можете сделать это, нажав CTRL + X, Y, затем ENTER.

Перезапустите BIND, чтобы изменения вступили в силу:

sudo systemctl restart bind9

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

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

Конфигурация BIND состоит из нескольких файлов, включенных в основной файл конфигурации, named.conf. Имена этих файлов начинаются с named, потому что это имя процесса, который запускает BIND (где named является сокращением от \name daemon, например, \domain name daemon »). Мы начнем с настройки файла named.conf.options.

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

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

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

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

acl "trusted" {
        10.128.10.11;    # ns1 
        10.128.20.12;    # ns2
        10.128.100.101;  # host1
        10.128.200.102;  # host2
};

options {

        . . .

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

        . . .
};

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

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

        . . .

};

options {
        directory "/var/cache/bind";
        
        recursion yes;                 # enables recursive 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;
        };

        . . .
};

Обратите внимание на блок forwarders, который включает два IP-адреса: 8.8.8.8 и 8.8.4.4. Этот блок определяет форвардеры, специальный механизм, который BIND использует для уменьшения трафика по ссылкам на внешние серверы имен. BIND также может использовать серверы пересылки, чтобы разрешить запросы серверов, не имеющих прямого доступа к Интернету. Это может помочь ускорить ответы на эти запросы за счет снижения нагрузки на локальную сеть.

Два IP-адреса в этом блоке представляют общедоступные преобразователи DNS Google, но здесь будет работать IP-адрес любого общедоступного рекурсивного сервера имен. Например, вместо этого вы можете использовать IP-адрес DNS-сервера Cloudflare (1.1.1.1).

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

Далее вы укажете зоны DNS, настроив файл named.conf.local.

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

На 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:

. . .

zone "nyc3.example.com" {
    type primary;
    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):

    . . .
};

zone "128.10.in-addr.arpa" {
    type primary;
    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

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

$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 полным доменным именем ns1, затем замените root.localhost на admin.nyc3.example.com. Каждый раз, когда вы редактируете файл зоны, вам необходимо увеличивать значение Serial перед перезапуском процесса named. Здесь увеличьте его до 3:

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

                              . . .

Затем удалите три записи в конце файла (после записи SOA). Если вы не знаете, какие строки удалить, они помечены комментариями удалить эту строку в предыдущем примере.

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

. . .

; 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 следующим образом:

. . .

; 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

Наш последний пример файла зоны прямой пересылки будет содержать следующее содержимое:

$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

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

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

Создание файла(ов) обратной зоны

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

На ns1 для каждой обратной зоны, указанной в файле named.conf.local, создайте файл обратной зоны. Мы будем основывать наш пример файла(ов) обратной зоны на образце файла зоны db.127. BIND использует этот файл для хранения информации для локального интерфейса loopback; 127 — это первый октет IP-адреса, который представляет локальный хост (127.0.0.1). Скопируйте этот файл в нужное место с помощью следующих команд (заменив имя файла назначения, чтобы оно соответствовало вашему определению обратной зоны):

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

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

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

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

$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 и увеличить серийное значение:

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

                              . . .

Теперь удалите две записи в конце файла (после записи SOA). Если вы не знаете, какие строки удалить, в предыдущем примере они отмечены комментарием удалить эту строку.

. . .

; 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-адреса в соответствии с вашими серверами:

. . .

; 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

Ваш окончательный пример файла обратной зоны будет похож на следующий:

$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*:

sudo named-checkconf

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

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

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

sudo named-checkzone nyc3.example.com /etc/bind/zones/db.nyc3.example.com

Outputzone nyc3.example.com/IN: loaded serial 3
OK

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

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

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

Перезапуск привязки

Перезапустите привязку:

sudo systemctl restart bind9

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

sudo ufw allow Bind9

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

Шаг 3 — Настройка вторичного DNS-сервера

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

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

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

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

acl "trusted" {
        10.128.10.11;   # ns1
        10.128.20.12;   # ns2 
        10.128.100.101;  # host1
        10.128.200.102;  # host2
};

options {

        . . .

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

    . . .

        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

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

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

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

Теперь сохраните и закройте файл named.conf.local.

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

sudo named-checkconf

Если эта команда не возвращает никаких ошибок, перезапустите BIND:

sudo systemctl restart bind9

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

sudo ufw allow Bind9

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

Шаг 4 — Настройка DNS-клиентов

Прежде чем все ваши серверы в trusted ACL смогут запрашивать ваши DNS-серверы, вы должны настроить каждый из них для использования ns1 и ns2 в качестве серверов имен.

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

ip address show to 10.128.0.0/16

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

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

В Ubuntu 22.04 сеть настраивается с помощью Netplan, абстракции, которая позволяет вам писать стандартизированную конфигурацию сети и применять ее к совместимому сетевому программному обеспечению. Чтобы настроить DNS, вам нужно написать файл конфигурации Netplan.

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

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

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

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

Вы можете устранить неполадки в файле YAML с помощью средства проверки YAML, такого как YAML Lint.

network:
    version: 2
    ethernets:
        eth1:                                    # 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 автоматически откатит изменения после тайм-аута:

sudo netplan try

OutputWarning: 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 resolvectl status

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

Output. . .

Link 3 (eth1)
    Current Scopes: DNS
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 67.207.67.3
       DNS Servers: 10.128.10.11 10.128.20.12 67.207.67.3 67.207.67.2
        DNS Domain: nyc3.example.com

Теперь ваш клиент Ubuntu настроен на использование ваших внутренних DNS-серверов.

Шаг 5 — Тестирование клиентов

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

Вы можете начать с прямого поиска.

Прямой поиск

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

nslookup host1

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

OutputServer:     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:

nslookup 10.128.100.101

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

Output11.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).

В качестве последнего шага в этом учебном пособии вы узнаете, как вести записи зон.

Шаг 6 — Ведение записей DNS

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

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

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

Первичный сервер имен

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

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

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

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

sudo systemctl reload bind9

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

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

Добавьте частный IP-адрес нового хоста в доверенный список управления доступом (named.conf.options)

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

sudo named-checkconf

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

sudo systemctl reload bind9

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

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

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

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

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

Заключение

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

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

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