DNS (BIND9)

С увеличением количества компьютеров в сети стало неудобно обращаться к ним по IP адресу, поэтому компьютерам начали присваивать имена. Первоначально для преобразования имени компьютера в IP адрес и обратно использовался файл /etc/hosts. Одним из условий правильного преобразования имен при помощи этого файла является наличие его на всех компьютерах в сети, причем с одинаковым содержанием.

Когда в сети несколько десятков компьютеров, синхронизация файла hosts между ними не вызывает особых проблем. Но если представить себе то количество машин, которое сейчас присутствует в Internet, то сразу становится понятно, что использование файла hosts вызовет очень большие затруднения. Представьте себе, что при подключении новой машины в сеть необходимо обновить этот файл на всех машинах сети. Кроме того, следует учитывать и размер этого файла, в котором на каждый компьютер отводиться одна строка. То есть, если в качестве источника данных для преобразования использовать /etc/hosts, то весь трафик в сети будет использоваться только для синхронизации этого файла.

В начале 80-х годов была создана система DNS — Domain Name System. Эта система представляет из себя распределенную базу данных, предназначенную для преобразования имен компьютеров в IP адреса и наоборот. DNS лишена недостатков файла hosts и позволяет довольно быстро осуществлять преобразование имен.

Пространство имен DNS

В DNS было введено понятие домена. Любая машина в сети находится в
определенном домене DNS.

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

Доменная структура DNS является иерархической. Иерархия имен начинается с корневого домена, обозначаемого символом точка — «.». В корневом домене находятся домены первого уровня. Они могут быть организованы по географическому принципу: ru, ua, fi и т.д. И по историческому принципу: домены, которые изначально использовались в США: com, net, mil и т.д. Дальше идут домены второго, третьего и т.д. уровней.

В DNS существует понятие полностью квалифицированного доменного имени — FQDN. Такое имя состоит из двух частей: имени компьютера и имени домена.

Например:

• w.rantivi.ru – состоит из имени машины w и имени домена —
  rantivi.ru
• nextcloud.rantivi.ru – имя машины nextcloud и имя домена rantivi.ru
  Как видно из примеров, первое имя — это имя машины. Оставшаяся часть — это
  домен.

Зона ответственности DNS сервера

Если предположить, что каждый DNS сервер в Интернет отвечает за все компьютеры в сети, то это не ничем не отличается от использования файла hosts. Поэтому DNS выполнена в виде распределенной базы данных. Каждый DNS сервер имеет свою зону ответственности. Он не отвечает за весь Интернет, а только за небольшую часть его.
Зона ответственности — это компьютеры в определенном домене, имена которых DNS сервер преобразует в IP адреса.

Например, DNS сервер, отвечающий за домен rantivi.ru предназначен для
преобразования имен компьютеров, входящих в этот домен. Если посмотреть на схему, то становиться понятно, что этот DNS сервер может преобразовать имена компьютеров: w.rantivi.ru, nextcloud.rantivi.ru, atc.rantivi.ru .

Принцип работы DNS

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

Работая на машине work1.rantivi.ru, в браузере набираем www.myblog.com и нажимаем Enter. Для того, чтобы браузер смог послать пакеты на соответствующий WEB сервер, ему необходимо получить IP адрес этого сервера. Он обратиться к клиенту DNS, находящемуся на том же компьютере, а клиент обратится к DNS серверу, на работу с которым он настроен.

Предположим, что DNS сервер, обслуживающий нашего клиента находится на
машине ns.rantivi.ru. Именно на этот сервер пошлет первый запрос наш клиент (шаг 1 на схеме). Поскольку машина www.myblog.com не входит в зону ответственности DNS сервера ns.rantivi.ru, этот сервер не может дать ответ на вопрос клиента и обратиться к DNS серверу, отвечающему за корневой домен (шаг 2 на схеме).
Корневой DNS сервер тоже не отвечает за машины домена www.myblog.com и не может дать окончательный ответ. Но этот сервер знает IP адрес и имя DNS сервера, отвечающего за домен com. . И он возвращает эти данные нашему серверу (шаг 3 на схеме).

Следующий запрос будет послан DNS серверу, отвечающему за домен com. (шаг 4 на схеме).

