Secondary DNS: AXFR/IXFR, Master/Slave и быстрая фейловер‑делегация

Если у вас есть домены с трафиком и SLA, Secondary DNS перестаёт быть «галочкой» и становится обязательным компонентом. Он защищает от простоев авторитативной зоны, ускоряет распространение изменений и упрощает обслуживание. Разберёмся, как устроены AXFR/IXFR, чем отличаются роли Master/Slave (современные термины — Primary/Secondary), как построить схему со «скрытым мастером», и главное — как организовать быструю фейловер‑делегацию, чтобы не ждать кэшей и TTL. Если вы держите авторитативные NS на собственной инфраструктуре (например, на VDS), всё ниже — про вас.

Термины и роль Secondary DNS

Классическая схема: есть авторитативный сервер зоны, на котором вы редактируете записи (Master/Primary), и один или несколько вторичных серверов (Slave/Secondary), которые принимают копии зоны через трансфер и отвечают на запросы клиентов. В делегировании на уровне регистратора объявлено несколько NS — резолверы случайно выбирают любой из них. Если один NS недоступен, запрос переходит к другому — это и есть базовая отказоустойчивость.

Сегодня чаще говорят Primary/Secondary, но в конфигурациях ПО до сих пор встречаются директивы master/slave. Семантика не меняется: именно Primary — единственный источник истины, где увеличивается SOA serial. Secondary — реплика, которая пассивно обновляется по сигналам и периодике.

AXFR и IXFR: полная и инкрементальная передача зон

AXFR — полная передача зоны. Secondary запрашивает у Primary весь набор записей. Это просто и совместимо с любым софтом, но неэффективно для больших зон.

IXFR — инкрементальная передача. Secondary получает только дельту изменений между номерами серий SOA. Это сильно экономит трафик и ускоряет распространение правок. Если дельту собрать нельзя (например, Secondary слишком отстал), сервер автоматически откатится к AXFR.

В обоих случаях критично правильно вести SOA serial. Выберите формат и придерживайтесь его: либо YYYYMMDDnn, либо монотонно возрастающий Unix time. Любое изменение зоны должно сопровождаться увеличением serial, иначе Secondary не поймут, что нужно обновиться.

NOTIFY и тайминги SOA

Механизм NOTIFY позволяет Primary «толкнуть» изменения на Secondary, не дожидаясь таймеров. С Secondary точки зрения это просто сигнал проверить SOA и, если номер вырос, запросить IXFR/AXFR.

Параметры таймингов в SOA тоже важны:

• refresh — период, через который Secondary сам проверит SOA, если не пришёл NOTIFY;
• retry — пауза между повторными попытками;
• expire — когда Secondary считает зону просроченной и перестаёт на неё отвечать (очень важно для целостности);
• minimum — негативное кэширование (NXDOMAIN TTL).

Не ставьте экстремально короткие значения — Secondary будут слишком часто дёргать Primary. Баланс для продакшена обычно: refresh 5–15 мин, retry 2–5 мин, expire 1–2 суток.

Схемы развертывания: видимый мастер и скрытый мастер

Видимый мастер — Primary присутствует в делегировании (NS-записях у родителя) и отвечает на клиентский трафик. Просто, но при его перегрузке пострадают пользователи.

Скрытый мастер (hidden master) — Primary вообще не объявляется в делегировании. Он закрыт от внешнего мира ACL’ами и брандмауэром, принимает только трансферы и NOTIFY. В делегировании — только Secondary (часто с anycast). Это повышает безопасность и стабильность.

Для быстрых изменений зоны скрытый мастер удобен: вы вносите правку, увеличиваете SOA serial, отправляете NOTIFY, и через секунды все Secondary начинают отвечать с новыми данными.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Безопасность трансферов: TSIG, ACL и закрытие рекурсии

Никогда не оставляйте открытый AXFR для всех. Разрешайте трансферы только адресам Secondary (ACL allow-transfer) и подписывайте запросы TSIG ключами. На авторитативных серверах должна быть отключена рекурсия: авторитативный — не резолвер.

Проверьте сетевую часть: для AXFR/IXFR нужен TCP 53 (и UDP 53 для NOTIFY и служебных запросов). Файрволы и NAT часто блокируют или ломают крупные TCP-сегменты, особенно при больших зонах. Тестируйте обе стороны.

Практика: Primary на BIND, Secondary на Knot/NSD

Далее — минимальный пример. Он показывает идею и контрольные точки; адаптируйте пути и имена под свою инфраструктуру.

1) Создать ключ TSIG

tsig-keygen -a hmac-sha256 axfr-key > /etc/dns/keys/axfr-key.key
chmod 640 /etc/dns/keys/axfr-key.key

