4 часа без DNS = 2 миллиона убытков: отказоустойчивый DNS для интернет-магазина

Задача клиента: интернет-магазин потерял 2 миллиона из-за DNS

В феврале 2026 года к нам обратился интернет-магазин МегаШоп24 из Краснодара — крупный региональный онлайн-ритейлер бытовой техники и электроники. Ежемесячный оборот — около 40 миллионов рублей, в пиковые дни (распродажи, праздники) — до 5 000 заказов в сутки.

Проблема: в январе DNS-сервер, обслуживающий домен megashop24.ru, стал недоступен на 4 часа. Причина — хостинг-провайдер, у которого были размещены DNS-записи, проводил «плановые работы» без предупреждения. Результат — сайт, API, почта, мобильное приложение — всё перестало работать. Клиенты видели ошибку «DNS_PROBE_FINISHED_NXDOMAIN» и уходили к конкурентам.

«За 4 часа мы потеряли около 2 миллионов рублей выручки. Но хуже всего — потеря доверия. Клиенты подумали, что мы закрылись. Некоторые до сих пор не вернулись» — коммерческий директор МегаШоп24.

После инцидента руководство решило взять DNS-инфраструктуру полностью под свой контроль и обеспечить отказоустойчивость уровня enterprise.

Аудит DNS-инфраструктуры

Текущее состояние было минимальным:

  • DNS — два NS-записи, обе указывали на DNS-серверы хостинг-провайдера (ns1.provider.ru, ns2.provider.ru)
  • Зоны — megashop24.ru (основной сайт), api.megashop24.ru, cdn.megashop24.ru, mail.megashop24.ru
  • Количество записей — около 60 DNS-записей (A, AAAA, CNAME, MX, TXT, SRV)
  • DNSSEC — не настроен
  • Мониторинг DNS — отсутствует
  • TTL — 86400 (24 часа) для всех записей (слишком большой, затрудняет оперативные изменения)

Проблемы:

  • Single point of failure — оба NS-сервера у одного провайдера, в одной стойке
  • Нет контроля — изменения DNS через тикет провайдеру, время реакции 2–4 часа
  • Нет DNSSEC — уязвимость к DNS spoofing и cache poisoning
  • Нет split-horizon — внутренние сервисы резолвились через публичный DNS

Проектирование отказоустойчивой DNS-архитектуры

Мы спроектировали архитектуру с географическим разнесением и несколькими уровнями отказоустойчивости:

# Архитектура DNS
┌────────────────────────────────────────────────────────┐
│                    Интернет                             │
│                                                        │
│  ns1.megashop24.ru          ns2.megashop24.ru          │
│  (Краснодар, DC1)           (Москва, DC2)              │
│  ┌──────────────┐           ┌──────────────┐           │
│  │ BIND 9.18    │◄──AXFR───►│ PowerDNS 4.9 │           │
│  │ Master       │  /IXFR    │ Slave+MySQL  │           │
│  │ DNSSEC       │           │ DNSSEC       │           │
│  └──────┬───────┘           └──────┬───────┘           │
│         │                          │                   │
│  ns3.megashop24.ru (Selectel DNS — третий NS)          │
│  ┌──────────────┐                                      │
│  │ Selectel DNS │◄──AXFR от Master                     │
│  │ Anycast      │                                      │
│  └──────────────┘                                      │
└────────────────────────────────────────────────────────┘

┌────────────────────────────────────────────────────────┐
│                Внутренняя сеть (Split-Horizon)          │
│                                                        │
│  ┌──────────────┐           ┌──────────────┐           │
│  │ BIND internal│           │ BIND internal│           │
│  │ (10.0.1.53)  │◄──sync───►│ (10.0.2.53)  │           │
│  │ Рекурсия +   │           │ Рекурсия +   │           │
│  │ внутр. зоны  │           │ внутр. зоны  │           │
│  └──────────────┘           └──────────────┘           │
└────────────────────────────────────────────────────────┘

Ключевые решения:

  • BIND как Primary (master) — проверенный, стабильный, отлично работает с DNSSEC
  • PowerDNS как Secondary (slave) — хранит зоны в MySQL, удобен для автоматизации через API
  • Selectel DNS — третий NS на anycast-инфраструктуре (глобальная доступность)
  • Разные площадки — Краснодар и Москва, разные провайдеры, разные подсети

