Модуль 06 — DNS и DHCP

Люди запоминают имена, сети работают с адресами. DNS (Domain Name System) — распределённый справочник, который переводит имя nevabit.ru в адрес 188.120.235.218 и обратно, а заодно хранит, куда доставлять почту домена и кто подтверждает права на него.

Имена образуют дерево, которое читается справа налево: корень (.) → зона верхнего уровня (ru) → домен (nevabit.ru) → поддомен (portal.nevabit.ru). За каждую зону отвечают свои авторитетные серверы: корневые знают серверы зоны ru, серверы ru — серверы nevabit.ru, а те — адреса имён в домене. Зоной .ru управляет Координационный центр доменов .RU/.РФ.

Ваш компьютер не обходит дерево сам. Он спрашивает рекурсивный сервер (резолвер) — обычно домашний роутер, сервер провайдера или публичный, например 77.88.8.8 Яндекса. Резолвер проходит дерево от корня, складывает ответы в кэш и возвращает итог.

компьютер ──1──▶ резолвер ──2──▶ корневой сервер:   «за ru отвечают серверы a.dns.ripn.net…»
                     │  ──3──▶ сервер зоны ru:      «за nevabit.ru отвечают ns1.firstvds.ru…»
                     │  ──4──▶ ns1.firstvds.ru:     «nevabit.ru — 188.120.235.218»
          ◀──5──    ответ из кэша следующим клиентам

Весь путь показывает dig +trace. Какой резолвер использует система — в /etc/resolv.conf:

$ cat /etc/resolv.conf
nameserver 192.168.116.1
$ dig @77.88.8.8 +short nevabit.ru     # спросить конкретный резолвер
188.120.235.218

До DNS система смотрит файл /etc/hosts: строка 192.168.116.50 test.local в нём перекрывает DNS для этой машины. Так подменяют имена на время тестов. Порядок источников задан в /etc/nsswitch.conf; проверка с учётом всех источников — getent hosts имя, а dig спрашивает только DNS.

dig из пакета dnsutils (в Debian 13 — bind9-dnsutils) — главный инструмент проверки DNS:

$ dig nevabit.ru

; <<>> DiG 9.20.23-1~deb13u1-Debian <<>> nevabit.ru
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17461
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;nevabit.ru.			IN	A

;; ANSWER SECTION:
nevabit.ru.		3268	IN	A	188.120.235.218

;; Query time: 0 msec
;; SERVER: 192.168.116.1#53(192.168.116.1) (UDP)

Для скриптов удобен краткий вывод +short, для чтения — +noall +answer.

$ dig +short ya.ru AAAA
2a02:6b8::2:242
$ dig +short yandex.ru MX
10 mx.yandex.ru.
$ dig +short nevabit.ru NS
ns1.firstvds.ru.
ns2.firstvds.ru.
$ dig +short www.gosuslugi.ru CNAME
www.gslb.gosuslugi.ru.
$ dig -x 77.88.8.8 +short                # обратный запрос
dns.yandex.ru.
$ dig nonexistent-domain-xyz.ru | grep status
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 4659

Точка в конце mx.yandex.ru. означает полное имя от корня. В файлах зон её забывают — и имя превращается в mx.yandex.ru.yandex.ru. Обратные записи (PTR) задаёт владелец блока адресов, то есть провайдер или хостинг, — их проверяют почтовые серверы при приёме писем.

Резолвер хранит ответ столько секунд, сколько указано в TTL записи, и в это время не спрашивает авторитетный сервер. Видно, как значение убывает:

$ dig +noall +answer ya.ru
ya.ru.			600	IN	A	77.88.55.242
ya.ru.			600	IN	A	77.88.44.242
ya.ru.			600	IN	A	5.255.255.242
$ sleep 2; dig +noall +answer ya.ru
ya.ru.			598	IN	A	77.88.44.242
ya.ru.			598	IN	A	5.255.255.242
ya.ru.			598	IN	A	77.88.55.242

У ya.ru три адреса, и порядок меняется от запроса к запросу — так нагрузка распределяется между серверами. Следствие кэширования для администратора: изменение записи вступает в силу не сразу, а по мере истечения TTL в кэшах по всему миру. Перед переездом сайта TTL заранее уменьшают (например, до 300), а после — возвращают.

Компьютеру нужно знать адрес, маску, шлюз и DNS-сервер. Вписывать их вручную на сотне машин долго и чревато ошибками; DHCP выдаёт их автоматически. Обмен идёт по UDP (порты 67 и 68) из четырёх сообщений:

клиент                                   сервер DHCP
  │── DISCOVER (широковещательно) ──────────▶│   «есть кто-нибудь?»
  │◀───────────────────────────── OFFER ─────│   «могу дать 192.168.116.34»
  │── REQUEST ──────────────────────────────▶│   «беру 192.168.116.34»
  │◀─────────────────────────────── ACK ─────│   «твой на 2 часа, шлюз .1, DNS .1»

Адрес выдаётся в аренду. Клиент продлевает её на середине срока; выключенный надолго компьютер может получить другой адрес. Что получила машина:

$ sudo dhcpcd -U ens18 | grep -E '^(ip_address|subnet_mask|routers|domain_name_servers|dhcp_lease_time)'
ip_address=192.168.116.34
subnet_mask=255.255.255.0
routers=192.168.116.1
domain_name_servers=192.168.116.1
dhcp_lease_time=7200

Клиент DHCP в Debian зависит от установки: dhcpcd, dhclient или NetworkManager — команда просмотра аренды у каждого своя, а ip -br addr и ip route работают везде.

Серверам и сетевому оборудованию адреса задают статически или резервированием: их адрес должен быть известен и неизменен. Адрес 169.254.x.x на интерфейсе означает, что DHCP-сервер не ответил.