How to use Bind9 at the home on the Debian/Linux

Дата и время публикации: 2020-05-11 21:30:00
Дата и время модификации: 2020-11-14 11:30:00

Проблема и решение

1. Cуть проблемы

Состоит в том, что во время работы на удаленке по TLS/IPSEC все интернет-запросы по разрешению имен идут через корпоративный сервер, как показано на рисунке 1.1

Рисунок 1.1

На котором показано два маршрута прохождения запроса.

Примечание. Запросы бывают трех типов:

Рекурсивные
Итеративные или нерекурсивные
Инверсные

Рекурсивным запросом является такой запрос, который переадресуется сервером далее, например к корневому серверу имен, если не может дать ответ по своим записям или таблицах кэширования искомая комбинация разрешения доменного имени к адресу IP не были обнаружены. В большинстве случаев так и происходит, когда рекурсивный сервер сначала обращается к КЭШу и если не может дать ответ, обращается к корневому серверу, который обслуживает только итеративные запросы. Для получения корневых серверов предпочитаемого публичного сервера имен следует воспользоваться утилитой nslookup(1):

     user@home:~$ nslookup 
     lserver 8.8.8.8
     Default server: 8.8.8.8
     Address: 8.8.8.8#53
     > set type=ns
     > .
     Server:	8.8.8.8
     Address:	8.8.8.8#53

     Non-authoritative answer:
     .	nameserver = c.root-servers.net.
     .	nameserver = i.root-servers.net.
     .	nameserver = e.root-servers.net.
     .	nameserver = b.root-servers.net.
     .	nameserver = d.root-servers.net.
     .	nameserver = m.root-servers.net.
     .	nameserver = g.root-servers.net.
     .	nameserver = a.root-servers.net.
     .	nameserver = h.root-servers.net.
     .	nameserver = f.root-servers.net.
     .	nameserver = l.root-servers.net.
     .	nameserver = j.root-servers.net.
     .	nameserver = k.root-servers.net.

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

  
        user@home:~$ nslookup 
        > set type=PTR
        > 213.204.180.213
        ...
        Authoritative answers can be found from:
       204.180.213.in-addr.arpa	nameserver = ns3.yandex.ru.
       204.180.213.in-addr.arpa	nameserver = ns4.yandex.ru.

Синие кружки (длинный маршрут)

прохождения запросов происходит: от домашнего компьютера, через роутер, глобальной сетевой среды Интернета, корпоративного DNS и уже потом к публичному DNS (или DNS провайдера), а затем обратно передается ответ тем же маршрутом. Плюс некоторые задержки в обмене могут наблюдаться с использованием протокола TLS/IPSEC.

Красные кружки (короткий)

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

Так же выяснилась определенная особенность использования преобразователя имен или резолвера DNS совместно с TLS/IPSEC, настраиваемый с помощью dhcpclient(1). Последний необходимо каждый раз вызвать при поднятии, закрытии или разрыва соединения с корпоративной сетью, c приведенной конфигурацией в файле /etc/dhcp/dhclient.conf, в дампе 1.1

Дамп 1.1

option rfc3442-classless-static-routes code 121 = array of unsigned integer 8;

supersede domain-search "company.com";
prepend domain-name-servers 192.168.22.1;

send host-name = gethostname();
request subnet-mask, broadcast-address, time-offset, routers,
        domain-name, domain-name-servers, domain-search, host-name,
        dhcp6.name-servers, dhcp6.domain-search, dhcp6.fqdn, dhcp6.sntp-servers,
        netbios-name-servers, netbios-scope, interface-mtu,
        rfc3442-classless-static-routes, ntp-servers;

После выполнения команды dhcpclient(1) файл конфигурации DNS-резольвера /etc/resolv.conf будет содержать первичный и вторичный сервера разрешения имен, как показано в дампе 1.2 .

Дамп 1.2

user@home:~$ cat /etc/resolv.conf 
nameserver 172.24.122.1
nameserver 192.168.22.1

Вся эта схема разрешения имен DNS прекрасно работает до внезапной потери связи с корпоративным DNS, например из-за обрушения туннеля TLS/IPSEC или затыках с местным WiFi на стороне клиента, можно получить ошибку «ERR_NAME_NOT_RESOLVED» при открытии (обновлении) страницы в браузере WEB.

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