Настройка BIND как Primary DNS-сервера

BIND (Berkeley Internet Name Domain) — самый распространённый DNS-сервер в мире. Мы установили его на выделенный сервер в ЦОД Краснодара.

Установка и базовая конфигурация BIND 9.18

Установка на Ubuntu 22.04 LTS:

# Установка BIND
sudo apt update
sudo apt install -y bind9 bind9-utils bind9-dnsutils

# Основная конфигурация
# /etc/bind/named.conf.options
options {
    directory "/var/cache/bind";

    # Слушаем на внешнем IP
    listen-on { 185.50.10.53; 127.0.0.1; };
    listen-on-v6 { none; };

    # Отключаем рекурсию (это авторитативный сервер)
    recursion no;
    allow-recursion { none; };

    # Скрываем версию BIND
    version "not disclosed";

    # Ограничиваем трансферы
    allow-transfer { none; };  # По умолчанию запрещаем

    # DNSSEC
    dnssec-validation auto;

    # Rate limiting (защита от DDoS)
    rate-limit {
        responses-per-second 10;
        window 5;
        slip 2;
        ipv4-prefix-length 24;
    };

    # Логирование
    querylog yes;
};

Настройка зоны megashop24.ru

Описание зоны в named.conf и файл зоны:

# /etc/bind/named.conf.local

# ACL для slave-серверов
acl "slaves" {
    91.200.25.53;      # ns2 (Москва, PowerDNS)
    185.12.64.0/24;    # Selectel DNS
};

# Ключ TSIG для аутентификации трансферов
key "transfer-key" {
    algorithm hmac-sha256;
    secret "B3s3cur3_TS1G_K3y_F0r_Tr4nsf3r=";
};

zone "megashop24.ru" {
    type master;
    file "/var/lib/bind/db.megashop24.ru";
    allow-transfer { key "transfer-key"; };
    also-notify { 91.200.25.53; };  # Уведомлять slave при изменениях
    notify yes;
};

Файл зоны:

; /var/lib/bind/db.megashop24.ru
$TTL 300    ; 5 минут (короткий TTL для оперативности)
@   IN  SOA ns1.megashop24.ru. admin.megashop24.ru. (
    2026020101  ; Serial (YYYYMMDDNN)
    3600        ; Refresh (1 час)
    900         ; Retry (15 мин)
    1209600     ; Expire (2 недели)
    300         ; Negative TTL (5 мин)
)

; NS-записи (3 сервера в разных локациях)
@       IN  NS  ns1.megashop24.ru.
@       IN  NS  ns2.megashop24.ru.
@       IN  NS  ns3.megashop24.ru.

; NS glue records
ns1     IN  A   185.50.10.53    ; Краснодар
ns2     IN  A   91.200.25.53    ; Москва
ns3     IN  A   185.12.64.53    ; Selectel Anycast

; Основной сайт
@       IN  A       185.50.10.10
@       IN  AAAA    2a01:db8::10
www     IN  CNAME   @

; API
api     IN  A       185.50.10.11

; CDN
cdn     IN  CNAME   cdn.megashop24.ru.cdn.cloudflare.net.

; Почта
@       IN  MX  10  mail.megashop24.ru.
mail    IN  A       185.50.10.20

; SPF, DKIM, DMARC
@       IN  TXT     "v=spf1 mx ip4:185.50.10.20 -all"
mail._domainkey IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhki..."
_dmarc  IN  TXT     "v=DMARC1; p=quarantine; rua=mailto:dmarc@megashop24.ru"

; Внутренние сервисы
admin       IN  A   185.50.10.12
monitoring  IN  A   185.50.10.13

; SRV-записи
_sip._tcp   IN  SRV 10 60 5060 sip.megashop24.ru.
sip         IN  A   185.50.10.25

Мы установили TTL 300 секунд (5 минут) вместо 24 часов. Это позволяет быстро переключать записи в случае инцидента — все DNS-резолверы в мире обновят кэш за 5 минут.

Обратите внимание на структуру зоны: мы разделили записи по логическим блокам (NS, веб, API, CDN, почта, безопасность почты, внутренние сервисы, SRV). Это упрощает администрирование — при изменении серверной инфраструктуры администратор быстро находит нужный блок. Также мы добавили полный набор записей для email-аутентификации (SPF, DKIM, DMARC), что важно для доставляемости писем и защиты от фишинга.