Содержимое файла понадобится обеим сторонам.

2) Зона и BIND (Primary)

// /etc/named.conf (фрагмент)
acl secondaries { 192.0.2.10; 2001:db8::10; };
include "/etc/dns/keys/axfr-key.key";

options {
  directory "/var/named";
  recursion no;
  allow-query { any; };
  allow-transfer { key axfr-key; secondaries; };
  notify yes;
};

server 192.0.2.10 { keys { axfr-key; }; };
server 2001:db8::10 { keys { axfr-key; }; };

zone "example.org" IN {
  type master;
  file "example.org.zone";
  allow-transfer { key axfr-key; secondaries; };
  also-notify { 192.0.2.10 key axfr-key; 2001:db8::10 key axfr-key; };
};

Пример файла зоны:

$TTL 300
@  IN  SOA  ns1.example.org. dns.example.org. (
        2025102301 ; serial
        900        ; refresh
        300        ; retry
        1209600    ; expire
        300 )      ; minimum

   IN  NS  ns1.example.org.
   IN  NS  ns2.example.net.

ns1 IN  A     198.51.100.11
ns1 IN  AAAA  2001:db8:100::11
www IN  A     203.0.113.20
api IN  A     203.0.113.21

Перед стартом убедитесь, что зона валидна:

named-checkzone example.org /var/named/example.org.zone
systemctl reload named

3) Knot DNS или NSD (Secondary)

Для Knot:

# /etc/knot/knot.conf (фрагмент)
key:
  - id: axfr-key
    algorithm: hmac-sha256
    secret: "BASE64_FROM_FILE"

remote:
  - id: primary
    address: 192.0.2.5@53
    address: 2001:db8::5@53
    key: axfr-key

acl:
  - id: xfr-in
    address: 192.0.2.5
    address: 2001:db8::5
    key: axfr-key

zone:
  - domain: example.org
    master: primary
    acl: xfr-in

server:
  listen: [0.0.0.0@53, ::@53]
  rrl-size: 2000

Для NSD:

# /etc/nsd/nsd.conf (фрагмент)
key:
  name: axfr-key
  algorithm: hmac-sha256
  secret: "BASE64_FROM_FILE"

server:
  hide-version: yes
  ip-address: 0.0.0.0
  ip-address: ::

zone:
  name: example.org
  zonefile: example.org.zone
  request-xfr: 192.0.2.5@53 axfr-key
  allow-notify: 192.0.2.5@53 axfr-key
  notify-retry: 60

Запускаем, проверяем логи, что IXFR/AXFR прошёл и зона в статусе «OK».

4) Сеть и брандмауэр

# Проверка доступности портов 53/tcp и 53/udp
nc -vz 192.0.2.5 53
nc -vz 192.0.2.10 53

# Пинг или трассировка для базовой диагностики
ping -c 3 192.0.2.10
traceroute 192.0.2.10

Проверка и эксплуатация

После первого трансфера сверяем номера серий:

dig +short @192.0.2.5 example.org SOA
dig +short @192.0.2.10 example.org SOA

Дальше — проверка полного AXFR (для авторизованных адресов/TSIG):

dig @192.0.2.10 example.org AXFR

Проверяем NOTIFY: правим зону, повышаем serial, перегружаем Primary и отслеживаем, что Secondary почти сразу подхватил новую версию.

Быстрая фейловер‑делегация: стратегии

Ключевая идея: не ждать часов кэширования у резолверов, а заранее подготовить делегирование так, чтобы отказ любого NS не приводил к простою. Есть три практичных подхода, которые комбинируются.

1) Параллельные NS‑сеты у родителя

Самый надёжный способ — в делегировании у регистратора держать сразу несколько NS из разных автономных зон ответственности (разные провайдеры или ваши площадки). Все они authoritative для одной и той же зоны, получают обновления от единого скрытого мастера. Если один NS‑кластер падает, рекурсивные резолверы автоматически переключаются на остальные, ничего менять у родителя не нужно.

Что важно:

• Согласуйте одинаковое содержимое зоны на всех Secondary (единый источник — ваш Primary, NOTIFY и IXFR включены).
• Следите, чтобы SOA MNAME и тайминги совпадали. Разные версии у разных NS — гарантия хаоса.
• Если ваши NS под доменом самой зоны (vanity NS), не забывайте про glue A/AAAA у родителя. Они тоже должны быть отказоустойчивыми.

Регистрация доменов от 99 руб.

Каждый проект заслуживает идеального доменного имени, выберите один из сотни, чтобы начать работу!

Зарегистрировать домен

Тема тесно связана с защитой доменного портфеля и процедурой смены поставщика NS. Для углубления посмотрите «Защита доменного бренда» в разделе бренд‑защиты доменов и разбор «Перенос домена и EPP‑код, нюансы DNS» — подробная статья о переносе.

