Dns сервер linux debian

Сервер DNS (Domain Name System) нужен для преобразования имен компьютера в IP адреса. Когда компьютеров было мало, обращения к компьютерам было по IP адресам. Но затем стало ясно, что намного удобнее обращаться по имени к компьютеру или сайту, чем запоминать IP адрес. Несложно запомнить несколько IP адресов, но когда их становится все больше и больше, то возникает необходимость переводить IP адреса в удобные имена. Именно для этих целей и служит DNS сервер, который занимается переводом имен компьютера в IP адреса и наоборот, переводом IP адресов компьютера в имена. Установка и настройка серевера DNS не занимает много времени, но требует внимательности и понимания конфигурационных файлов и указанных в них параметров. Одной из реализацией в Linux DNS серверов является BIND. Текущая реализация это BIND9. Все настроечные файлы находятся в каталоге /etc/bind/. Основной файл конфигурации — named.conf. Установим и настроим сервер DNS BIND9 на основе операционной системы Debian.

Для начала откроем терминал. Все действия по установке и настройке DNS сервера производятся с правами root или с помощью sudo.

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

Для Debian 9 вместо jessie указываем stretch.

Сохраняем файл, далее выполняем следующие команды:

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

Устанавливаем пакет bind9 (dns сервер):

Директория, в которой находятся настроечные файлы dns сервера — /etc/bind/. Основным настроечным файлом является named.conf.options. Настраиваем файл named.conf.options (находится в каталоге /etc/bind):

Прописываем в файле named.conf.options:

allow-query < mynetwork; >; — список тех, кто имеет право запрашивать информацию, если хотите, чтобы принимать запросы ото всех, вместо mynetwork ставим any.

acl — ограничивает адреса, которые могут запрашивать зоны с сервера DNS.

forwarders < 8.8.8.8; >; — прописываем DNS сервера, у которого можно получить информацию, если информация о доменах неизвестна нашему серверу.

listen on < 192.168.91.10; 192.168.91.20; >; — прописываем DNS сервера, которые будут использованы для отображения IP адресов в имена и наоборот.

listen-on-v6 < none; >; — если IP 6 версии не используем.

auth-nxdomain no; — параметр для совместимости с RFC1035.

Далее редактируем файл named.conf.local:

В файле прописываем зону прямого и обратного просмотра для домена. Зона прямого просмотра — тип зоны, в котором в ответ на имя получают IP адрес. Соответственно ответственность зоны обратного просмотра состоит в том, чтобы получить по IP адресу имя компьютера:

91.168.192.in-addr.arpa — обратная зона просмотра, берётся из IP адреса DNS сервера (в данном случае 192.168.91.10);

db.sigro.ru — прямая зона просмотра, домен в данном случае называется sigro.ru.

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

Далее начинаем прописывать зону прямого просмотра. Чтобы произвести настройку быстрее и по шаблону, копируем фал db.local и изменяем уже вновь созданный файл настройки зоны прямого просмотра (имена для файлов зоны прямого и обратного просмотра можно придумать любые, но принято, чтобы они были читабельны):

; — после данного знака возможно делать комментарий

$TTL 604800 — time to live (время кэширования из вашей зоны)

$ORIGIN sigro.ru. — при использовании $ORIGIN к именам будет автоматически дописываться в данном случае sigro.ru. (не забываем в конце точку). Например, при считывании зоны прямого просмотра, вместо nic1 автоматически будет подставлено nic1.sigro.ru.

@ IN SOA nic1 admin — запись SOA (начало ответственности)

nic1 — имя первичного dns сервера

admin — почтовый адрес пользователя, отвечающего за эту зону

2017060100 — серийный номер зоны (десятизначное число)

604800 — период обновления

86400 — повтор каждые 86400 с

2419200 — время хранения информации

604800 — время хранения в кэше удаленных серверов негативных ответов