Rate limiting в конфигурации BIND (responses-per-second 10) — это защита от DNS amplification DDoS-атак. Без неё злоумышленник может использовать наш DNS-сервер как усилитель для атаки на третьих лиц, отправляя запросы с поддельным IP-адресом жертвы.

PowerDNS как Secondary DNS с MySQL-бэкендом

Вторым NS-сервером мы выбрали PowerDNS — он принципиально отличается от BIND: хранит зоны в реляционной БД (MySQL/PostgreSQL) вместо текстовых файлов и имеет встроенный REST API.

Установка PowerDNS Authoritative Server

Установка на сервере в московском ЦОД:

# Установка MySQL 8.0
sudo apt update
sudo apt install -y mysql-server

# Создание БД для PowerDNS
mysql -u root -p <<'SQL'
CREATE DATABASE powerdns CHARACTER SET utf8mb4;
CREATE USER 'pdns'@'localhost' IDENTIFIED BY 'PdnS_DB_P@ss!';
GRANT ALL PRIVILEGES ON powerdns.* TO 'pdns'@'localhost';
FLUSH PRIVILEGES;
SQL

# Установка PowerDNS
sudo apt install -y pdns-server pdns-backend-mysql

# Инициализация схемы БД
mysql -u pdns -p powerdns < /usr/share/doc/pdns-backend-mysql/schema.mysql.sql

Конфигурация PowerDNS как slave:

# /etc/powerdns/pdns.conf

# Основные параметры
setuid=pdns
setgid=pdns
local-address=91.200.25.53
local-port=53

# MySQL backend
launch=gmysql
gmysql-host=127.0.0.1
gmysql-port=3306
gmysql-dbname=powerdns
gmysql-user=pdns
gmysql-password=PdnS_DB_P@ss!

# Slave mode
secondary=yes
autosecondary=yes

# TSIG ключ для аутентификации
# Добавляется через pdnsutil:
# pdnsutil import-tsig-key transfer-key hmac-sha256 "B3s3cur3_TS1G_K3y_F0r_Tr4nsf3r="

# API (для управления и мониторинга)
api=yes
api-key=PdnS_API_K3y!
webserver=yes
webserver-address=127.0.0.1
webserver-port=8081

# Логирование
log-dns-queries=yes
loglevel=4

Регистрация slave-зоны:

# Добавление зоны в режиме slave
pdnsutil create-secondary-zone megashop24.ru 185.50.10.53

# Привязка TSIG-ключа
pdnsutil import-tsig-key transfer-key hmac-sha256 "B3s3cur3_TS1G_K3y_F0r_Tr4nsf3r="
pdnsutil set-meta megashop24.ru TSIG-ALLOW-AXFR transfer-key
pdnsutil set-meta megashop24.ru AXFR-MASTER-TSIG transfer-key

# Запуск первоначального трансфера зоны
pdns_control retrieve megashop24.ru

# Проверка
pdnsutil list-zone megashop24.ru | head -20

Репликация AXFR/IXFR и автоматическая синхронизация

Два механизма синхронизации DNS-зон:

  • AXFR (Full Zone Transfer) — полная передача зоны. Используется при первой синхронизации или когда IXFR невозможен
  • IXFR (Incremental Zone Transfer) — передача только изменений. Экономит трафик и время
# На master (BIND) — настройка NOTIFY
# При изменении зоны BIND автоматически отправляет NOTIFY slave-серверам
# Slave получает NOTIFY → проверяет SOA serial → запрашивает IXFR/AXFR

# Проверка: изменяем запись на master
# 1. Редактируем /var/lib/bind/db.megashop24.ru
# 2. Увеличиваем serial: 2026020101 → 2026020102
# 3. Перезагружаем зону:
sudo rndc reload megashop24.ru

# На slave (PowerDNS) — проверяем синхронизацию
# В логах должно появиться:
# "Received NOTIFY for megashop24.ru from 185.50.10.53"
# "IXFR of megashop24.ru from 185.50.10.53: done"

# Ручная проверка
dig @91.200.25.53 megashop24.ru SOA +short
# ns1.megashop24.ru. admin.megashop24.ru. 2026020102 3600 900 1209600 300

