В прошлом уроке мы подняли named и заставили его отвечать. Теперь задача инженера - наполнить сервер собственными данными: описать домен в виде зонного файла, корректно сопровождать его и не сломать резолвинг при каждом редактировании. В этом уроке разбираем формат зонного файла построчно, основные типы записей (SOA, NS, A, AAAA, MX, CNAME, PTR, TXT, SRV), прямые и обратные зоны, дисциплину serial и TTL, а также проверку и безопасную перезагрузку зоны.
Как это работает
Зона - это часть пространства имён DNS, за которую отвечает конкретный авторитетный сервер. Физически зона живёт в текстовом зонном файле в формате RFC 1035. named читает этот файл при старте или перезагрузке и держит записи в памяти, отвечая на запросы из неё.
Каждая строка зонного файла - это ресурсная запись (RR). Полный вид: имя, TTL, класс (почти всегда IN), тип, данные. Если имя не оканчивается точкой, named дописывает к нему имя зоны (origin) - это источник большинства ошибок новичков. Пустое имя в начале строки означает повтор предыдущего имени.
Сердце зоны - запись SOA (Start of Authority). Она задаёт основной NS, почту администратора (точка вместо @), и пять чисел: serial, refresh, retry, expire, minimum. Serial - версия зоны: подчинённые серверы (slave) сравнивают свой serial с мастеровым и тянут зону через AXFR/IXFR только если число выросло. Если забыть увеличить serial после правки - slave останется со старыми данными, и это классический баг в продакшене.
TTL - сколько секунд резолверы по всему миру держат ответ в кэше. Большой TTL разгружает сервер, но замедляет распространение изменений. Перед миграцией адреса TTL заранее снижают (например до 300), а после стабилизации возвращают.
Прямая зона переводит имя в адрес (A, AAAA). Обратная зона делает наоборот - по IP возвращает имя через запись PTR, и живёт в специальном псевдодомене in-addr.arpa (IPv4) или ip6.arpa (IPv6). Обратная зона нужна для почты, логов и SSH-проверок, и она отдельная от прямой - синхронность между ними держит только администратор.
Команды и примеры
Прямая зона example.lab. Обратите внимание на $ORIGIN, $TTL и точки в конце FQDN.
Код: Выделить всё
$TTL 3600
$ORIGIN example.lab.
@ IN SOA ns1.example.lab. admin.example.lab. (
2026061401 ; serial YYYYMMDDnn
3600 ; refresh
900 ; retry
1209600 ; expire
300 ) ; minimum (negative TTL)
@ IN NS ns1.example.lab.
@ IN NS ns2.example.lab.
@ IN MX 10 mail.example.lab.
@ IN A 192.0.2.10
@ IN AAAA 2001:db8::10
ns1 IN A 192.0.2.1
ns2 IN A 192.0.2.2
mail IN A 192.0.2.20
www IN CNAME @
_sip._tcp IN SRV 10 5 5060 sip.example.lab.
example.lab. IN TXT "v=spf1 mx -all"
Код: Выделить всё
$TTL 3600
$ORIGIN 2.0.192.in-addr.arpa.
@ IN SOA ns1.example.lab. admin.example.lab. (
2026061401 3600 900 1209600 300 )
@ IN NS ns1.example.lab.
1 IN PTR ns1.example.lab.
10 IN PTR example.lab.
20 IN PTR mail.example.lab.
Debian 13 / Ubuntu 24.04 (пакет bind9, зоны в /var/lib/bind или /etc/bind, описания в named.conf.local):
Код: Выделить всё
zone "example.lab" {
type master;
file "/etc/bind/db.example.lab";
};
zone "2.0.192.in-addr.arpa" {
type master;
file "/etc/bind/db.192.0.2";
};
Код: Выделить всё
zone "example.lab" IN {
type master;
file "example.lab.zone";
};
Код: Выделить всё
# Debian
named-checkzone example.lab /etc/bind/db.example.lab
# RHEL
named-checkzone example.lab /var/named/example.lab.zone
# обратная зона
named-checkzone 2.0.192.in-addr.arpa /var/named/2.0.192.rev
Перезагрузка без рестарта демона делается через rndc:
Код: Выделить всё
rndc reload # перечитать всё
rndc reload example.lab # только одну зону
rndc retransfer example.lab # slave: принудительно перетянуть
rndc zonestatus example.lab # состояние и serial
Код: Выделить всё
dig @127.0.0.1 www.example.lab A +short
dig @127.0.0.1 example.lab MX
dig @127.0.0.1 -x 192.0.2.10 +short # обратный запрос PTR
dig @127.0.0.1 example.lab SOA +multiline
Код: Выделить всё
sub IN NS ns1.sub.example.lab.
ns1.sub IN A 192.0.2.53 ; glue
- Забыли точку в конце FQDN - named дописывает origin, и ns1.example.lab. превращается в ns1.example.lab.example.lab. Проверяйте named-checkzone, он это ловит.
- Не увеличили serial после правки - slave не обновляется, dig на мастере показывает новое, а на slave старое. Заведите дисциплину YYYYMMDDnn.
- CNAME на вершине зоны (apex) запрещён стандартом: нельзя сделать @ IN CNAME. На MX, NS и на сам apex CNAME тоже ставить нельзя.
- PTR указывает на CNAME или на несуществующее имя - почтовые серверы и логи будут ругаться. PTR ведёт только на каноническое A-имя.
- Поправили только прямую зону, забыли обратную - прямой и обратный резолвинг разъезжаются.
- rndc reload без named-checkzone: битый файл, named отвергает зону и продолжает отдавать старую копию (или ничего). Всегда проверяйте до reload.
- Слишком большой serial или формат не по возрастанию (откатили дату) - slave решит, что зона не новее, и не обновится.
- Создайте прямую зону lab.local с записями SOA, двумя NS, A для хоста web и MX на mail.lab.local.
- Создайте обратную зону для вашей подсети /24 с PTR на web и mail.
- Подключите обе зоны в named.conf.local (Debian) или named.conf (RHEL), укажите type master и пути к файлам.
- Прогоните named-checkconf и named-checkzone по обеим зонам, исправьте ошибки до состояния OK.
- Выполните rndc reload и проверьте dig @127.0.0.1 web.lab.local A и dig -x по IP веба.
- Измените A-запись web, увеличьте serial, перезагрузите зону и убедитесь через rndc zonestatus, что serial вырос.
- Добавьте делегирование поддомена dev.lab.local с NS и glue, проверьте named-checkzone.
- За что отвечает каждое из пяти чисел в SOA и какое из них слейв сравнивает при решении тянуть ли зону?
- Почему нельзя поставить CNAME на вершину зоны и на имя в MX?
- Как формируется имя обратной зоны для сети 10.20.30.0/24 и в каком порядке идут октеты?
- Что произойдёт, если отредактировать зону, но не тронуть serial, и как это проявится на slave?
- Зачем при делегировании поддомена иногда нужна glue-запись и когда она обязательна?
- Чем named-checkzone отличается от named-checkconf и почему запускать его надо до rndc reload?
