Поиск по сайту:

Как настроить Bind в качестве авторитетного DNS-сервера в Ubuntu 14.04


Введение

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

В этом руководстве мы обсудим, как установить и настроить DNS-сервер Bind9 в качестве полномочных DNS-серверов на компьютерах с Ubuntu 14.04. Мы настроим два Bind-сервера для нашего домена в первично-вторичной конфигурации.

Предпосылки и цели

Чтобы завершить это руководство, вам сначала необходимо ознакомиться с некоторыми общепринятыми терминами DNS. Ознакомьтесь с этим руководством, чтобы узнать о концепциях, которые мы будем реализовывать в этом руководстве.

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

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

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

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

В этом руководстве мы будем использовать фиктивный домен example.com. Вы должны заменить его доменом, который вы настраиваете. Вот детали машин, которые мы будем настраивать:

Purpose DNS FQDN IP Address
Primary name server ns1.example.com. 192.0.2.1
Secondary name server ns2.example.com. 192.0.2.2
Web Server www.example.com. 192.0.2.3

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

Установка имени хоста на серверах имен

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

Начните с изучения файла /etc/hosts. Откройте файл с привилегиями sudo в текстовом редакторе:

sudo nano /etc/hosts

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

127.0.0.1       localhost
127.0.1.1       ns1 ns1
. . .

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

127.0.0.1       localhost
192.0.2.1       ns1.example.com ns1
. . .

Сохраните и закройте файл, когда закончите.

Мы также должны изменить файл /etc/hostname, чтобы он содержал наше неполное имя хоста:

sudo nano /etc/hostname
ns1

Мы можем прочитать это значение в текущей работающей системе, набрав:

sudo hostname -F /etc/hostname

Мы хотим выполнить ту же процедуру на нашем вторичном сервере.

Начните с файла /etc/hosts:

sudo nano /etc/hosts
127.0.0.1       localhost
192.0.2.2       ns2.example.com ns2

Сохраните и закройте файл, когда закончите.

Затем измените файл /etc/hostname. Не забудьте использовать только фактический хост (в нашем примере просто ns2) для этого файла:

sudo nano /etc/hostname
ns2

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

sudo hostname -F /etc/hostname

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

Установите Bind на обоих серверах имен

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

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

sudo apt-get update
sudo apt-get install bind9 bind9utils bind9-doc

Запустите эту команду установки на первичном и вторичном DNS-серверах, чтобы получить соответствующие файлы.

Настройка основного сервера привязки

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

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

Первое, что мы настроим для начала, — это файл named.conf.options.

DNS-сервер Bind также известен как named. Основной файл конфигурации находится в /etc/bind/named.conf. Этот файл вызывает другие файлы, которые мы будем фактически настраивать.

Откройте файл параметров с привилегиями sudo в вашем редакторе:

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

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

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

        dnssec-validation auto;

        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { any; };
};

Главное, что нам нужно настроить в этом файле — это рекурсия. Поскольку мы пытаемся настроить только авторитетный сервер, мы не хотим включать рекурсию на этом сервере. Мы можем отключить это в блоке options.

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

options {
        directory "/var/cache/bind";
        recursion no;
        allow-transfer { none; };

        dnssec-validation auto;

        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { any; };
};

Когда вы закончите, сохраните и закройте файл.

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

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

Мы настраиваем домен example.com и не собираемся делегировать ответственность за какую-либо часть домена другим серверам. Таким образом, зона будет охватывать весь наш домен.

Чтобы настроить наши зоны, нам нужно открыть файл /etc/bind/named.conf.local с привилегиями sudo:

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

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

Для начала нам нужно настроить зону пересылки для нашего домена example.com. Прямая зона — это обычное преобразование имени в IP, о котором думает большинство из нас, когда мы обсуждаем DNS. Мы создаем блок конфигурации, определяющий доменную зону, которую мы хотим настроить:

zone "example.com" {
};

Примечание. Многие инструменты DNS, их файлы конфигурации и документация используют термины «ведущий» и «подчиненный», в то время как DigitalOcean обычно предпочитает альтернативные дескрипторы. Чтобы избежать путаницы, мы решили использовать термины «первичный» и «вторичный» для обозначения отношений между серверами и использовать термины «главный» или «подчиненный» только там, где этого требует директива конфигурации.

Внутри этого блока мы добавляем информацию об управлении этой зоной. Указываем отношение этого DNS-сервера к зоне. Это type master; в приведенном ниже примере зоны, поскольку мы настраиваем этот компьютер в качестве основного сервера имен для всех наших зон. Мы также указываем Bind на файл, содержащий фактические записи ресурсов, определяющие зону.

