Собственные NS добавляют проекту независимость и контроль над делегированием, а также решают маркетинговую задачу: на визитке и в панелях у клиента видны ваши бренд‑серверы, а не стороннего провайдера. Но к бренду прилагаются технические тонкости: glue‑записи в регистре, корректное делегирование, IPv6, DNSSEC и проверка на «lame delegation». Ниже — практический разбор для админов, девопсов и вебмастеров.
Термины и контекст
Чтобы говорить на одном языке, определимся с базовыми понятиями:
- NS‑запись — указывает, какие авторитетные серверы обслуживают зону домена.
- Родительская зона (parent) — зона более высокого уровня (например, .com или .ru), в которой хранится делегирование вашего домена.
- Glue‑запись — IP‑адрес (A/AAAA) для имени NS, которое находится внутри самого домена (in‑bailiwick), чтобы резолверы не попали в «курицу и яйцо» при начальном поиске.
- In‑bailiwick NS — NS вида ns1.example.com для домена example.com. Для них требуются glue.
- Out‑of‑bailiwick NS — NS вне домена, например ns1.dnsprovider.net; glue обычно не нужны, т.к. IP можно найти через обычный рекурсивный запрос.
- Vanity nameservers — «брендированные» NS внутри вашего домена, которые, по сути, указывают на инфраструктуру провайдера DNS (его IP‑адреса/Anycast), но видны как ваши.
Коротко: если NS‑имя находится внутри вашего домена — готовьте glue. Если снаружи — скорее всего, не нужно.
Когда вообще нужны собственные NS
- Бренд и белейбл: красивые ns1.brand.tld и ns2.brand.tld вместо чужих.
- Контроль над стеком: свой авторитетный DNS (BIND/Knot/NSD/PowerDNS), свои политики, логирование, DNSSEC, RRL, transfer‑ы по TSIG.
- Независимость от провайдера: перенос доменов/зон без смены имён NS.
- Тонкая сеть: ближайшие точки присутствия, собственный anycast (если умеете), разделение по ЦОД.
Для защиты имён и зон в целом пригодится разбор смежной темы — защита доменного бренда и зоны.
Планирование: имена, IP и топология
Перед началом продумайте:
- Имена: классика — ns1.example.tld и ns2.example.tld. Для отказоустойчивости лучше минимум две независимые площадки.
- IP‑адреса: разные подсети/площадки/ASN, отдельные A и AAAA для каждого NS. Не кладите оба NS на один IP или одну VM.
- Порты и протоколы: UDP/53 и TCP/53 должны быть доступны. Не забывайте про фрагментацию и ICMP — иначе будут редкие «призрачные» проблемы.
- Безопасность: отключите рекурсию, ограничьте AXFR, включите RRL, следите за ответами на TCP/53 под нагрузкой.
- TTL: на старте придерживайтесь умеренных TTL (например, 3600) для возможности оперативных правок.
Шаг 1. Поднимите авторитетные DNS‑сервера
Нужен любой софт авторитетного DNS: BIND, Knot DNS, NSD, PowerDNS Authoritative. Суть одна: зона должна отдавать корректные SOA/NS, а имена NS внутри зоны — иметь A/AAAA. Удобно размещать авторитетные узлы на изолированных инстансах — подойдут две и более виртуальные машины на разных площадках, например VDS с разнесением по ЦОД.
Минимальная зона (пример)
$ORIGIN example.com.
$TTL 3600
@ IN SOA ns1.example.com. hostmaster.example.com. (
2025010101 ; serial
3600 ; refresh
900 ; retry
1209600 ; expire
300 ) ; minimum
IN NS ns1.example.com.
IN NS ns2.example.com.
ns1 IN A 203.0.113.10
ns1 IN AAAA 2001:db8:10::53
ns2 IN A 203.0.113.11
ns2 IN AAAA 2001:db8:11::53
Критично, чтобы серверы реально отвечали авторитетно (AA=1), не делали рекурсию, и чтобы TCP/53 тоже работал.
Фрагмент конфигурации BIND (идея)
options {
recursion no;
allow-transfer { none; };
rate-limit { responses-per-second 20; };
};
zone "example.com" {
type master;
file "/etc/bind/zones/db.example.com";
};
Проверьте зону перед запуском: утилиты типа named-checkzone или аналоги у вашего DNS‑софта помогут поймать синтаксис и базовые ошибки.
Шаг 2. Создайте host‑объекты (glue) у регистратора
Для in‑bailiwick NS большинство регистраторов требуют завести «дочерние хосты» (host objects, child hosts, registered nameserver). По сути это и есть glue: вы объявляете ns1.example.tld → A/AAAA и ns2.example.tld → A/AAAA. Если домен ещё не зарегистрирован — начните с регистрации доменов.
- gTLD (.com/.net/.org): обычно один раз регистрируете ns1/ns2 как host‑объекты — их можно потом использовать для разных доменов.
- ccTLD (.ru/.рф и др.): терминология и требования могут отличаться, но логика та же. Многие реестры принимают glue как A и AAAA; IPv6‑glue поддерживается широко.
Желательно заранее снизить TTL в вашей зоне и на стороне провайдера DNS (если меняете IP NS), затем добавить/изменить glue и выждать кэш.
Шаг 3. Делегируйте домен на собственные NS
После создания host‑объектов установите для домена NS‑набор: ns1.example.tld и ns2.example.tld. Учтите:
- Согласованность: NS в родительской зоне (делегирование) и NS внутри вашей зоны должны совпадать по набору имён. Различия допустимы, но повышают риск «lame» и усложняют диагностику.
- Glue полнота: укажите A и при наличии AAAA для каждого in‑bailiwick NS. Некоторые реестры позволяют только A — смотрите политику TLD.
- Количество: минимум два NS на независимых площадках. Один NS — это SPOF.
Vanity nameservers: белейбл без своего софта
Сценарий: вы используете DNS‑платформу провайдера, но хотите свои имена NS (ns1.brand.tld). Варианты реализации:
- Провайдер поддерживает vanity: вы регистрируете glue для ns1.brand.tld/ns2.brand.tld на IP, которые дал провайдер (часто это его Anycast). Он на своей стороне настраивает ответные NS так, чтобы авторитетные ответы содержали ваши именованные NS. Это идеальный вариант.
- Провайдер не поддерживает vanity: формально вы можете сделать glue на его IP, но в авторитетных ответах NS будут «чужие». Это воспринимается как «stealth NS» и может путать диагностику или нарушать требования некоторых реестров/валидаторов.
Имейте в виду: NS не могут быть CNAME. Любые попытки «замаскировать» NS через CNAME приведут к невалидной зоне.
Если переносите портфель доменов между NS‑провайдерами, используйте чек‑лист из статьи перенос домена: EPP‑код и DNS.
Проверка: что и как смотреть
dig +trace
Базовый способ увидеть путь резолва и работу делегирования.
dig +trace example.com NS
Смотрите, кто отвечает на каждом уровне, и провалидируйте, что на авторитетных серверах ответы приходят быстро и последовательно.
Проверка авторитетности и TCP
dig @ns1.example.com example.com SOA +norecurse
dig @ns1.example.com example.com SOA +tcp +norecurse
Флаг AA в ответе должен быть 1, время ответа стабильным, а TCP работать без таймаутов.
Glue глазами whois и host‑объектов
В данных домена и/или host‑объекта у регистратора должны быть видны ваши NS и их IP. Несовпадение IP в host‑объекте и фактических A/AAAA в вашей зоне — частая причина «ломаного» делегирования.
DNSSEC, если включаете
- Подпишите зону (KSK/ZSK), проверьте RRSIG и NSEC/NSEC3.
- Опубликуйте DS у регистратора для домена после валидации подписей.
- Убедитесь, что ключи ротируются корректно и нет просроченных RRSIG.
IPv6‑glue и dual‑stack
Рекомендуется иметь AAAA‑glue для каждого NS, если TLD и регистратор это поддерживают. Проверьте доступность по IPv6: MTU, фильтрацию ICMPv6, фрагментацию, корректную маршрутизацию. Многие корпоративные резолверы предпочитают v6 при наличии.
Типичные ошибки и их симптомы
- Неверный glue (IP) у NS: резолверы ходят «в никуда». Симптомы — таймауты на первом заходе, но успех при повторных попытках (когда кэш уже есть).
- Один и тот же IP у двух NS: формально проходит, по факту SPOF. Нагрузочные пики и отказ дадут массовые ошибки NXDOMAIN/SERVFAIL.
- Отключён TCP/53: большие ответы (DNSSEC, много записей) ломаются. dig +tcp покажет проблему.
- Включена рекурсия на авторитетных NS: риск амплификаций и мусор в логах. Отключайте recursion.
- Несогласованные NS в child/parent: «lame delegation», разные наборы NS, непредсказуемость в кэше резолверов.
- AXFR открыт для всех: утечка зоны, повышение риска атак. Закрывайте или TSIG.
- DNSSEC без DS или с неверным DS: SERVFAIL у валидирующих резолверов. Проверяйте цепочку доверия.
- Слишком большие TTL: медленная реакция на переносы/миграции. Для NS‑сетапа в период изменений снижайте TTL заранее.
Пошаговый чек‑лист внедрения
- Выберите имена NS и спланируйте IP (v4/v6, разные площадки/ASN).
- Поднимите два и более авторитетных DNS‑сервера. Отключите рекурсию, настройте RRL, ограничьте AXFR.
- Создайте зону: корректные SOA/NS и A/AAAA для имен NS внутри зоны.
- Заведите у регистратора host‑объекты для ns1/ns2 (glue A/AAAA).
- Установите делегирование домена на ns1/ns2.
- Проверьте dig +trace, авторитетность ответов, TCP/53, IPv6.
- При необходимости включите DNSSEC: подпись зоны, публикация DS, валидация.
- Мониторьте доступность из разных регионов, следите за логами и латентностью.
Vanity: перенос существующих доменов
Если у вас уже есть домены на NS провайдера и он поддерживает vanity:
- Получите у провайдера список IP для вашего набора ns1.brand.tld/ns2.brand.tld.
- Создайте host‑объекты (glue) с этими IP.
- Согласуйте NS‑наборы: провайдер должен отдавать в авторитетных ответах именно ваши ns1.brand.tld/ns2.brand.tld.
- Переведите домены на ваш NS‑набор партиями, наблюдая за логами и ошибками.
Если провайдер vanity не поддерживает, оцените риски «stealth NS» (рассинхрон parent/child) или подумайте о миграции к тому, кто поддерживает корректный белейбл.
Миграции и изменение IP у NS
Меняете адреса ns1/ns2? Действуйте аккуратно:
- Заранее снизьте TTL для glue‑зависимых записей (в вашей зоне и по правилам провайдера DNS).
- Добавьте новые A/AAAA для NS в зоне и на хост‑объекты у регистратора.
- Подержите старые IP включёнными в течение окна миграции, чтобы кэшировавшие резолверы не падали в таймауты.
- Через несколько TTL отрежьте старые адреса.
Особенности IDN
Если домен IDN, регистратор будет хранить host‑объекты в Punycode. При проверке whois/панелей сверяйте, что ns‑имена и glue заведены именно в Punycode‑форме, а зона при этом может содержать Unicode‑вариант (зависит от софта).
Минимальный набор автоматических тестов
- dig +trace домена и однотипные проверки из двух‑трёх разных сетей.
- dig NS/SOA/AAAA на каждый NS с +tcp и +norecurse.
- Проверка задержки и процент таймаутов по UDP/53 и TCP/53.
- Периодическая валидация DNSSEC (если включён): срок RRSIG, валидность DS.
- Алерты на изменения NS‑набора и glue у регистратора (ручные или через API провайдера, если доступно).
Итоги
Собственные NS — это управляемость и бренд, но цена — дисциплина при настройке glue, внимательность к in‑bailiwick деталям, тестирование TCP/UDP, IPv6 и, при необходимости, DNSSEC. Начните с двух независимых площадок, аккуратно заведите host‑объекты, проверьте делегирование через dig +trace, держите TTL разумными и не забывайте про безопасность (no‑recursion, ограничение AXFR, RRL). При работе с vanity nameservers опирайтесь на провайдера, который умеет корректно «отзеркаливать» ваш NS‑набор в авторитетных ответах. Тогда делегирование будет устойчивым, предсказуемым и готовым к росту нагрузки.
