Вступление
DNS, или Система доменных имен, часто является сложным компонентом, который нужно понять, когда вы учитесь настраивать веб-сайты и серверы. Хотя большинство людей, вероятно, решат использовать DNS-серверы, предоставленные их хостинговой компанией или регистратором доменов, у вас есть некоторые преимущества в создании собственных DNS-серверов.
В этом руководстве мы обсудим, как установить и настроить DNS-сервер Bind9 в качестве авторитетных DNS-серверов на компьютерах с Ubuntu 14.04. Мы настроим эти два сервера Bind для нашего домена в первичной-вторичной конфигурации.
Предпосылки и цели
Чтобы завершить это руководство, вам сначала необходимо ознакомиться с некоторой общей терминологией DNS. Ознакомьтесь сthis guide, чтобы узнать о концепциях, которые мы будем реализовывать в этом руководстве.
Вам также понадобится как минимум два сервера. Один будет для «первичного» DNS-сервера, на котором будут создаваться файлы зон для нашего домена, а второй будет «вторичным» сервером, который будет получать данные зоны посредством передачи и будет доступен в случае отказа другого сервера. Это позволяет избежать опасности наличия единой точки отказа для ваших DNS-серверов.
В отличие отcaching or forwarding DNS servers или многоцелевого DNS-сервера, авторитетные серверы отвечают только на итеративные запросы для зон, для которых они являются полномочными. Это означает, что если сервер не знает ответа, он просто скажет клиенту (обычно какой-то разрешающий DNS-сервер), что он не знает ответа, и даст ссылку на сервер, который может знать больше.
Авторитетные DNS-серверы часто являются хорошей конфигурацией для обеспечения высокой производительности, поскольку они не имеют накладных расходов на разрешение рекурсивных запросов от клиентов. Они заботятся только о зонах, для которых они предназначены.
В этом руководстве мы будем ссылаться на серверыthree. Два сервера имен, упомянутых выше, плюс веб-сервер, который мы хотим настроить в качестве хоста в нашей зоне.
В этом руководстве мы будем использовать фиктивный доменexample.com. Вы должны заменить его доменом, который вы настраиваете. Вот детали машин, которые мы будем настраивать:
| Цель | Полное доменное имя DNS | Айпи адрес |
|---|---|---|
Первичный сервер имен |
ns1.example.com. |
192.0.2.1 |
Вторичный сервер имен |
ns2.example.com. |
192.0.2.2 |
Веб сервер |
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/hostnamens1Мы можем прочитать это значение в работающей в данный момент системе, набрав:
sudo hostname -F /etc/hostnameМы хотим выполнить ту же процедуру на нашем вторичном сервере.
Начнем с файла/etc/hosts:
sudo nano /etc/hosts127.0.0.1 localhost
192.0.2.2 ns2.example.com ns2Сохраните и закройте файл, когда вы закончите.
Затем измените файл/etc/hostname. Не забудьте использовать только фактический хост (толькоns2 в нашем примере) для этого файла:
sudo nano /etc/hostnamens2Снова, прочитайте файл, чтобы изменить текущую систему:
sudo hostname -F /etc/hostnameТеперь на ваших серверах должны быть правильно определены определения хостов.
Установите Bind на обоих серверах имен
Теперь на каждом из ваших серверов имен вы можете установить Bind, DNS-сервер, который мы будем использовать.
Программное обеспечение Bind доступно в репозиториях Ubuntu по умолчанию, поэтому нам просто нужно обновить наш локальный индекс пакета и установить программное обеспечение с помощьюapt. Мы также включим документацию и некоторые общие утилиты:
sudo apt-get update
sudo apt-get install bind9 bind9utils bind9-docЗапустите эту команду установки на основном и дополнительном DNS-серверах, чтобы получить соответствующие файлы.
Настройте основной сервер Bind
Теперь, когда у нас установлено программное обеспечение, мы можем начать с настройки вашего 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" {
};[.note] #Note:Many DNS tools, their configuration files, and documentation use the terms “master” and “slave” while DigitalOcean generally prefers alternative descriptors. To avoid confusion we’ve chosen to use the terms “primary” and “secondary” to denote relationships between servers, and only use “master” or “slave” where a configuration directive requires it.
#
Внутри этого блока мы добавляем управляющую информацию об этой зоне. Мы указываем отношение этого 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, который контролируется Internet Assigned Numbers Authority (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. (обратите внимание на конечную точку. Это важно для правильной регистрации нашей записи!).
Мы также хотим изменить следующий фрагмент, который на самом деле представляет собой специально отформатированный адрес электронной почты с заменой@ точкой. Мы хотим, чтобы наши электронные письма отправлялись администратору домена, поэтому традиционный адрес электронной почты -[email protected]. Мы бы перевели это так, чтобы оно выглядело какadmin.example.com.:
@ IN SOA ns1.example.com. admin.example.com. (Следующая часть, которую нам нужно отредактировать, это серийный номер. Значение серийного номера - то, как Bind сообщает, нужно ли ему отправлять обновленную информацию на вторичный сервер.
Note: Невозможность увеличить серийный номер - одна из наиболее распространенных ошибок, которая приводит к проблемам с обновлениями зоны. Каждый раз, когда вы вносите правку, выmust нажимаете серийный номер.
Одним из распространенных методов является использование соглашения для увеличения числа. Один из подходов заключается в использовании даты в формате ГГГГММДД вместе с номером редакции для дня, добавленного в конец. Таким образом, первая редакция, сделанная 5 июня 2014 года, может иметь серийный номер 2014060501, а обновление, сделанное позднее в тот же день, может иметь серийный номер 2014060502. Значение может быть десятизначным числом.
Для простоты использования стоит принять соглашение, но, чтобы упростить нашу демонстрацию, мы пока просто установим для нас значение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 basics guide, чтобы ознакомиться с некоторыми из ваших вариантов создания дополнительных записей.
Когда вы закончите, ваш файл должен выглядеть примерно так:
$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Следите за этим журналом, чтобы убедиться в отсутствии ошибок.
Настройте вторичный сервер Bind
Теперь, когда у нас настроен первичный сервер, мы можем приступить к настройке вторичного сервера. Это будет значительно проще, чем основной сервер.
Настройка файла опций
Опять же, мы начнем с файла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Вы должны увидеть некоторые записи, которые указывают, что файлы зон были переданы правильно.
Делегируйте полномочия вашим серверам имен
Ваши авторитетные серверы имен должны быть полностью настроены. Однако вам все равно нужно делегировать полномочия для вашего домена вашим серверам имен.
Для этого вам необходимо перейти на сайт, где вы приобрели доменное имя. Интерфейс и, возможно, терминология будут отличаться в зависимости от используемого вами регистратора доменных имен.
В настройках вашего домена найдите параметр, который позволит вам указать серверы имен, которые вы хотите использовать. Поскольку наши серверы имен являютсяwithin нашим доменом, это особый случай.
Вместо того, чтобы регистратор просто делегировал полномочия для зоны с помощью записей NS, ему нужно будет создатьglue record. Связующая запись - это запись A, в которой указываются IP-адреса для серверов имен после того, как она указывает серверы имен, которым она делегирует полномочия.
Обычно делегирование перечисляет только серверы имен, которые будут обрабатывать полномочия домена, но когда серверы имен находятся в самом домене, запись A необходима для серверов имен в родительской зоне. Если этого не произойдет, преобразователи DNS будут зациклены, потому что они никогда не смогут найти IP-адрес серверов имен домена, чтобы следовать пути делегирования.
Итак, вам нужно найти раздел панели управления вашего регистратора домена, который позволяет вам указать серверам именand их IP-адреса.
В качестве демонстрации, регистраторNamecheap имеет два разных раздела сервера имен.
Существует раздел «Регистрация сервера имен», который позволяет вам указать IP-адреса серверов имен в вашем домене:
Внутри вы сможете ввести IP-адреса серверов имен, которые существуют в домене:
Это создаст запись A, которая послужит связующими записями, которые вам нужны в файле родительской зоны.
После того, как вы это сделаете, вы сможете изменить активные серверы имен на серверы вашего домена. В NameCheap это делается с помощью пункта меню «Настройка сервера доменных имен»:
Здесь вы можете указать использовать серверы имен, добавленные вами в качестве официальных серверов для вашего сайта:
Для распространения изменений может потребоваться некоторое время, но вы должны увидеть, что данные с ваших серверов имен будут использоваться в течение следующих 24-48 часов для большинства регистраторов.
Заключение
Теперь у вас должно быть два авторитетных DNS-сервера, настроенных для сервера ваших доменов. Их можно использовать для хранения информации о зоне для дополнительных доменов по мере их приобретения.
Настройка и управление собственными DNS-серверами дает вам максимальный контроль над обработкой записей DNS. Вы можете вносить изменения и быть уверенными, что все соответствующие части данных DNS обновлены в источнике. В то время как другие решения DNS могут упростить этот процесс, важно знать, что у вас есть варианты, и понимать, что происходит в более комплексных решениях.