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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

sudo systemctl restart bind9

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

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

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

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

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

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

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

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

options {

        . . .

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

        . . .
};

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

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

        . . .

};

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

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

        forwarders {
                8.8.8.8;
                8.8.4.4;
        };

        . . .
};

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

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

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

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

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

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

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

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

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

    . . .
};

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

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

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

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

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

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

sudo mkdir /etc/bind/zones

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

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

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

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

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

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

@       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

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

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

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

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

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

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

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

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

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

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

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

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

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

$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

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

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

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

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

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

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

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

Перезапуск BIND

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

sudo systemctl restart bind9

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

sudo ufw allow Bind9

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

Настройка дополнительного 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 - can be set to localhost
        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

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

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

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

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

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

sudo named-checkconf

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

sudo systemctl restart bind9

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

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:

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

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

Вставьте в файл следующее содержимое. Вам потребуется изменить интерфейс частной сети, адреса ваших DNS-серверов ns1 и ns2, а также зону 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-преобразователь системы, чтобы определить, применены ли изменения в конфигурацию DNS:

sudo systemd-resolve --status

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

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

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

Клиенты Ubuntu 16.04 и Debian

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

sudo nano /etc/network/interfaces

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

    . . .

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

    . . .

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

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

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

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

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

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

cat /etc/resolv.conf

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

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

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

Клиенты CentOS

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

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

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

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

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

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

sudo systemctl restart network

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

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

cat /etc/resolv.conf

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

nameserver 10.128.10.11
nameserver 10.128.20.12
search nyc3.example.com

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

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

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

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

sudo yum install bind-utils

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

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

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

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

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

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

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

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

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

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

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

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

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

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

sudo systemctl reload bind9

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

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

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

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

sudo named-checkconf

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

sudo systemctl reload bind9

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

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

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

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

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

Заключение

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

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