Но и он не может дать нам ответ на наш запрос, т.к. не является
ответственным за домен www.myblog.com. Но он знает IP адрес и имя DNS сервера, отвечающего за домен myblog.com и возвращает нам эти значения (шаг 5 на схеме).

Наш DNS сервер посылает запрос на DNS сервер, отвечающий за домен myblog.com (шаг 6 на схеме). Поскольку DNS сервер отвечает за домен myblog.com, он возвращает IP адрес
машины www.myblog.com (шаг 7 на схеме). Этот IP адрес возвращается нашему DNS серверу и он возвращает его клиенту (шаг 8).

Кэширующие DNS сервера

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

Для того, чтобы не возникало проблем с повторяющимися запросами, все DNS
сервера являются кэширующими. Наш сервер поместит информацию о машине www.myblog.com в свой локальный кэш и при следующем запросе выдаст информацию из локального кэша. Кроме того он поместит в кэш ответы DNS серверов, зон . , com. и myblog.com. .

Время хранения информации в кэш сервера зависит от настроек зоны. В большинстве случаев оно составляет около суток.

Рекурсивные и не рекурсивные DNS сервера

Рекурсивный DNS сервер при запросе ресурса , зная зону где находится ресурс сам обращается за информацией к серверу той зоны которая нужна.

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

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

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

Авторитетные и не авторитетные ответы

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

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

Чтобы такой ситуации не возникало, рекомендуется использовать дополнительные DNS сервера, поддерживающие ваш домен. Серверу зоны com. известны все DNS сервера, отвечающие за домен myblog.com. и, если сервер myblog.com не отвечает на запросы, сервер зоны com. обратиться к другим DNS серверам, ответственным за домен.

Сервер myblog.com называется главным (master) DNS сервером. Дополнительные сервера называются подчиненными (slave) DNS серверами. Все изменения в домене описываются только на master сервере, на slave серверах информация непосредственно не редактируется, они получают ее с master сервера.

Когда клиент DNS получает информацию с авторитетных серверов — master или slave, этот ответ называется авторитетным. Если информация получена из кэш, такой ответ называется не авторитетным.

Установка и настройка DNS Сервера (BIND9)

Обновляем листы пакетного менеджера apt

sudo apt update

sudo apt upgrade

Устанавливаем пакеты :

sudo apt install bind9

Основным конфигурационным файлом сервера BIND является файл
/etc/bind/named.conf. Кроме файла named.conf, используются дополнительные конфигурационные файлы:

• описания зон
• описания ключей
• файлы подсказок

В файле определяются основные
конфигурационные параметры DNS сервера и
зоны, которые он поддерживает.
Инструкции, применяемые в файле:

• include
• options
• acl
• zone
• view

и другие.

Файл состоит из инструкций. Каждая инструкция начинается с ключевого слова, определяющего ее тип и должна завершаться символом «;». Если параметры инструкции не помещаются на одну строку, их необходимо брать в фигурные скобки: { и }.

Список поддерживаемых инструкций приведен в ниже:

Инструкция options

При помощи инструкции options задаются глобальные параметры сервера
BIND.

options {
         параметр;
         параметр;
};

Ниже приведены некоторые параметры, определяемые в инструкции options:

Инструкция acl

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

acl имя {
элементы списка;
};

Определение acl должно происходить до того, как его имя будет использоваться в параметрах.
Существуют четыре заранее определенных списка:

• any – соответствует всем узлам
• localnets – соответствует всем узлам локальной сети
• localhost – соответствует своему компьютеру
• none – не соответствует ни одному узлу

Пример определения acl:
acl internal { 1.2.3.4; 2.3.4.5; 10.10.100/24; 192.168.0/24; };

Инструкция zone

Инструкция предназначена для описания зон ответственности DNS сервера. Для каждого поддерживаемого сервером DNS домена необходимо писать отдельную инструкцию zone.

Параметры, используемые в инструкции, зависят от типа зоны. Тип зоны
определяется при помощи параметра type.

Пример описания зоны:

zone «имя домена» IN {
                type тип_зоны;
                параметры зоны;
};

Ниже перечислены возможные типы зон.

Все вышеперечисленные типы зон будут рассмотрены ниже при описании поднятия поддержки домена и при рассмотрении различных случаев применения DNS сервера BIND.

