Вступление
Важная часть управления конфигурацией сервера и инфраструктурой включает в себя поддержание простого способа поиска сетевых интерфейсов и IP-адресов по имени путем настройки правильной системы доменных имен (DNS). Использование полных доменных имен (FQDN) вместо IP-адресов для указания сетевых адресов облегчает настройку служб и приложений и повышает удобство сопровождения файлов конфигурации. Настройка собственного DNS для вашей частной сети - отличный способ улучшить управление вашими серверами.
В этом руководстве мы рассмотрим, как настроить внутренний DNS-сервер, используя программное обеспечение сервера имен BIND (BIND9) в Ubuntu 18.04, которое может использоваться вашими серверами для разрешения частных имен хостов и частных IP-адресов. Это обеспечивает центральный способ управления внутренними именами хостов и частными IP-адресами, что необходимо, когда ваша среда расширяется до нескольких хостов.
Версию этого руководства для CentOS можно найтиhere.
Предпосылки
Для завершения этого урока вам понадобится следующая инфраструктура. Создайте каждый серверin the same datacenter сprivate networking enabled:
-
Новый сервер Ubuntu 18.04 в качестве первичного DNS-сервера,ns1
-
(Рекомендуется) Второй сервер Ubuntu 18.04 в качестве вторичного DNS-сервера,ns2
-
Дополнительные серверы в том же центре обработки данных, которые будут использовать ваши DNS-серверы
На каждом из этих серверов настройте административный доступ через пользователяsudo
и брандмауэр, следуя нашимUbuntu 18.04 initial server setup guide.
Если вы не знакомы с концепциями DNS, рекомендуется прочитать хотя бы первые три части нашегоIntroduction to Managing 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. Обратитесь к следующей таблице соответствующих деталей:
Host | Role | Частное полное доменное имя | Частный IP-адрес |
---|---|---|---|
ns1 |
Первичный DNS-сервер |
ns1.nyc3.example.com |
10.128.10.11 |
ns2 |
Вторичный DNS-сервер |
ns2.nyc3.example.com |
10.128.20.12 |
host1 |
Общий хост 1 |
host1.nyc3.example.com |
10.128.100.101 |
host2 |
Общий хост 2 |
host2.nyc3.example.com |
10.128.200.102 |
Note
[.note] # Ваши существующие настройки будут отличаться, но примеры имен и IP-адресов будут использоваться для демонстрации того, как настроить DNS-сервер для обеспечения работающего внутреннего DNS. Вы сможете легко адаптировать эту настройку к своей среде, заменив имена хостов и частные IP-адреса своими собственными. Нет необходимости использовать имя региона центра обработки данных в вашей схеме именования, но мы используем его здесь для обозначения того, что эти хосты принадлежат частной сети конкретного центра обработки данных. Если вы используете несколько центров обработки данных, вы можете настроить внутренний DNS в каждом соответствующем центре обработки данных.
#
К концу этого руководства у нас будет первичный DNS-серверns1 и, возможно, вторичный DNS-серверns2, который будет служить резервным.
Давайте начнем с установки нашего основного DNS-сервера ns1.
Установка BIND на DNS-серверы
Note
[.note] # Текст, выделенный вred, важен! Он часто используется для обозначения чего-то, что должно быть заменено вашими собственными настройками или что оно должно быть изменено или добавлено в файл конфигурации. Например, если вы видите что-то вродеhost1.nyc3.example.com
, замените его на полное доменное имя вашего собственного сервера. Аналогичным образом, если вы видитеhost1_private_IP
, замените его частным IP-адресом вашего собственного сервера.
#
На обоих DNS-серверах,ns1 иns2, обновите кеш пакетовapt
, набрав:
sudo apt-get update
Теперь установите BIND:
sudo apt-get install bind9 bind9utils bind9-doc
Настройка привязки к режиму IPv4
Прежде чем продолжить, давайте установим BIND в режим IPv4, поскольку наша частная сеть использует исключительно IPv4. На обоих серверах отредактируйте файл настроек по умолчаниюbind9
, набрав:
sudo nano /etc/default/bind9
Добавьте «-4» в конец параметраOPTIONS
. Это должно выглядеть следующим образом:
/etc/default/bind9
. . .
OPTIONS="-u bind -4"
Сохраните и закройте файл, когда вы закончите.
Перезапустите BIND, чтобы изменения вступили в силу:
sudo systemctl restart bind9
Теперь, когда BIND установлен, давайте настроим основной DNS-сервер.
Настройка основного DNS-сервера
Конфигурация BIND состоит из нескольких файлов, которые включены в основной файл конфигурацииnamed.conf
. Эти имена файлов начинаются сnamed
, потому что это имя процесса, который запускает BIND (сокращение от «демон доменного имени»). Начнем с настройки файла опций.
Настройка файла опций
Наns1 откройте файлnamed.conf.options
для редактирования:
sudo nano /etc/bind/named.conf.options
Над существующим блокомoptions
создайте блок ACL (список управления доступом)new с именем «доверенный». Здесь мы определим список клиентов, которым мы будем разрешать рекурсивные DNS-запросы (т.е. ваши серверы, которые находятся в том же центре обработки данных, что иns1). Используя наш пример частных IP-адресов, мы добавимns1,ns2,host1 иhost2 в наш список доверенных клиентов:
/etc/bind/named.conf.options — 1 of 3
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
. В настоящее время начало блока выглядит следующим образом:
/etc/bind/named.conf.options — 2 of 3
. . .
};
options {
directory "/var/cache/bind";
. . .
}
Под директивойdirectory
добавьте выделенные строки конфигурации (и подставьте правильный IP-адресns1), чтобы он выглядел примерно так:
/etc/bind/named.conf.options — 3 of 3
. . .
};
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 zones обозначают конкретную область для управления и определения записей DNS. Поскольку все наши домены будут находиться в поддомене «nyc3.example.com», мы будем использовать его в качестве зоны пересылки. Поскольку каждый частный IP-адрес наших серверов находится в IP-пространстве10.128.0.0/16
, мы настроим обратную зону, чтобы мы могли определять обратный поиск в этом диапазоне.
Добавьте прямую зону со следующими строками, заменив имя зоны своим собственным иsecondary DNS server’s private IP address в директивеallow-transfer
:
/etc/bind/named.conf.local — 1 of 2
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
, добавьте обратную зону с помощью следующих строк (note that our reverse zone name starts with “128.10” which is the octet reversal of “10.128”):
/etc/bind/named.conf.local — 2 of 2
. . .
};
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
Изначально это будет выглядеть примерно так:
/etc/bind/zones/db.nyc3.example.com — original
$TTL 604800
@ IN SOA localhost. root.localhost. (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS localhost. ; delete this line
@ IN A 127.0.0.1 ; delete this line
@ IN AAAA ::1 ; delete this line
Сначала вы захотите отредактировать запись SOA. Замените первый localhost на полное доменное имяns1, затем замените root.localhost на admin.nyc3.example.com. Каждый раз, когда вы редактируете файл зоны, вам нужно увеличивать значениеserial перед перезапуском процессаnamed
. Мы будем увеличивать его до «3». Теперь это должно выглядеть примерно так:
/etc/bind/zones/db.nyc3.example.com — updated 1 of 3
@ IN SOA ns1.nyc3.example.com. admin.nyc3.example.com. (
3 ; Serial
. . .
Затем удалите три записи в конце файла (после записи SOA). Если вы не уверены, какие строки удалить, они помечены комментарием «удалить эту строку» выше.
В конце файла добавьте записи сервера имен со следующими строками (замените имена на свои). Обратите внимание, что во втором столбце указано, что это записи «NS»:
/etc/bind/zones/db.nyc3.example.com — updated 2 of 3
. . .
; 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 следующим образом:
/etc/bind/zones/db.nyc3.example.com — updated 3 of 3
. . .
; 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
.
Наш последний пример файла зоны пересылки выглядит следующим образом:
/etc/bind/zones/db.nyc3.example.com — updated
$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
Теперь давайте перейдем к файлам обратной зоны.
Создание файла (ов) обратной зоны
Файлы обратной зоны - это место, где мы определяем записи DNS PTR для обратного поиска DNS. То есть, когда DNS получает запрос по IP-адресу, например, «10.128.100.101», он ищет в файле (-ах) обратной зоны разрешение соответствующего полного доменного имени, в данном случае «host1.nyc3.example.com». ,
Наns1 для каждой обратной зоны, указанной в файлеnamed.conf.local
, создайте файл обратной зоны. Мы будем основывать наш файл (ы) обратной зоны на примере файла зоныdb.127
. Скопируйте его в нужное место с помощью следующих команд (подставляя имя файла назначения, чтобы оно соответствовало определению вашей обратной зоны):
sudo cp /etc/bind/db.127 /etc/bind/zones/db.10.128
Отредактируйте файл обратной зоны, который соответствует обратной зоне (ам), определенной вnamed.conf.local
:
sudo nano /etc/bind/zones/db.10.128
Изначально это будет выглядеть примерно так:
/etc/bind/zones/db.10.128 — original
$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. Это должно выглядеть примерно так:
/etc/bind/zones/db.10.128 — updated 1 of 3
@ IN SOA ns1.nyc3.example.com. admin.nyc3.example.com. (
3 ; Serial
. . .
Теперь удалите две записи в конце файла (после записи SOA). Если вы не уверены, какие строки удалить, они помечены комментарием «удалить эту строку» выше.
В конце файла добавьте записи сервера имен со следующими строками (замените имена на свои). Обратите внимание, что во втором столбце указано, что это записи «NS»:
/etc/bind/zones/db.10.128 — updated 2 of 3
. . .
; name servers - NS records
IN NS ns1.nyc3.example.com.
IN NS ns2.nyc3.example.com.
Затем добавьте записиPTR
для всех ваших серверов, IP-адреса которых находятся в подсети файла зоны, который вы редактируете. В нашем примере это включает все наши хосты, потому что все они находятся в подсети10.128.0.0/16
. Обратите внимание, что первый столбец состоит из последних двух октетов частных IP-адресов ваших серверов вreversed order. Не забудьте заменить имена и частные IP-адреса в соответствии с вашими серверами:
/etc/bind/zones/db.10.128 — updated 3 of 3
. . .
; 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
Сохраните и закройте файл обратной зоны (повторите этот раздел, если вам нужно добавить больше файлов обратной зоны).
Наш последний пример обратного файла зоны выглядит следующим образом:
/etc/bind/zones/db.10.128 — updated
$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-адресами всех ваших доверенных серверов:
/etc/bind/named.conf.options — updated 1 of 2 (secondary)
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
добавьте следующие строки:
/etc/bind/named.conf.options — updated 2 of 2 (secondary)
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-сервере. Обратите внимание, что это тип «подчиненный», файл не содержит пути, и есть директиваmasters
, которая должна быть установлена на частный IP-адрес основного DNS-сервера. Если вы определили несколько обратных зон на основном DNS-сервере, обязательно добавьте их все здесь:
/etc/bind/named.conf.local — updated (secondary)
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
Output3: eth1: 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:
[.note] #Note: Netplan используетYAML data serialization format для своих файлов конфигурации. Поскольку YAML использует отступы и пробелы для определения своей структуры данных, убедитесь, что ваше определение использует последовательные отступы, чтобы избежать ошибок.
#
/etc/netplan 00-private-nameservers.yaml
network:
version: 2
ethernets:
eth1: # Private network interface
nameservers:
addresses:
- 10.128.10.11 # Private IP for ns1
- 10.132.20.12 # Private IP for ns2
search: [ nyc3.example.com ] # DNS zone
Сохраните и закройте файл, когда вы закончите.
Затем сообщите Netplan, чтобы он попытался использовать новый файл конфигурации, используяnetplan try
. Если есть проблемы, которые вызывают потерю сети, Netplan автоматически откатит изменения по истечении времени ожидания:
sudo netplan try
OutputWarning: Stopping systemd-networkd.service, but it can still be activated by:
systemd-networkd.socket
Do you want to keep these settings?
Press ENTER before the timeout to accept the new configuration
Changes will revert in 120 seconds
Если обратный отсчет обновляется в нижней части, новая конфигурация по крайней мере достаточно функциональна, чтобы не разорвать ваше соединение SSH. НажмитеENTER, чтобы принять новую конфигурацию.
Теперь проверьте, что DNS-преобразователь системы определяет, была ли применена ваша конфигурация DNS:
sudo systemd-resolve --status
Прокрутите вниз, пока не увидите раздел для интерфейса вашей частной сети. Сначала вы должны увидеть частные IP-адреса для ваших DNS-серверов, а затем некоторые запасные значения. Ваш домен должен быть в «домене DNS»:
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 Linux вы можете редактировать файл/etc/network/interfaces
:
sudo nano /etc/network/interfaces
Внутри найдите строкуdns-nameservers
и добавьте свои собственные серверы имен перед текущим списком. Ниже этой строки добавьте параметрdns-search
, указывающий на базовый домен вашей инфраструктуры. В нашем случае это будет «nyc3.example.com»:
/etc/network/interfaces
. . .
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
Это должно перезагрузить вашу сеть, не прерывая ваше текущее соединение. Если это работает правильно, вы должны увидеть что-то вроде этого:
OutputRTNETLINK 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»:
/etc/sysconfig/network-scripts/ifcfg-eth0
. . .
DNS1=10.128.10.11
DNS2=10.128.20.12
DOMAIN='nyc3.example.com'
. . .
Сохраните и закройте файл, когда вы закончите.
Теперь перезапустите сетевой сервис, набрав:
sudo systemctl restart network
Команда может зависнуть на несколько секунд, но вскоре должна вернуться к приглашению.
Убедитесь, что ваши изменения были применены, набрав:
cat /etc/resolv.conf
Вы должны увидеть свои серверы имен и поисковый домен в списке:
/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 будут пытаться искать этот поддомен перед поиском хоста в другом месте. Вывод команды выше будет выглядеть следующим образом:
OutputServer: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: host1.nyc3.example.com
Address: 10.128.100.101
Далее мы можем проверить обратный поиск.
Обратный поиск
Чтобы проверить обратный поиск, запросите DNS-сервер с частным IP-адресомhost1:
nslookup 10.128.100.101
Вы должны увидеть вывод, который выглядит следующим образом:
Output11.10.128.10.in-addr.arpa name = host1.nyc3.example.com.
Authoritative answers can be found from:
Если все имена и IP-адреса соответствуют правильным значениям, это означает, что файлы зоны настроены правильно. Если вы получили неожиданные значения, обязательно просмотрите файлы зон на основном DNS-сервере (например, db.nyc3.example.com
иdb.10.128
).
Поздравляем! Ваши внутренние 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 и ваши файлы конфигурации используют частные полные доменные имена для определения сетевых подключений, этоcritical, что ваши DNS-серверы обслуживаются должным образом. Если они оба станут недоступны, ваши сервисы и приложения, которые на них полагаются, перестанут функционировать должным образом. Вот почему рекомендуется настроить DNS как минимум с одним вторичным сервером и поддерживать рабочие резервные копии всех из них.