Время синхронизации: при использовании NOTIFY + IXFR изменения появляются на slave в течение 1–3 секунд после изменения на master.

TSIG-ключ (Transaction SIGnature) обеспечивает аутентификацию трансферов зон. Без него любой сервер, знающий IP master, мог бы запросить полную копию зоны через AXFR — это раскрывает внутреннюю структуру инфраструктуры (IP-адреса, имена серверов). С TSIG только авторизованные серверы могут получать трансферы. Мы использовали HMAC-SHA256 — наиболее безопасный из доступных алгоритмов.

Для Selectel DNS (третий NS) мы настроили AXFR-трансфер через их панель управления, указав IP нашего master и TSIG-ключ. Selectel использует anycast-инфраструктуру — это означает, что один IP-адрес ns3 обслуживается десятками серверов в разных точках мира, обеспечивая минимальную задержку для клиентов из любого региона.

DNSSEC: защита от подделки DNS-ответов

DNSSEC (DNS Security Extensions) — криптографическая подпись DNS-записей, которая гарантирует, что ответ пришёл от авторитативного сервера и не был изменён. Для интернет-магазина это критически важно — DNS spoofing может перенаправить клиентов на фишинговый сайт.

Генерация ключей и подпись зоны

Настройка DNSSEC на BIND master:

# Генерация KSK (Key Signing Key) — подписывает другие ключи
cd /var/lib/bind
dnssec-keygen -a ECDSAP256SHA256 -f KSK megashop24.ru
# Kmegashop24.ru.+013+12345

# Генерация ZSK (Zone Signing Key) — подписывает записи
dnssec-keygen -a ECDSAP256SHA256 megashop24.ru
# Kmegashop24.ru.+013+67890

# Включение автоматической подписи в named.conf
zone "megashop24.ru" {
    type master;
    file "/var/lib/bind/db.megashop24.ru";
    allow-transfer { key "transfer-key"; };
    also-notify { 91.200.25.53; };
    notify yes;
    key-directory "/var/lib/bind";
    auto-dnssec maintain;
    inline-signing yes;
};

# Перезагрузка
sudo rndc reload megashop24.ru
sudo rndc signing -list megashop24.ru

После подписания необходимо добавить DS-запись у регистратора домена. DS-запись — это хеш KSK, который связывает зону с родительской зоной (.ru):

# Получение DS-записи
dnssec-dsfromkey /var/lib/bind/Kmegashop24.ru.+013+12345.key
# megashop24.ru. IN DS 12345 13 2 A1B2C3D4E5F6...

# Эту строку нужно добавить в панели регистратора домена
# (Webnames.ru, REG.RU и т.д.)

Проверка DNSSEC

После настройки мы провели полную проверку:

# Проверка подписи через dig
dig @185.50.10.53 megashop24.ru A +dnssec +short
# 185.50.10.10
# A 13 2 300 20260301000000 20260201000000 67890 megashop24.ru. abc123...

# Проверка цепочки доверия
dig megashop24.ru +trace +dnssec
# Должна быть полная цепочка: . → ru. → megashop24.ru.

# Проверка через DNSSEC Analyzer (онлайн)
# https://dnssec-analyzer.verisignlabs.com/megashop24.ru
# Все проверки должны быть зелёными

# Проверка через delv (DNSSEC-валидирующий резолвер)
delv @185.50.10.53 megashop24.ru A
# ; fully validated
# megashop24.ru.  300  IN  A  185.50.10.10

Автоматическая ротация ZSK настроена через BIND auto-dnssec maintain — новый ключ генерируется каждые 90 дней, старый автоматически удаляется после истечения TTL подписей.

Split-horizon DNS и внутренние зоны

Для внутренней сети МегаШоп24 мы настроили отдельные DNS-серверы с split-horizon — внутренние клиенты получают внутренние IP-адреса, а внешние — публичные.

Конфигурация split-horizon на внутреннем BIND

На внутренних DNS-серверах (10.0.1.53 и 10.0.2.53):

# /etc/bind/named.conf (внутренний DNS)

acl "internal" {
    10.0.0.0/8;
    172.16.0.0/12;
    192.168.0.0/16;
    localhost;
};