2. Решение проблемы

2.1 Заключается в определении внутренней (локальной) зоны верхнего уровня domain.tld. на узле сети с IP: 192.168.22.96, который должен быть закреплен за домашнем компьютером на роуторе с IP: 192.168.22.1, выступающего зачастую в качестве точки доступа к сети Интернет и на которой крутится комбинированный сервер разрешения имен, который включает в себе несколько типов одновременно, и служба DHCP выделяющая динамически реквизиты сети подключаемому клиенту.

Примечание. Caching DNS Server Кэшируемый сервер DNS обрабатывает рекурсивные запросы от клиентов. Почти каждый сервер DNS, что оперирует cо вспомогательной системной программой разрешения имен (stub resover), будет непременно контактировать с сервером DNS. Кэшируемые серверы имеют преимущество с рекурсивными запросами от клиентов. В то время как авторитетные серверы могут быть идеальны в получении специфичной информации от зоны, кэшируемые серверы весьма полезны с точки зрения клиента. Они делают систему DNS более доступной менее интелектуальным клиентским сервисам. Чтобы избежать проблем с необходимости высокой производительности из-за многократных запросов каждый раз к серверам DNS, кэшируемый сервер он кэширует результат принятого рекурсивного запроса. Это позволяет ему осуществлять доступ к обширной базе информации DNS, позволяет обработать очень быстро оставшиеся запросы. Forwarding DNS Server Сервер переадресации запросов DNS (Forwarding DNS Server), который практически идентичен кэшируемому серверу (Chached DNS Server), но реализация и рабочая нагрузка совсем иная. Такой сервер предлагает теже самые преимущества поддержки кэша для снижения результативного времени клиента. Однако, он фактически не производит рекурсивных запросов к самому себе, а пробрасывает все запросы к внешним серверами разрешения имен (outside resolving server) и кэширует результаты для использования в более поздних запросах. Это позволяет серверу отвечать из своего КЭШа, не требуя от него проделывать всю работу рекурсивными очередями. Это позволяет серверу производить только отдельные запросы ( перенаправляемый запрос клиента), вместо того чтобы проходить всю рекурсивную процедуру. Это будет преимуществом в сетевых окружених, особенно там, где за каждый переданный/принятый лишний байт взимается плата, где ваш кэширующий сервер может постоянно нуждаться в обновлении, или есть желание перенаправлять локальные запросы к одному серверу, а внешние запросы к другому серверу. Internal DNS server Внутренний сервер является авторитетным сервером DNS по отношению ко всем узлам объявленной локально зоны. Поэтому для обращения к внешнему серверу необходимо использовать комбинированный подход с использованием кэшируемого сервера, который может еще принимать рекурсивные запросы к самому себе. В тоже время внутренний авторитетный сервер DNS имеет следующие ограничения:

разрешение имен DNS производится только главным образом для собственных внутренних IP адресов;
внутренние имена DNS не могут использоваться для соединения с внешними ШЗ адресами;внутренние имена DNS не могут использоваться для соединения с внешними ШЗ адресами;
внутренние имена DNS не могут сконфигурированы псевдонимы адресам IP (Alias Ips);
В тоже время внутренние имена DNS можно использовать для присоединения, если они находятся с ними в одной тоже зоне.

2.2 Для начала устанавливаем требуемое программное обеспечение для запуска сервера имен named, как показано в дампе 2.1

Дамп 2.1

user@home:~$ sudo apt update && sudo apt install bind9 bind9utils bind9-doc

2.3 В файле /etc/default/bind9 устанавливаем дополнительно опцию поддержки IPv4, как показано в дампе 2.2

Дамп 2.2

user@home:~$ sudo nano /etc/default/named
. . .
OPTIONS="-u bind -4"

2.4 Производим перезапуск сервер named и проверяем статус запуска, как показано в дампе 2.3

Дамп 2.3