2) Смена делегирования как план B

Если по организационным причинам нельзя держать параллельные NS‑сеты, готовьте заранее шаблоны на быструю замену делегирования у регистратора. Однако учтите: TTL NS на стороне родителя контролирует реестр TLD, вы его не ускорите. Из-за кэшей резолверов эффект смены будет растянут. Поэтому план «мгновенного» переключения на практике нередко оказывается «минуты–часы».

3) «Смена клея» для vanity NS

Когда NS находятся в той же зоне (например, ns1.example.org), у родителя создаются glue записи. Быстрый фейловер возможен через переключение IP адресов этих glue на заранее подготовленные адреса второй площадки. Здесь тоже работают кэши, но в некоторых реестрах обновление host‑объектов распространяется быстрее, чем изменение всей делегации.

Подготовка зоны к фейловеру

Чтобы изменения записей внутри зоны распространялись быстро, снизьте $TTL для критичных записей (A/AAAA, MX, SRV) за 24–48 часов до плановой операции до 300–600 секунд. Для делегирования (NS на стороне родителя) этот трюк не работает — там TTL задаёт реестр.

Отдельный нюанс — DNSSEC. Если зона подписана, и у вас несколько независимых Secondary, либо используйте «inline signing» на поверхности одного контура, либо отработайте процедуру multi‑signer. Смешивать подписанные ответы от разных поставщиков без согласованного ключевого материала нельзя: получится «SERVFAIL» на части резолверов. При миграции NS — поддерживайте валидные DS у родителя для всех действующих ключей до завершения перестроения.

Мониторинг и алерты

Минимальный набор сигналов:

• Несовпадение SOA serial между Primary и Secondary дольше порога (например, 5 минут).
• Ошибки IXFR/AXFR и NOTIFY в логах (авторизация TSIG, таймауты, блокировки портов).
• Большой процент SERVFAIL/REFUSED на внешних пробывальщиках; рост времени ответа.
• Состояние TCP 53, MTU/PMTU проблемы на маршруте, фрагментация.

Для быстрой диагностики полезно периодически опрашивать конкретный NS и сравнивать ответы:

dig +noall +answer @ns1.example.net example.org SOA
dig +noall +answer @ns2.example.net example.org SOA

Производительность и устойчивость

Secondary на anycast — хороший бонус: трафик упрётся в ближайший узел, латентность ниже, нагрузка распределяется. Включите RRL (Response Rate Limiting) на авторитативных серверах, чтобы снизить риск усилительных DDoS. Проверьте лимиты файловых дескрипторов и сокетов на системе, чтобы не упереться в пределы при пике запросов. Если у вас нет железа в разных локациях — поднимите узлы на независимых VDS площадках.

Частые ошибки

• Забыли увеличить SOA serial — Secondary не обновились.
• Открытый AXFR без ACL/TSIG — утечка зоны наружу.
• Включена рекурсия на авторитативном — злоумышленники используют ваш NS как отражатель.
• Блокирован TCP 53 — IXFR/AXFR не проходит, зона висит на старой версии.
• Слишком большой expire и слишком редкий refresh — при разрыве связи Secondary долго будут отвечать устаревшими данными, а потом внезапно «впадут в тишину».
• DNSSEC несогласован между площадками — клиенты видят SERVFAIL.

Чек‑лист внедрения Secondary DNS

1. Определите схему: видимый или скрытый мастер; сколько Secondary и где.
2. Подготовьте TSIG ключи, ACL, закройте рекурсию.
3. Настройте IXFR и NOTIFY, проверьте TCP/UDP 53 между площадками.
4. Согласуйте SOA: адекватные refresh/retry/expire, единый MNAME.
5. Автоматизируйте релизы зоны: правка → рост serial → reload → NOTIFY → сверка SOA.
6. В делегировании у родителя держите NS из разных доменов/сетей; протестируйте отказ любого NS.
7. Если зона подписана — спланируйте multi‑signer или единый контур подписания.
8. Настройте мониторинг serial‑расхождений и доступности TCP 53.

Итог: Secondary DNS — это не «резервная копия», а операционная практика. С грамотно настроенными AXFR/IXFR, TSIG и NOTIFY, скрытым мастером и параллельными NS в делегировании вы получите предсказуемые обновления и устойчивость к отказам.

Если домены обслуживаются у вас, проверяйте, что у регистратора поддерживаются независимые NS‑сеты и оперативное управление glue. При необходимости переноса домена — заранее подготовьте вторую площадку и протестируйте синхронизацию до переключения. Для новых проектов начните с корректного делегирования и удобной регистрации доменов — это упростит дальнейшую эксплуатацию.