Файл описания зоны

Специальные символы
Директивы
Записи:

• SOA
• NS
• MX
• A
• CNAME
• PTR

и другие

Основная информация о конкретном домене располагается в файле описания зоны. В нем описываются так называемые «записи о ресурсах», которые определяются в RFC: 882, 1035, 1183, 2065, 2181, 2308 и 2535.

В файле описания зоны можно использовать следующие специальные символы:
; — комментарий.
@ — Имя текущего домена. Берется либо из инструкции zone, либо
определяется в файле описания зоны директивой $ORIGIN.
() — Разбивка данных на несколько строк.

* — используется только в именах машин или доменов.

Директивы

В файле описания зоны можно использовать специальные директивы:

$TTL время — определяет время жизни записей в кэш DNS сервера для всех
записей зоны

$ORIGIN домен — определяет имя домена, подставляемое вместо символа @,
или подставляется в конце не полностью определенного имени компьютера
или домена

$INCLUDE файл— подключает внешние файлы

$GENERATE параметры — предназначена для создания наборов похожих
записей

Особенности написания FQDN имен в файлах описания зоны

В файлах описания зоны. только в файлах описания зоны! При указании полностью квалифицированного доменного имени машины (FQDN) или полного имени домена.
Требуется явно указывать имя корневого домена — «.».

Например, если необходимо указать FQDN имя машины nextcloud.rantivi.ru в файле описания зоны, его необходимо описывать следующим образом:

nextcloud.rantivi.ru. 

Обратите внимание на точку в конце имени — это явное указание корневого домена.

Если в конце имени точки нет, то DNS сервер автоматически подставит имя текущего домена (имя берется либо из инструкции zone, конфигурационного файла named.conf, либо определяется при помощи директивы $ORIGIN).

Записи о ресурсах

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

[имя_компьютера|имя_домена] [ttl] [класс] тип параметры

Первое – это имя машины или домена. Что именно писать в этом поле, зависит от типа записи. Если это поле оставить пустым, то его значение берется из предыдущей записи.

Если вы не указываете первое поле, то в начале строки обязательно должен
присутствовать либо символ пробела, либо табуляции.

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

Третье поле – класс сети. Можно использовать следующие классы сетей:

• IN – Internet (значение по умолчанию
• CH – ChaosNet. В настоящее время не используется.
• HS – Hesoid – информационная служба, являющаяся надстройкой пакета BIND. Используется крайне редко

Четвертое поле — тип — это зарезервированное слово. Основные типы записей приведены в таблице.

Тип	Описание
SOA	Определение параметров зоны DNS. Обязательная запись
NS	Определение DNS серверов, авторитетных для зоны. Делегирование полномочий поддоменам. Обязательная запись
А	Преобразование имени в IP адрес
AAAA	Преобразование имени в адрес IPv6
А6	Преобразование имени в адрес IPv6
PTR	Преобразование IP адреса в имя
MX	Применяется для указание почтового сервера, отвечающего за почту домена
KEY	Открытый ключ шифрования для DNS имени
CNAME	Дополнительное имя машины (псевдоним)
SRV	Определение служб в пределах домена

В любом файле описания зоны должны быть определены три обязательные записи:
SOA, NS и A для NS (или PTR в случае зоны обратного преобразования).

Запись SOA

Запись SOA (Start Of Autority) – определяет начало описания зоны. Это одна из
обязательных записей, которая должна присутствовать в файле описания зоны. Она должна быть самой первой в файле описания зоны. Описание зоны в файле продолжается до тех пор, пока не встретиться другая запись SOA.

Пример формата записи SOA:

Рассмотрим из каких полей состоит запись SOA.

Первый параметр – это имя домена. В этом параметре можно использовать
специальный символ @, вместо которого будет подставлено имя текущего домена.

Второй (необязательный) параметр TTL указан, поэтому время жизни этой
записи в кэш DNS сервера будет взято 1 час.

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

Дальше идет тип записи SOA. Все остальные параметры – это параметры присущие только записи типа SOA.

Сначала указывается имя master DNS сервера, ответственного за данную зону у меня это xubuntu.rantiviri.ru.

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

20241225 – серийный номер записи зоны.

При изменении файла описания зоны вы обязаны увеличить это число, потому что оно используется slave DNS серверами для определения необходимости зонной пересылки. Если серийный номер на slave сервере больше или равен серийному номеру на master DNS сервере, зонной пересылки не будет. Если он меньше, то будет происходить зонная пересылка на slave сервер. Максимальное количество знаков, которое можно применять в этом поле, равняется десяти.

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

В параметрах записи типа SOA интервал времени указывается в виде количества секунд. Но сервер BIND позволяет использовать сокращенный вариант определения времени.

Если slave сервер не может подключиться к master серверу, он переходит в другой режим работы, при котором интервал времени обращения к master серверу уменьшается. Параметр 10M определяет этот интервал.

Slave сервер не может до бесконечности пытаться подключиться к master серверу, поэтому следующий параметр 1d определяет время, по прошествии которого slave сервер перестает поддерживать эту зону.

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

Все параметры записи типа SOA являются обязательными.

Запись NS

Запись типа NS (Name Server) предназначена для описания всех DNS серверов,
авторитетных для данного домена. При помощи этой записи вы должны описать все master и slave сервера. Она так же применяется при делегировании прав на зону.

В файле описания зоны должна быть определена как минимум одна такая запись.

Формат записи NS:

[зона] [TTL] [IN] NS имя_сервера

Если предположить, что за зону rantiviri.ru отвечают DNS сервера:
xubuntu.rantiviri.ru. и ns.rantiviri.ru., в файл описания зоны необходимо добавить две записи:

@ IN NS xubuntu.rantiviri.ru.
@ IN NS ns.rantiviri.ru.

Кто из перечисленных серверов является master, а кто slave определяется при помощи первого параметра записи SOA.

Записи MX

Записи типа MX (Mail Exchanger) предназначены для указания почтовых серверов, отвечающих за прием почты для домена.

Формат записи MX:

[домен] [TTL] [IN] MX приоритет почтовый_сервер

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

Предположим, что почту для домена rantiviri.ru могут принимать два почтовых сервера: smpt.rantiviri.ru и mail.rantiviri.ru . Тогда в файле описания зоны
необходимо добавить две записи:

@ IN MX 5 mail.rantiviri.ru.
@ IN MX 10 smpt.rantiviri.ru.

Запись А

Запись типа А (address) предназначена для преобразования имени машины в IP адрес.
Формат записи:

[имя_машины] [TTL] [IN] A IP_адрес

Предположим, что в домене rantiviri.ru есть три машины:
mail.rantiviri.ru, my.rantiviri.ru и nextcloud.rantiviri.ru. Тогда в файле
описания зоны необходимо добавить три записи:

mail IN A 192.168.7.248
my IN A 192.168.7.20
nextcloud IN A 192.168.7.250

IP адреса машин могут находиться в разных сетях. Если машина имеет несколько сетевых интерфейсов, возникает желание написать две записи для одной машины. Но если это сделать, вас ждет сюрприз. Например, машина mail.rantiviri.ru имеет два
сетевых интерфейса со следующими IP адресами: 195.156.98.20 и 192.168.7.248.

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

mail IN A 1195.156.98.20
     IN A 192.168.7.248

Тогда при первом запросе на преобразование имени машины mail.rantiviri.ru будет выдан первый IP адрес. При втором — второй. При третьем — снова первый. При четвертом — опять второй и т.д. Поэтому рекомендуется в DNS сервере одной машине присваивать один IP адрес.

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

Запись CNAME

Запись типа CNAME (Canonical Name) — позволяет добавить несколько имен одной и той же машине. Формат записи CNAME:

дополнительное_имя [TTL] [IN] CNAME каноническое_имя

Одной машине можно присвоить несколько имен, в том числе и в разных доменах, которые преобразуются в один IP адрес. Обратное преобразование IP адреса возможно только в одно имя машины. Такое имя называется каноническим. При помощи записи типа А определяют только канонические имена. Все дополнительные имена необходимо определять только при помощи записи типа CNAME.

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

www IN CNAME server
ftp IN CNAME server

Важно запомнить, что параметр записи CNAME — это имя машины, а не ее IP адрес.

Запись PTR

Записи типа PTR (Pointer) предназначены для обратного преобразования — IP адреса в имя машины. Обычно эти записи применяются в зонах обратного преобразования.
Формат записи:

адрес [TTL] [IN] PTR имя

Пример, создание и настройки доменной зоны rantiviri.ru

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

В BIND9 основной файл конфигурации сервера named.conf , в котором указаны файлы из которых забирать настройки:

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

Здесь описываются инструкции options

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

Параметр forwarders { ip adres, ip adres,…..};

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

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

Параметр listen-on-v6 {interface;};

Этот параметр отвечает за то на каких интерфейсах слушать демону named IPv6 трафик.(по умолчанию стоит any, чтобы отключить none )

Второй файл на рассмотрение named.conf.local

Здесь описываются инструкции zone

Инструкция предназначена для описания зон ответственности DNS сервера. Для каждого поддерживаемого сервером DNS домена необходимо писать отдельную инструкцию zone.

Третий файл на рассмотрение named.conf.default-zones

Здесь также как и named.conf.local описываются инструкции zone

зоны широковещательные и локальные, и . .

При редактировании файла /etc/bind/named.conf.local в зоне rantiviri.ru мы указали файл где хранится описание зоны (ресурсы , сервера ….) это файл /etc/bind/rantiviri.ru.zone .

По окончанию внесения всех правок нужно проверить на синтаксические ошибки командами :

named-checkconf -z

Если есть ошибки , в выводе команды будет указано в какой зоне в каком файле и номер строки.

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

rndc reconfig

Если зона ранее была загружена и мы что то добавили ,для обновления:

rndc reload rantiviri.ru

Для правильной работы сервера рекомендуется установить ему статический IP адрес

Назначение статического IP-адреса

Чтобы настроить систему на использование статического назначения адресов, создайте netplanконфигурацию в файле /etc/netplan/FILE.yaml. В примере ниже предполагается, что вы настраиваете свой первый интерфейс Ethernet, идентифицированный как eth0. Измените значения addresses, routes, и nameserversв соответствии с требованиями вашей сети.

network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      addresses:
        - 10.10.10.2/24
      routes:
        - to: default
          via: 10.10.10.1
      nameservers:
          search: [mydomain, otherdomain]
          addresses: [10.10.10.1, 1.1.1.1]

Затем конфигурацию можно применить с помощью netplanкоманды.

sudo netplan apply

ПРИМЕЧАНИЕ.
netplan В Ubuntu Bionic 18.04 LTS не понимает to: defaultсинтаксис « » для указания маршрута по умолчанию и должен использовать старый gateway4: 10.10.10.1ключ вместо всего routes:блока.

Интерфейс loopback идентифицируется системой как loи имеет IP-адрес по умолчанию 127.0.0.1. Его можно просмотреть с помощью ipкоманды.

ip address show lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever

Разрешение имени

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

Конфигурация DNS-клиента

Традиционно файл /etc/resolv.confбыл статическим файлом конфигурации, который редко требовалось изменять, или он автоматически изменялся через DHCP-клиентские хуки. systemd-resolved обрабатывает конфигурацию сервера имен, и с ним следует взаимодействовать через systemd-resolved команду. Netplan настраивается systemd-resolved для генерации списка серверов имен и доменов для помещения в /etc/resolv.conf, который является символической ссылкой:

/etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

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

network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s25:
      addresses:
        - 192.168.0.100/24
      routes:
        - to: default
          via: 192.168.0.1
      nameservers:
          search: [mydomain, otherdomain]
          addresses: [1.1.1.1, 8.8.8.8, 4.4.4.4]

Опцию поиска можно также использовать с несколькими доменными именами, чтобы DNS-запросы добавлялись в том порядке, в котором они были введены. Например, в вашей сети может быть несколько поддоменов для поиска; родительский домен example.com, и два поддомена, sales.example.comи dev.example.com.

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

network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s25:
      addresses:
        - 192.168.0.100/24
      routes:
        - to: default
          via: 192.168.0.1
      nameservers:
          search: [example.com, sales.example.com, dev.example.com]
          addresses: [1.1.1.1, 8.8.8.8, 4.4.4.4]

Если вы попытаетесь выполнить команду ping на хост с именем server1, ваша система автоматически запросит DNS для получения его полного доменного имени (FQDN) в следующем порядке:

1. server1.example.com
2. server1.sales.example.com
3. server1.dev.example.com

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