user@home:~$ sudo systemctl restart named
user@home:~$ sudo systemctl status named
● named.service - BIND Domain Name Server
     Loaded: loaded (/lib/systemd/system/named.service; enabled; vendor preset: enabled)
     Active: active (running) since Sun 2020-05-10 05:21:42 MSK; 7s ago
       Docs: man:named(8)
   Main PID: 15063 (named)
      Tasks: 26 (limit: 16644)
     Memory: 42.3M
     CGroup: /system.slice/named.service
             └─15063 /usr/sbin/named -f -u bind -4
. ..

2.5 Создаем сигнатуру TSIG для доступа к домену domain.tld, как показано в дампе 2.4

Дамп 2.4

user@home:~$ sudo tsig-keygen domain-tld.key > /etc/bind/domain-tld.key

Примечание. RNDC расшифровывается как удаленное управление сервера имен, которое реализуется в виде утилиты администрированной, запускаемой из интерфейса командной строки (command line interface, cli) и позволяющей локально и удаленно управлять сервером имен. По умолчанию, файл настройки RNDC определен в /etc/bind/rdnc.conf, как можно увидеть из дампа 2.4, синтаксис которого подобен файлу сервера имен /etc/named.conf . При этом, если указанный файл не существует, утилита будет использовать ключ из файла /etc/bind/rndc.key, который сгененрирован был автоматически во время установки службы сервера имен командой rndc-confgen -a, выполнение которого приведет к обновлению указанного файла:

      user@home:~$ sudo rndc-confgen -a
      wrote key file "/etc/bind/rndc.key"

Для предотвращения несанкционированного доступа неавторизованных пользователей сервер разрешения имен (он же — демон, он же — сервис) named использует метод аутентификации по общему секретному ключу (shared secret key authentication) для выделения полномочий доступа для отдельных узлов (клиентов). Это значит, что идентификационный ключ должен быть представлен в конфигурационном файле сервера имен /etc/named.conf и конфигурационном файле /etc/rndc.conf Общий секретный ключ может использоваться в качестве сигнатуры TSIG (Transaction SIGnatures), который является механизмом аутентификации или подтверждения подлинности DNS сервера, описанным в RFC 2845. TSIG используется в любых транзакциях DNS, как способ ограничить доступ к определенным функциям для авторизованных клиентов, когда доступ по протоколу IP может быть скомпроментирован или может быть переопределен, или в качестве обеспечения аутентичности сообщения, когда существует возможность нарушения целостности сервера, наподобие динамически обновляемых сообщений или передачи зон от мастера (master server) к ведомому серверу (slave server). Ключ TSIG может быть сгененрирован командой tsig-keygen, которая на выходе будет иметь директиву ключа для вставки в конфигурационный файл named.conf . Имя, алгоритм и размер ключа могут быть указаны при вызове команды в аргументах командной строки, которым по умолчанию установлены значения "tsig-key", HMAC-SHA256 и 256 бит, соответственно. На самом деле tsig-keygen, в версии сервера имен Bind 9.16 является символьной ссылкой на файл:

      root@home:~# ls -la /usr/sbin/tsig-keygen
      lrwxrwxrwx 1 root root 12 апр 23 12:45 /usr/sbin/tsig-keygen -> ddns-confgen

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

      root@home:~# sudo tsig-keygen -a hmac-md5 domain.tld
      key "domain.tld" {
        algorithm hmac-md5;
        secret "FF4uq3dXUTZh6+KKOa4ehg==";
      };

Начиная с версии Bind 9.16 вместо dnssec-keygen следует использовать tsig-keygen или ddns-confgen, как показано выше.

2.6 После чего, переходим к редактированию /etc/bind/named.conf, который изменять не требуется, т.к.

добавление зон осуществляется в файле /etc/bind/named.conf.local,
указание конфигурационных опций в файле /etc/bind/named.conf.options,
локальные зоны перечисляются в файле /etc/bind/named.conf.default-zones

Как следствие этого файл /etc/bind/named.conf имеет вид, как показано в дампе 2.6

Дамп 2.6

user@ns:~$ sudo cat /etc/bind/named.conf
// This is the primary configuration file for the BIND DNS server named.
//
// Please read /usr/share/doc/bind9/README.Debian.gz for information on the 
// structure of BIND configuration files in Debian, *BEFORE* you customize 
// this configuration file.
//
// If you are just adding zones, please do that in /etc/bind/named.conf.local