Мы собираемся хранить наши файлы основной зоны в подкаталоге с именем zones в каталоге конфигурации Bind. Мы назовем наш файл db.example.com, чтобы позаимствовать соглашение из других файлов зон в каталоге Bind. Теперь наш блок будет выглядеть так:

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

Мы хотим разрешить перенос этой зоны на наш вторичный сервер, нам нужно добавить такую строку:

zone "example.com" {
    type master;
    file "/etc/bind/zones/db.example.com";
    allow-transfer { 192.0.2.2; };
};

Далее мы собираемся определить обратную зону для нашего домена.

Немного об обратных зонах

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

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

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

Обратные зоны используются для обратного подключения IP-адреса к доменному имени. Однако система доменных имен изначально была разработана для прямого сопоставления, поэтому необходимо продумать ее, чтобы адаптировать ее для обеспечения обратного сопоставления.

Элементы информации, которые вам необходимо иметь в виду, чтобы понять обратное отображение:

  • В домене наиболее конкретная часть адреса находится слева. Наиболее конкретная часть IP-адреса находится справа.
  • Самая конкретная часть спецификации домена — это субдомен или имя хоста. Это определяется в файле зоны для домена.
  • Каждый субдомен, в свою очередь, может определять дополнительные субдомены или хосты.

Все сопоставления обратных зон определяются в рамках специального домена in-addr.arpa, который контролируется Управлением по присвоению номеров в Интернете (IANA). В этом домене существует дерево, которое использует поддомены для сопоставления каждого октета в IP-адресе. Чтобы убедиться, что специфика IP-адресов отражает специфичность обычных доменов, октеты IP-адресов фактически перевернуты.

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

Поскольку при использовании DNS мы определяем отдельные хосты (например, ведущую «1») в самом файле зоны, зона, которую мы будем настраивать, будет 2.0.192.in-addr.arpa. Если наш сетевой провайдер предоставил нам блок адресов /24, скажем, 192.0.2.0/24, они делегировали нам эту часть in-addr.arpa.

Теперь, когда вы знаете, как задать имя обратной зоны, фактическое определение точно такое же, как и для прямой зоны. Под определением зоны example.com создайте обратную зону для указанной сети. Опять же, это, вероятно, необходимо только в том случае, если вам был делегирован контроль над блоком адресов:

zone "2.0.192.in-addr.arpa" {
    type master;
    file "/etc/bind/zones/db.192.0.2";
};

Мы решили назвать файл db.192.0.2. Это относится к тому, что настраивает зона, и более удобочитаемо, чем обратная запись.

Сохраните и закройте файл, когда закончите.

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

Мы сообщили Bind о наших зонах прямой и обратной передачи, но еще не создали файлы, которые будут определять эти зоны.

Если вы помните, мы указали расположение файлов в подкаталоге с именем zones. Нам нужно создать этот каталог:

sudo mkdir /etc/bind/zones

Теперь мы можем использовать некоторые из уже существующих файлов зон в каталоге Bind в качестве шаблонов для файлов зон, которые мы хотим создать. Для прямой зоны файл db.local будет близок к тому, что нам нужно. Скопируйте этот файл в подкаталог zones с именем, используемым в файле named.conf.local.

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

Пока мы это делаем, мы можем скопировать шаблон и для обратной зоны. Мы будем использовать файл db.127, так как он точно соответствует тому, что нам нужно:

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

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

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

Файл будет выглядеть так:

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

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

Нам нужно заменить localhost. на полное доменное имя этой машины. Эта часть записи используется для определения любого сервера имен, который будет авторитетно отвечать для определяемой зоны. Это будет машина, которую мы сейчас настраиваем, в нашем случае ns1.example.com. (обратите внимание на точку в конце. Это важно для правильной регистрации нашей записи!).

Мы также хотим изменить следующую часть, которая на самом деле представляет собой специально отформатированный адрес электронной почты с заменой @ на точку. Мы хотим, чтобы наши электронные письма направлялись администратору домена, поэтому традиционная электронная почта — admin@example.com. Мы бы перевели это так, чтобы оно выглядело как admin.example.com.:

@       IN      SOA     ns1.example.com. admin.example.com. (

Следующей частью, которую нам нужно отредактировать, является серийный номер. Значение серийного номера — это то, как Bind сообщает, нужно ли отправлять обновленную информацию на вторичный сервер.

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

Одной из распространенных практик является использование соглашения для увеличения числа. Один из подходов заключается в использовании даты в формате ГГГГММДД вместе с номером версии дня, добавленным в конце. Таким образом, первая версия, сделанная 05 июня 2014 г., может иметь серийный номер 2014060501, а обновление, сделанное позже в тот же день, может иметь серийный номер 2014060502. Значение может быть 10-значным числом.

Стоит принять соглашение для простоты использования, но чтобы не усложнять нашу демонстрацию, мы просто установим наше значение 5 на данный момент:

@       IN      SOA     ns1.example.com. admin.example.com. (
                              5         ; Serial

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

Первое, что мы хотим установить после записи SOA, — это серверы имен для нашей зоны. Мы указываем домен, а затем два наших сервера имен, которые являются авторитетными для зоны, по имени. Поскольку эти серверы имен будут хостами внутри самого домена, это будет выглядеть немного самореферентным.

Для нашего руководства это будет выглядеть так. Опять же, обратите внимание на конечные точки!:

; Name servers
example.com.    IN      NS      ns1.example.com.
example.com.    IN      NS      ns2.example.com.

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

Итак, далее нам нужно создать записи A, которые будут связывать эти имена серверов имен с фактическими IP-адресами наших серверов имен:

; A records for name servers
ns1             IN      A       192.0.2.1
ns2             IN      A       192.0.2.2

Теперь, когда у нас есть записи A для успешного преобразования наших серверов имен в их правильные IP-адреса, мы можем добавить любые дополнительные записи. Помните, у нас есть веб-сервер на одном из наших хостов, который мы хотим использовать для обслуживания нашего сайта. Мы будем направлять запросы для общего домена (в нашем случае example.com) на этот хост, а также запросы для хоста www. Это будет выглядеть так:

; Other A records
@               IN      A       192.0.2.3
www             IN      A       192.0.2.3

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

Когда вы закончите, ваш файл должен выглядеть примерно так:

$TTL    604800
@       IN      SOA     ns1.example.com. admin.example.com. (
                              5         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;

; Name servers
example.com.    IN      NS      ns1.example.com.
example.com.    IN      NS      ns2.example.com.

; A records for name servers
ns1             IN      A       192.0.2.1
ns2             IN      A       192.0.2.2

; Other A records
@               IN      A       192.0.2.3
www             IN      A       192.0.2.3

Сохраните и закройте файл, когда закончите.

Создайте файл обратной зоны

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

Откройте файл в текстовом редакторе с правами sudo:

sudo nano db.192.0.2

Файл должен выглядеть так:

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

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

@       IN      SOA     example.com. admin.example.com. (
                              5         ; Serial

Снова удалите строки под закрывающей скобкой записи SOA. Мы возьмем последний октет каждого IP-адреса в нашем сетевом диапазоне и сопоставим его с полным доменным именем этого хоста, используя запись PTR. Каждый IP-адрес должен иметь только одну запись PTR, чтобы избежать проблем с некоторым программным обеспечением, поэтому вы должны выбрать имя хоста, с которым вы хотите выполнить обратное сопоставление.

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

Во-первых, нам нужно снова настроить наши серверы имен:

; Name servers
        IN      NS      ns1.example.com.
        IN      NS      ns2.example.com.

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

; PTR Records
1       IN      PTR      ns1.example.com.
2       IN      PTR      ns2.example.com.
3       IN      PTR      www.example.com.

Когда вы закончите, файл должен выглядеть примерно так:

$TTL    604800
@       IN      SOA     example.com. admin.example.com. (
                              5         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;

; Name servers
        IN      NS      ns1.example.com.
        IN      NS      ns2.example.com.

; PTR records
1       IN      PTR      ns1.example.com.
2       IN      PTR      ns2.example.com.
3       IN      PTR      www.example.com.

Сохраните и закройте файл, когда закончите.

Проверка файлов и перезапуск службы

Настройка основного сервера завершена, но нам еще нужно внести изменения.

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

Во-первых, мы можем проверить файлы named.conf.local и named.conf.options с помощью команды named-checkconf. Поскольку оба этих файла являются исходными файлами скелета named.conf, он проверит синтаксис файлов, которые мы изменили.

sudo named-checkconf

Если это возвращается без каких-либо сообщений, это означает, что файлы named.conf.local и named.conf.options синтаксически допустимы.

Затем вы можете проверить свои отдельные файлы зоны, передав домен, который обрабатывает зона, и местоположение файла зоны команде named-checkzone. Итак, для нашего руководства вы можете проверить файл зоны пересылки, набрав:

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

Если с вашим файлом все в порядке, он должен сказать вам, что он загрузил правильный серийный номер, и выдать сообщение «ОК»;

zone example.com/IN: loaded serial 5
OK

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

Вы можете проверить обратную зону, передав адрес in-addr.arpa и имя файла. Для нашей демонстрации мы должны ввести это:

sudo named-checkzone 2.0.192.in-addr.arpa /etc/bind/zones/db.192.0.2

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

zone 2.0.192.in-addr.arpa/IN: loaded serial 5
OK

Если все ваши файлы извлекаются, вы можете перезапустить службу Bind:

sudo service bind9 restart

Вы должны проверить журналы, набрав:

sudo tail -f /var/log/syslog

Следите за этим журналом, чтобы убедиться в отсутствии ошибок.

Настройка вторичного сервера привязки

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

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

Опять же, мы начнем с файла named.conf.options. Откройте его с правами sudo в текстовом редакторе:

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

Мы внесем в этот файл те же изменения, что и в файл нашего основного сервера.

options {
        directory "/var/cache/bind";
        recursion no;
        allow-transfer { none; };

        dnssec-validation auto;

        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { any; };
};

Сохраните и закройте файл, когда закончите.

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

Далее мы настроим файл named.conf.local на вторичном сервере. Откройте его с правами sudo в текстовом редакторе:

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

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

Сначала поработаем над форвардной зоной. Начните его так же, как и в основном файле:

zone "example.com" {
};

На этот раз мы собираемся установить type на slave, так как этот сервер действует как вторичный для этой зоны. Это просто означает, что он получает свои файлы зоны через передачу, а не файл в локальной системе. Кроме того, мы просто укажем относительное имя файла вместо абсолютного пути к файлу зоны.

Причина этого в том, что для дополнительных зон Bind хранит файлы /var/cache/bind. Bind уже настроен на поиск в этом каталоге, поэтому нам не нужно указывать путь.

Для нашей форвардной зоны эти детали будут выглядеть так:

zone "example.com" {
    type slave;
    file "db.example.com";
};

Наконец, вместо директивы allow-transfer мы укажем первичные серверы по IP-адресу, с которых этот сервер будет принимать передачу зоны. Это делается в директиве masters:

zone "example.com" {
    type slave;
    file "db.example.com";
    masters { 192.0.2.1; };
};

Это завершает нашу спецификацию прямой зоны. Мы можем использовать этот же точный формат, чтобы позаботиться о нашей спецификации обратной зоны:

zone "2.0.192.in-addr.arpa" {
    type slave;
    file "db.192.0.2";
    masters { 192.0.2.1; };
};

Когда вы закончите, вы можете сохранить и закрыть файл.

Проверка файлов и перезапуск службы

На самом деле нам не нужно создавать какие-либо файлы зоны на дополнительном компьютере, потому что, как мы упоминали ранее, этот сервер будет получать файлы зоны с основного сервера. Итак, мы готовы к испытаниям.

Опять же, мы должны проверить синтаксис файла конфигурации. Поскольку у нас нет файлов зон для проверки, нам нужно использовать только инструмент named-checkconf:

sudo named-checkconf

Если это возвращается без каких-либо ошибок, это означает, что файлы, которые вы изменили, не имеют синтаксических ошибок.

В этом случае вы можете перезапустить службу Bind:

sudo service bind9 restart

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

sudo tail -f /var/log/syslog

Вы должны увидеть некоторые записи, указывающие на то, что файлы зоны были переданы правильно.

Делегируйте полномочия своим серверам имен

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

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

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

Вместо того, чтобы регистратор просто делегировал полномочия для зоны с помощью записей NS, ему потребуется создать связующую запись. Связующая запись — это запись A, которая указывает IP-адреса для серверов имен после указания серверов имен, которым она делегирует полномочия.

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

Поэтому вам нужно найти раздел панели управления вашего регистратора доменов, который позволяет указать серверы имен и их IP-адреса.

В качестве демонстрации у регистратора Namecheap есть два разных раздела сервера имен.

Существует раздел под названием «Регистрация сервера имен», который позволяет указать IP-адреса для серверов имен в вашем домене:

Внутри вы сможете ввести IP-адреса серверов имен, существующих в домене:

Это создаст запись A, которая служит связующими записями, которые вам нужны в файле родительской зоны.

После того, как вы это сделаете, вы сможете изменить активные серверы имен на серверы вашего домена. В NameCheap это делается с помощью пункта меню «Настройка сервера доменных имен»:

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

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

Заключение

Теперь у вас должно быть два авторитетных DNS-сервера, настроенных для обслуживания ваших доменов. Их можно использовать для хранения информации о зоне для дополнительных доменов по мере их приобретения.

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