Прописываем зону обратного просмотра. Для этого создаём файл зоны обратного просмотра и производим изменения в вновь созданном файле:

Делаем так, чтобы сервер DNS работал с новой конфигурацией:

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

named-checkconf -z — пытается произвести действия, такие же как bind при загрузке зон.

nslookup sigro.ru — должен быть показан адрес проверяемого сервера (т.е. в данном случае Address: 192.168.91.10).

nslookup 192.168.91.10 — должен быть показано имя проверяемого сервера (т.е. в данном случае name = nic1.sigro.ru).

Если ошибок нет, то сервер DNS сконфигурирован правильно.

Что и как делать можно также посмотреть здесь:

Источник

BIND DNS на Debian 10.9

Статья описывает быструю настройку Master и Slave DNS серверов с использованием BIND в ОС Debian GNU/Linux 10.9.

На всех серверах сделаем следующее:

установим необходимые пакеты

если включён файрволл, необходимо разрешить использование DNS

переходим в каталог /etc/bind и откроем здесь файл named.conf

в самом конце впишем строчку:

теперь создадим файл /etc/bind/named.conf.zones

и при необходимости отдадим права пользователю root группы bind

в настройках сетевого интерфейса /etc/network/interfaces в параметре dns-nameservers поменяем IP-адреса на наши DNS-сервера:

также в файле /etc/resolv.conf закомментируем все строчки решёткой и добавим наши DNS-сервера:

192.168.1.47 и 192.168.1.48 — заданные для примера IP-адреса серверов ns1 (master) и ns2 (slave) соответственно

перезапускаем сетевой интерфейс

и проверяем его

после этого сгенерируем ключи

Переходим к настройкам на сервере ns1:

в файле /etc/bind/named.conf.options стираем строчку

и на её месте напишем:

в файле /etc/bind/named.conf.zones пропишем описание нашей зоны:

в файле /etc/bind/db.localserver34.ru зададим описание зоны, т.е. внесём основные записи:

перезапускаем службу bind9

и проверяем её состояние

ответ должен содержать:

Затем переходим к настройке сервера ns2:

в файле /etc/bind/named.conf.options стираем строчку

и на её месте напишем:

в файле /etc/bind/named.conf.zones пропишем описание нашей зоны:

теперь создадим каталог /etc/bind/slave и отдадим на него права пользователю bind группы bind

при этом здесь файл зоны создавать не нужно — он автоматически подтянется из мастера

перезапускаем службу bind9

и проверяем её состояние

ответ должен содержать:

Проверяем работу DNS-серверов с помощью утилиты dig:

на ns1 (Master DNS) запускаем

ответ должен быть таким:

на ns2 (Slave DNS) запускаем

ждём такого ответа:

Если ошибок нет, значит настройка прошла успешно.

Теперь IP-адреса этих серверов можно прописывать на клиентских машинах в сети.

Источник

DNS сервер BIND на Debian 9

Bind9 это пакет создающий DNS-сервер который определяет доменное имя по IP-адресу в локальной или глобальной сети. Bind9 может также работать и в режиме кеширующего DNS-сервера. BIND использует 53/TCP, UDP порт. Настоящая статья содержит описание установки и настройки.

1. Установка BIND 9

2. Настройка BIND 9

В этом примере используются глобальные IP-адреса [172.16.0.80/29], частные IP-адреса [10.0.0.0/24], имя домена [srv.local]. Однако при настройке конфигурации на своем сервере используйте свои собственные IP-адреса и доменное имя.

Для зон обратного разрешения, указывается адрес сети, как показано ниже:

10.0.0.0/24
Адрес сети — 10.0.0.0
Диапазон сети — 10.0.0.0 — 10.0.0.255
Как записать — 0.0.10.in-addr.arpa

172.16.0.80/29
Адрес сети — 172.16.0.80
Диапазон сети — 172.16.0.80 — 172.16.0.87
Как записать — 80.0.16.172.in-addr.arpa