include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";
...

2.7 Настройка локальных зон прямого и обратного разрешения имен производится в /etc/bind/named.conf.local, как показано в дампе 2.7

Дамп 2.7

user@home:~$ sudo nano /etc/bind/named.conf.local 
// Domain Management gitlab.tld
// ------------------------------
//  - The server is defined as the master on the domain.
//  - Entries in the domain can be added dynamically
//    with the key  domain.tld
zone "domain.tld" {
        type master;
        file "/etc/bind/db.domain.tld";
        allow-update { key domain-tld.key; };
};

zone "22.168.192.in-addr.arpa" {
        type master;
        file "/etc/bind/db.22.168.192";
        allow-update { key domain-tld.key; };
};

При этом защищаемся от возможности несанкционированного обновления с указанием ранее созданного общего ключа domain-tld.key путем указания опции allow-update, как было показано в дампе 2.7

2.8 Правим файл /etc/bind/named.options, как показано в листинге 2.8

Дамп 2.8

user@home:~$ sudo nano /etc/bind/named.conf.options 
...
 2 acl "trusted" {   
 3        192.168.22.96; # trust recursive queries from themselves ONLY
 4 };
...
 6 options {
 7      directory "/var/cache/bind";
 8 
 9       recursion yes;                # enables resursive queries
10        allow-recursion { trusted; }; # allows recursive queries from "trusted" clients
11        listen-on { 192.168.22.96; }; # ns private IP address - listen on private network only
12        allow-transfer { none; };     # disable zone transfers by default
...
27       forwarders {
28            192.168.22.1;    # a private cached nameserver on home router 
29            172.24.122.1;    # a corporative nameserver on company side
30            213.180.204.213  # a public internet nameserver
31        };
...
39    listen-on-v6 { none; };
...
40 };
...

В котором, как было показано в листинге 2.8, с использованием списка контроля доступа ACL (acl "trusted", строки 2-4, и опции allow-recursion, строка 10), разрешаем принимать рекурсивные запроcы (опциями recursion строка 9) только от самих себя с IP, который будет прослушивать настраиваемый сервер имен (опция listen-on, строка 11).

В опции forwaders, строки 27-31, указывается к каким внешним серверам DNS (серверам разрешения имен) будут перенаправляться запросы. В данном случае, будут перенаправляться к внутреннему серверу с IP 192.168.22.1, к корпоративному серверу с IP 172.24.122.1 и публичному серверу Интернета с IP 213.180.204.213, если настраиваемый сервер имен не найдет их у себя в таблицах кэширования, которые хранит в файле /var/cache/bind.

2.9 Производим проверку всех файлов конфигурации начинающиеся /etc/bind/named.conf.*, как показано в дампе 2.9

Дамп 2.9

user@home:~$ sudo named-checkconf
[sudo] пароль для user: 
/etc/bind/named.conf.options:31: missing ';' before '}'

Как показана в дампе 2.9, ошибка выявлена из-за отсутствия точки с запятой при указании адреса IP для публичного сервера Интернета в строке 30

2.10 Настройка зон "domain.tld" и инверсного "22.168.192.in-addr.arpa" разрешения имен производится согласно принятого для них формата в ранее объявленных указанных им файлах /etc/bind/db.domain.tld и /etc/bind/db.22.168.192 соответственно.

Так пример объявление зоны "domain.tld" в файле /etc/bind/db.domain.tld показан в листинге 2.10

Листинг 2.10

 1 ;
 2 ; BIND reverse data file for broadcast zone
 3 ;
 4 $TTL 86400
 5 @	IN	SOA	ns.domain.tld. root.localhost. (
 6			      1		; Serial
 7			   3600		; Refresh [1 hour]
 8			   7200		; Retry   [2 hour] 
 9			  86400		; Expire  [1 day ]
10			 604800 )	; Negative Cache TTL [1 week]
11 ;domain bindings
12 @	IN	NS	ns.domain.tld.
13 @	IN	MX	96 pop.domain.tld.
14 @	IN	MX	96 smtp.domain.tld.
15 ;
16 ;nodes of domain domain.tld
17 ns                        IN     A      192.168.22.96
18 domain.tld.               IN     A      192.168.22.96
19 router.domain.tld.        IN     A      192.168.22.1
20 pop.domain.tld.           IN     A     192.168.22.96
21 smtp.domain.tld.          IN     A     192.168.22.96