view "internal" {
    match-clients { internal; };
    recursion yes;  # Рекурсия для внутренних клиентов

    # Внутренняя зона megashop24.ru (переопределяет публичную)
    zone "megashop24.ru" {
        type master;
        file "/var/lib/bind/internal/db.megashop24.ru";
    };

    # Внутренняя зона для обратного DNS
    zone "0.10.in-addr.arpa" {
        type master;
        file "/var/lib/bind/internal/db.10.0";
    };

    # Форвардинг внешних запросов
    zone "." {
        type forward;
        forwarders { 8.8.8.8; 1.1.1.1; };
    };
};

view "external" {
    match-clients { any; };
    recursion no;

    zone "megashop24.ru" {
        type slave;
        masters { 185.50.10.53; };
        file "/var/lib/bind/external/db.megashop24.ru";
    };
};

Внутренний файл зоны содержит приватные IP:

; /var/lib/bind/internal/db.megashop24.ru
; Внутренние адреса для сервисов
@       IN  A       10.0.1.10    ; Сайт (внутренний)
api     IN  A       10.0.1.11    ; API (внутренний)
mail    IN  A       10.0.1.20    ; Почта (внутренний)
admin   IN  A       10.0.1.12    ; Админка
db      IN  A       10.0.1.30    ; БД (только внутри!)
redis   IN  A       10.0.1.31    ; Redis
rabbit  IN  A       10.0.1.32    ; RabbitMQ
gitlab  IN  A       10.0.1.40    ; GitLab
zabbix  IN  A       10.0.1.50    ; Zabbix

Мониторинг DNS-инфраструктуры

Мы настроили комплексный мониторинг DNS через Zabbix и внешние сервисы:

# Zabbix UserParameter: проверка DNS-ответа
# /etc/zabbix/zabbix_agentd.d/dns.conf

UserParameter=dns.resolve.time[*],dig +noall +stats $1 @$2 | grep 'Query time' | awk '{print $4}'
UserParameter=dns.resolve.status[*],dig +short $1 @$2 > /dev/null 2>&1 && echo 1 || echo 0
UserParameter=dns.serial[*],dig SOA $1 @$2 +short | awk '{print $3}'
UserParameter=dns.axfr.status[*],dig AXFR $1 @$2 +short > /dev/null 2>&1 && echo 1 || echo 0

Триггеры мониторинга:

ПроверкаИнтервалТриггерSeverity
DNS resolve (ns1)30 секНе отвечает > 60 секCritical
DNS resolve (ns2)30 секНе отвечает > 60 секCritical
SOA serial sync5 минРазница serial > 0 за 10 минWarning
Query time1 мин> 100 мсWarning
DNSSEC validation1 часПодпись не валиднаCritical
Certificate expiry1 деньDNSSEC KSK expire < 30 днейWarning

Дополнительно мы подключили внешний мониторинг через Hetrix Tools (бесплатный) — он проверяет DNS из 10 точек мира каждые 60 секунд и отправляет алерт, если хотя бы один NS не отвечает.

Тестирование отказоустойчивости и результаты

После развёртывания мы провели серию тестов, имитируя различные сценарии отказа.

Сценарии тестирования

Мы проверили три сценария:

Тест 1: Отказ master (ns1)

# Останавливаем BIND на ns1
sudo systemctl stop named

# Проверяем с клиента (через 5 секунд)
dig megashop24.ru @91.200.25.53 +short
# 185.50.10.10  ← ns2 (PowerDNS) отвечает корректно

time dig megashop24.ru +short
# 185.50.10.10
# real 0m0.032s  ← 32 мс, клиент автоматически перешёл на ns2

# Восстанавливаем master
sudo systemctl start named

Тест 2: Отказ slave (ns2) — аналогично, ns1 продолжает обслуживать запросы. Время переключения клиентов — 0 мс (ns1 отвечает первым).

Тест 3: Одновременный отказ ns1 и ns2 — ns3 (Selectel Anycast) продолжает обслуживать запросы. Время переключения — до 5 секунд (DNS-резолверы пробуют ns1, ns2, затем ns3).

Тест 4: Изменение записи и проверка синхронизации

# На master: изменяем A-запись
# db.megashop24.ru: test IN A 1.2.3.4 (serial++)
sudo rndc reload megashop24.ru

# Через 2 секунды проверяем на slave
dig test.megashop24.ru @91.200.25.53 +short
# 1.2.3.4  ← Синхронизировалось за 2 секунды