3. Диапазоны ограничений, которые вы разрешаете при необходимости.

4. Создание файлов зон для разрешения IP-адреса из имени домена

4.1. Для внутренней зоны

4.2. Для внешней зоны

5. Создание файлов зон для разрешения
имени домена из IP-адреса

5.1. Для внутренней зоны

5.2. Для внешней зоны

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

Добавьте в resolv.conf свой собственный DNS для разрешения имен.

[ens3] отличается в каждом дистрибутиве, замените его на свой

6. Установка CNAME

Если вы хотите установить другое имя для своего хоста, укажите запись CNAME в файле зоны.

Источник

BIND как DNS-сервер для частной сети в Debian 9

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

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

Требования

Для работы вам понадобится следующая инфраструктура. Все серверы должны находиться в одном ЦОД с включенной поддержкой частной сети.

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

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

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

В мануале предполагается, что:

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

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

Хост	Роль	Частный FQDN	Внутренний IP-адрес
ns1	Первичный DNS-сервер	ns1.nyc3.example.com	10.128.10.11
ns2	Вторичный DNS-сервер	ns2.nyc3.example.com	10.128.20.12
host1	Клиент Host 1	host1.nyc3.example.com	10.128.100.101
host2	Клиент Host 2	host2.nyc3.example.com	10.128.200.102

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

В результате у вас будет первичный DNS-сервер ns1 и вторичный DNS-сервер ns2.

1: Установка BIND на DNS-серверы

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

На серверах ns1 и ns2 обновите индекс пакетов:

sudo apt update

Затем установите BIND:

sudo apt install bind9 bind9utils bind9-doc

Настройка режима IPv4

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

sudo nano /etc/default/bind9

Добавьте опцию -4 в конец параметра OPTIONS:

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

Чтобы обновить настройки, перезапустите BIND:

sudo systemctl restart bind9

2: Настройка первичного DNS-сервера

Конфигурация BIND состоит из нескольких файлов, которые включены в основной файл конфигурации named.conf. Имена этих файлов начинаются с named, потому что это имя процесса, который запускает BIND. Начнем с настройки файла options.

Файл options

На сервере ns1 откройте этот файл:

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

Над существующим блоком options создайте новый блок управления доступом ACL (access control list) под названием trusted. Здесь можно определить список клиентов, которые могут отправлять рекурсивные DNS-запросы (например, ваши серверы, находящиеся в том же ЦОД, что и ns1). Добавьте 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. В настоящее время начало блока выглядит следующим образом:

Под директивой 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-сервера.

Затем нужно настроить файл local, чтобы определить DNS-зоны.

Настройка файла local

На ns1 откройте файл named.conf.local:

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

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

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

zone «nyc3.example.com» <
type 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. В данном случае нужно добавить записи A для ns1, ns2, host1 и host2 следующим образом:

. . .
; name servers — A records
ns1. nyc3.example.com. IN A 10.128.10.11
ns2. nyc3.example.com. IN A 10.128.20.12
; 10.128.0.0/16 — A records
host1.nyc3.example.com. IN A 10.128.100.101
host2.nyc3.example.com. IN A 10.128.200.102

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

В результате файл зоны имеет такой вид:

$TTL 604800
@ IN SOA ns1. nyc3.example.com. admin .nyc3.example.com. (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
; name servers — NS records
IN NS ns1. nyc3.example.com.
IN NS ns2. nyc3.example.com.
; name servers — A records
ns1. nyc3.example.com. IN A 10.128.10.11
ns2. nyc3.example.com. IN A 10.128.20.12
; 10.128.0.0/16 — A records
host1.nyc3.example.com. IN A 10.128.100.101
host2.nyc3.example.com. IN A 10.128.200.102

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

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

Файлы зоны обратного просмотра определяют записи 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

Изначально файл будет выглядеть так:

$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 не содержат синтаксических ошибок, вы вернетесь в командную строку оболочки и не увидите сообщений об ошибках. Если команда обнаружит проблемы, просмотрите сообщение об ошибке и перечитайте раздел 2, а затем повторно запустите named-checkconf.

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

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

sudo named-checkzone nyc3.example.com /etc/bind/zones/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. Теперь создадим вторичный сервер.

3: Настройка вторичного DNS-сервера

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

На ns2 отредактируйте файл named.conf.options:

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

В начале файла добавьте ACL с внутренними IP-адресами доверенных серверов.

acl «trusted» <
10.128.10.11 ; # ns1
10.128.20.12 ; # ns2 — 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

Определите вторичные зоны, соответствующие зонам первичного 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
>;

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

Чтобы проверить файлы на наличие ошибок, введите:

Если ошибок нет, перезапустите BIND:

sudo systemctl restart bind9

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

sudo ufw allow Bind9

Теперь у вас есть первичный и вторичный DNS-сервер. Пора настроить клиентские серверы.

4: Настройка DNS-клиентов

Прежде чем все ваши серверы из ACL trusted смогут запрашивать 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
3: 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.

Затем создайте новый файл 00-private-nameservers.yaml в /etc/netplan:

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

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

Примечание: Netplan использует формат сериализации данных 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
Warning: Stopping systemd-networkd.service, but it can still be activated by:
systemd-networkd.socket
Do you want to keep these settings?
Press ENTER before the timeout to accept the new configuration
Changes will revert in 120 seconds

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

Теперь убедитесь, что системный DNS-резолвер применил новую конфигурацию:

sudo systemd-resolve —status

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

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

Клиенты Ubuntu 16.04 и Debian

На серверах Ubuntu 16.04 и Debian Linux вы можете отредактировать файл /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
. . .

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

Установите пакет resolvconf:

sudo apt update
sudo apt install resolvconf

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

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

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

RTNETLINK answers: No such process
Waiting for DAD. Done

Повторно проверьте, применены ли новые параметры:

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

# 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

Настройка клиента завершена.

Клиенты 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

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

Убедитесь, что ваши изменения были применены:

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

nameserver 10.128.10.11
nameserver 10.128.20.12
search nyc3.example.com

Настойка клиента завершена.

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

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

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

sudo yum install bind-utils

Чтобы установить утилиту на клиенты Debian, введите:

sudo apt install dnsutils

Начнем с прямого просмотра.

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

Чтобы выполнить прямой просмотр и извлечь IP-адрес хоста host1.nyc3.example.com, введите:

Запрос host1 расширяется до host1.nyc3.example.com, поскольку параметр search содержит ваш частный субдомен, а запросы DNS будут пытаться просмотреть его, прежде чем искать хост в другом месте. Вывод команды выглядят следующим образом:

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-сервер:

Команда должна вернуть такой вывод:

11.10.128.10.in-addr.arpa name = host1.nyc3.example.com.
Authoritative answers can be found from:

Если все имена и IP-адреса разрешены с правильным значением, это означает, что ваши файлы зон настроены правильно. Если вы получили другие значения, обязательно просмотрите файлы зон на первичном DNS-сервере (например, db.nyc3.example.com и db.10.128).

Теперь рассмотрим сохранение записей в зоне.

6: Поддержка DNS-записей

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

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

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

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

sudo systemctl reload bind9

Теперь ваш первичный сервер должен поддерживать новый хост.

Добавьте внутренний IP нового хоста в ACL trusted (named.conf.options).
Проверьте синтаксис:

sudo systemctl reload bind9

Теперь ваш вторичный сервер должен поддерживать новый хост.

Чтобы настроить новый хост для поддержки DNS:

Настройте поддержку в файле /etc/resolv.conf.
Протестируйте работу хоста с помощью nslookup.

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

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

Заключение

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

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

Источник

Dns сервер linux debian