Так пример объявление инверсной или обратной зоны "22.168.192.in-addr.arpa" в файле /etc/bind/db.domain.tld показан в листинге 2.11

Листинг 2.11

 1 ;
 2 ; BIND reverse data file for broadcast zone
 3 ;
 4 $TTL 86400
 5 @	IN	SOA	ns.domain.tld. root.localhost. (
 6 			      2		; Serial
 7 			   3600		; Refresh [1 hour]
 8 			   7200		; Retry   [2 hour] 
 9 			  86400		; Expire  [1 day ]
10			 604800 )	; Negative Cache TTL [1 week]
11 ;domain bindings
12 @	IN	NS	ns.domain.tld.
13 ;
14 ;nodes of domain domain.tld
15 96                   IN     PTR      ns.domain.tld.
16 1                    IN     PTR      router.domain.tld.

2.12 Как показано в листинге 2.10 и 2.11, формат записи прямой и инверсной зоны разрешения имени к IP адресу и обратно состоят из из деректив и записей ресурсов, в данном случае содержащие их файлы /etc/bind/db.domain.tld и /etc/bind/db.22.168.192.

Директивы начинаются с символа "$" и относятся к трем типам директив, которые можно объявить:

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

Как показано в строке 4 листинга 2.10 и 2.11, директива $TTL должна быть указана в первой строке файла с записями зоны DNS и до указания записи SOA, которая была объявлена в строках 5-10 тех же листингов.

В строке 5 символ @ подразумевает, что данная запись сделана для домена gitlab-tld. Далее указывается первичный DNS ns.domain.tld., а за ним следом почтовый адрес хост-мастера root.localhost. куда будут отправляться сообщения об ошибках.

В той же строке 5,

если адрес имеет точки, то они должны быть экранированы. Например, mailto: user.home@domain.tld => user\.home.domain.tld
все имена узлов должны заканчиваться символом точки (.), тем самым указывается точное имя узла, т.к. все, что идет без точки идет с привязкой от корня зоны. Так узел ns будет связан с ns.domain.tld.

В скобках указывается следующие значения:

Serial

Серийный номер, 32-разрядное значение присваиваемое для записи SOA и должно иметь значение между 1 и 42949667295

Refresh

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

Retry

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

Expire

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

Negatinve Cache TTL

Минимальное время жизни зоны, которое используется для указания хранения записи SOA в кэше других серверов DNS.

2.13 Формат записи ресурсов для прямого преобразования имен к адресу IPv4 используются записи типа А и NS в файле /etc/bind/db.domain.tld, как показано в строках 11-21 листинга 2.10 указывается:

в строке 12 — сервер DNS;
в строке 17 — соответствующая ему запись типа А, на узел в сети домена, на котором фактически развернут наш сервер DNS, реализуемый сервером named, который, в свою очередь, является ядром службы BIND9;
в строке 18 — запись типа А для имени узла domain.tld., c совпадающей с именем домена и на котором может крутится локальный WEB-сервер;
в строке 19 — запись типа А для имени узла router.domain.tld., под которым понимается точка доступа или роутер, обеспечивающие доступ ко Всемирной сети Интернет;
в строке 13 — запись типа MX сервиса почтового сервера по приему (выдачи) почтовых отправлений клиенту, в роли которого выступает почтовый агент;
в строке 20 — соответствующая ему запись типа А, на котором для узела в сети домена, на котором развернут сервер POP, реализующий передачу клиенту принятых, например почтовым сервером Postfix, почтовых отправлений по протоколу POP3;
в строке 14 — запись типа MX сервиса почтового сервера для передачи клиентом почтовых электроных отправлений по протоколу SMTP;
в строке 21 — соответствующая ему запись типа А для узела в сети домена, на котором развернут почтовый сервер Postfix, реализующий прием и передачу адресатам почтовых отправления по протоколу SMTP;