Финальные результаты

Проект занял 6 рабочих дней: 2 дня — установка и настройка серверов, 2 дня — DNSSEC и split-horizon, 2 дня — тестирование и миграция NS-записей у регистратора.

МетрикаДо внедренияПосле внедрения
NS-серверы2 (один провайдер, одна стойка)3 (Краснодар + Москва + Anycast)
SLA DNS~99% (3.6 дня простоя/год)99.99% (52 мин простоя/год)
Время реакции на изменение2–4 часа (тикет провайдеру)Мгновенно (свой сервер)
DNSSECНетECDSAP256SHA256
Время синхронизацииN/A1–3 секунды (NOTIFY+IXFR)
МониторингНетZabbix + внешний мониторинг
Split-horizonНетДа (внутренние IP для LAN)
TTL86400 (24 часа)300 (5 минут)

Ключевые результаты:

  • 0 минут простоя DNS за 3 месяца после внедрения
  • 3 географически разнесённых NS — отказ любых двух не влияет на доступность
  • DNSSEC — защита от DNS spoofing и cache poisoning
  • Время переключения при отказе — менее 5 секунд
  • Полный контроль — изменения применяются мгновенно без посредников
«Теперь я сплю спокойно. У нас три DNS-сервера в разных городах, DNSSEC, мониторинг. Даже если весь Краснодар останется без интернета, наш сайт будет работать» — технический директор МегаШоп24.

Дополнительно мы подготовили для IT-отдела МегаШоп24 набор runbook-инструкций:

  • Добавление DNS-записи — редактирование зоны на master, инкремент serial, rndc reload
  • Аварийное переключение — процедура смены A-записи при падении основного сервера
  • Ротация DNSSEC-ключей — ручная процедура на случай компрометации ключа
  • Восстановление master из slave — как развернуть новый master, если старый погиб

Стоимость проекта составила 180 000 ₽ (включая аренду сервера в Москве на год). Учитывая, что один инцидент с DNS обошёлся в 2 000 000 ₽ убытков, окупаемость — менее одного месяца.

Часто задаваемые вопросы

Это стратегия «software diversity» — защита от уязвимостей в конкретном ПО. Если в BIND обнаружится критическая уязвимость (а это случается), PowerDNS продолжит работать. Кроме того, PowerDNS с MySQL-бэкендом удобнее для автоматизации через API, а BIND лучше подходит для DNSSEC.

Юридически — нет, но настоятельно рекомендуется. Без DNSSEC злоумышленник может подменить DNS-ответ и перенаправить покупателей на фишинговый сайт-клон. Для магазина, обрабатывающего платежи, это прямой финансовый риск. Современные браузеры и резолверы (Google, Cloudflare) проверяют DNSSEC, что также повышает доверие.

ZSK (Zone Signing Key) рекомендуется менять каждые 90 дней — BIND делает это автоматически с auto-dnssec maintain. KSK (Key Signing Key) меняют реже — раз в 1–2 года, так как замена требует обновления DS-записи у регистратора. Алгоритм ECDSAP256SHA256 считается безопасным на ближайшие 10+ лет.

Cloudflare DNS — отличный вариант для большинства компаний: бесплатный, быстрый, с anycast и встроенным DNSSEC. Однако МегаШоп24 хотел полный контроль над DNS-инфраструктурой. С Cloudflare вы зависите от внешнего провайдера (пусть и надёжного). Компромиссный вариант — Cloudflare как один из нескольких NS в комбинации с собственными серверами.

Split-horizon (он же split-brain DNS) — это конфигурация, при которой один и тот же домен возвращает разные IP-адреса для внутренних и внешних клиентов. Это нужно, когда: (1) внутренние сервисы должны быть доступны по тому же домену, но напрямую, без выхода в интернет; (2) есть сервисы, которые вообще не должны быть видны снаружи (БД, очереди, мониторинг).

Нужна помощь с настройкой?

Специалисты АйТи Фреш помогут с внедрением и настройкой — 15+ лет опыта, обслуживание от 15 000 ₽/мес

📞 Связаться с нами
#BIND настройка master slave#PowerDNS MySQL#отказоустойчивый DNS#DNSSEC настройка#DNS failover#AXFR IXFR репликация#split-horizon DNS#мониторинг DNS