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

Введение

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

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

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

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

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

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

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

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

Для целей этой статьи мы будем предполагать следующее:

• У вас есть два сервера, которые будут выступать в качестве ваших 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. В следующей таблице приведены соответствующие детали, используемые в примерах в этом руководстве:

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

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

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

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

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

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

Давайте начнем установку 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”, что означает “демон доменного имени”). Мы начнем с настройки файла 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. Этот блок определяет forwarders, специальный механизм, который BIND использует для сокращения трафика по ссылкам на внешние именные серверы. BIND также может использовать переадресацию для разрешения запросов серверов, которые не имеют прямого доступа к интернету. Это может помочь ускорить ответы на эти запросы, уменьшив нагрузку на локальную сеть.

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

Когда вы закончите, сохраните и закройте файл named.conf.options. В приведенной выше конфигурации указано, что только ваши собственные серверы (так называемые trusted) смогут запрашивать ваш 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 на FQDN 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). Если вы не уверены, какие строки удалять, они помечены комментариями delete this line в предыдущем примере.

В конце файла добавьте записи своих серверов имен с помощью следующих строк (замените имена своими). Обратите внимание, что второй столбец указывает, что это записи 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.

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

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

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

На ns1, для каждой обратной зоны, указанной в файле named.conf.local, создайте файл обратной зоны. Мы будем основываться на примере файла зоны db.127. BIND использует этот файл для хранения информации для локального интерфейса обратной связи; 127 – это первый октет IP-адреса, представляющий localhost (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 и увеличить значение serial:

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

                              . . .

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

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

. . .

; 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

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

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

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

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

Output
zone 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.

Перезапуск BIND

Перезапустите 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-клиентов

Прежде чем все ваши серверы в ACL trusted смогут обращаться к вашим 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

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

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

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-сервера системы:

sudo resolvectl status

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

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 для проверки возможности ваших клиентов выполнять запросы к вашим серверам имен. Вы должны быть в состоянии это сделать на всех клиентах, которые вы настроили и которые находятся в ACL trusted.

Начните с выполнения прямого поиска.

Прямой поиск

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

nslookup host1

Запрос 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:

nslookup 10.128.100.101

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

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

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

Шаг 6 — Поддержание DNS-записей

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

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

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

Основной сервер имен

• Прямой файл зоны: Добавьте запись A для нового хоста, увеличьте значение Serial
• Обратный файл зоны: Добавьте запись PTR для нового хоста, увеличьте значение Serial
• Добавьте частный IP-адрес вашего нового хоста в trusted ACL (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-адрес вашего нового хоста в ACL trusted (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.