Cоответственно, потом на работающем сервере получим следующий дамп, подверждающий работоспособность записей MX для обоих почтовых сервисов :

dig doamin.tld MX 

; <<>> DiG 9.16.8-Debian <<>> domain.tld MX
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12384
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 77ec28267c8accb8010000005fae4101f652ecbec522f50c (good)
;; QUESTION SECTION:
;domain.tld.			IN	MX

;; ANSWER SECTION:
domain.tld.		86400	IN	MX	96 pop.domain.tld.
domain.tld.		86400	IN	MX	96 smtp.domain.tld.

;; ADDITIONAL SECTION:
pop.domain.tld.	86400	IN	A	192.168.22.96
smtp.domain.tld.	86400	IN	A	192.168.22.96

;; Query time: 0 msec
;; SERVER: 192.168.22.96#53(192.168.22.96)
;; WHEN: Пт ноя 14 11:17:05 MSK 2020
;; MSG SIZE  rcvd: 142

2.14 Для обратного преобразования адресов IPv4 к имени узла используется формата записи ресурса типа PTR в файле /etc/bind/db.22.168.192, как показано в строках в листинге 2.11, в строках 15 и 16 которого прописаны адреса (последний октет адреса).

2.15 Таким образом, из листингов 2.10 и 2.11 видно, что файл /etc/bind/db.22.168.192 практически идентичен (за исключением отсутствия в нем последних строк 18 — 21 листинга 2.10) файлу /etc/bind/db.domain.tld, в котором указаны различающиеся по формату записи ресурсов типов А и PTR соответственно.

Листинг 2.11.1

Затем, производим проверку обоих зон, как показано в дампе 2.12

Дамп 2.12

user@home2:~$ sudo named-checkzone 22.168.192.in-addr.arpa  /etc/bind/db.22.168.192
zone 22.168.192.in-addr.arpa/IN: loaded serial 2
OK
… 
user@home2:~$ sudo named-checkzone domain.tld /etc/bind/db.domain.tld 
zone domain.tld/IN: loaded serial 1
OK

После чего, производим перезапуск сервера имен named, как это делали в дампе 2.3, а затем производим проверку с использованием утилиты nslookup(1), как показано в дампе 2.13.

Дамп 2.13

user@hom:~$ nslookup 
> server 192.168.22.96
Default server: 192.168.22.96
Address: 192.168.22.96#53

> router.domain.tld.
Server:192.168.22.96
Address:192.168.22.96#53

Name: 	router.domain.tld
Address: 192.168.22.1

> ns.domain.tld.
Server: 192.168.22.96
Address: 192.168.22.96#53

Name:	ns.domain.tld
Address: 192.168.22.96

После чего, вносим в конфигурацию утилиты dhcpclient(1) в файле /etc/dhcp/dhclient.conf, как показано в дампе 2.14

Дамп 2.14

option rfc3442-classless-static-routes code 121 = array of unsigned integer 8;

supersede domain-search "domain.tld";
prepend domain-name-servers 192.168.22.96;

send host-name = gethostname();
request subnet-mask, broadcast-address, time-offset, routers,
        domain-name, domain-name-servers, domain-search, host-name,
        dhcp6.name-servers, dhcp6.domain-search, dhcp6.fqdn, dhcp6.sntp-servers,
        netbios-name-servers, netbios-scope, interface-mtu,
        rfc3442-classless-static-routes, ntp-servers;

и после перезапуска dhcpclient(1), нам не страшен серый волк в виде обрыва соединения с корпоративной сетью по TLS/IPSEC, а маршрут запросов к публичному серверу Интернета будет более коротким, обозначенный красными кружками.

3. Библиография

3.1 Difference between iterative and recursive dns query

3.2 What is Inverse (Reverse) DNS Query

3.3 DNS Root Server. A DNS root server is the first stop in a DNS lookup.

3.4 What and how to use RNDC?

3.5 Understanding views in BIND 9, by example

3.6 BIND 9 Administrator Reference Manual.BIND 9.16.2^[pdf]

3.7 https://sort.veritas.com/public/documents/vie/7.1/aix/productguides/html/vcs_bundled_agents/ch03s09s06s06.htm