Anycast DNS для распределённого бизнеса: когда DNS — это SPOF и как от него избавиться

Меня зовут Семёнов Евгений Сергеевич, директор АйТи Фреш. В сентябре 2025 у моего клиента — торговая сеть с офисом в Москве и пятью магазинами в Подмосковье — единственный DNS-сервер в центральном офисе улёгся спать на 4 часа. Вместе с ним встали 1С, почта, внутренний портал, WiFi с 802.1X и все магазинные кассы, потому что никто не мог резолвить хосты AD. Через неделю после инцидента мы поставили им Anycast DNS на трёх узлах. С тех пор DNS уже один раз падал на одном из узлов — и никто этого не заметил. Расскажу, как это устроено и сколько стоит.

Почему традиционный DNS у бизнеса — это мина

Типовая схема среднего офиса: один контроллер домена на Windows Server 2022 с ролью DNS, второй DC как реплика, клиенты указывают обе. Выглядит отказоустойчиво — но не работает в двух сценариях:

• Оба DC в одном VLAN. При падении свитча или петле в сети оба становятся недоступны. Клиенты сидят с таймаутами.
• Удалённые офисы. Филиал в другом городе держит копию DNS или спрашивает через VPN. Если VPN-туннель упал — всё, локальный резолв перестаёт работать, магазинные кассы не могут достучаться до 1С.
• Внешние запросы. AD-DNS forwards наружу (Yandex, Google). Если forwarder'ы отвечают медленно — внутренний пользователь видит «тормозит интернет».

Anycast DNS решает все три проблемы сразу: несколько узлов анонсируют один и тот же IP через BGP, клиенты (настроенные на этот IP) автоматически попадают на ближайший живой сервер. Один упал — трафик уходит на другой за секунды, не за таймауты.

Как устроено — на схеме

Типовая архитектура для компании с 3 офисами:

• Три Linux-сервера (Debian 12 или Astra Linux 1.7). По одному в каждом офисе или в трёх разных дата-центрах.
• На каждом — PowerDNS Authoritative (держит зоны) и PowerDNS Recursor (резолвит наружу + кэширует).
• Каждый сервер анонсирует через BGP один и тот же адрес, например 10.99.0.10/32 (для внутренней сети) и 198.51.100.10/32 (для внешних запросов).
• BGP-пиринг с провайдерским маршрутизатором или с внутренним L3-оборудованием (Mikrotik, Juniper, Huawei).
• Клиенты (рабочие станции, 1С-сервер, VoIP-телефоны) настроены на эти два IP как primary/secondary DNS.
• Health check на каждом узле: если PowerDNS не отвечает — скрипт через frr vtysh снимает анонс. Через 3-5 секунд клиенты переходят на другой узел.

Зоны (A, AAAA, MX, SRV, CNAME, TXT) хранятся в git-репозитории как YAML. OctoDNS читает их и синхронизирует с базой PowerDNS через API. Любое изменение — через pull request, после merge запускается CI и применяет изменения во все узлы.

PowerDNS: почему не BIND и не dnsmasq

BIND — исторический лидер, но тяжёлый в администрировании и неудобно интегрируется с IaC. Пять лет назад ещё был разумным выбором, сегодня редко.

dnsmasq — хорош для дома и небольшого офиса с IoT-роутером, но не для продового DNS уровня бизнеса. Нет настоящего master/slave, нет API, нет поддержки DNSSEC в реальном виде.

PowerDNS — чёткое разделение на Authoritative (ответы по своим зонам) и Recursor (резолв чужих). Есть HTTP API, поддерживает множество бэкендов (MySQL, PostgreSQL, SQLite, LDAP, plain BIND-file), работает быстро (десятки тысяч qps на обычном VM).

Для бизнеса я ставлю Authoritative + Recursor на один узел. Authoritative слушает на 0.0.0.0:53 для зон corp.example.ru и dc1.corp.example.ru, Recursor — на том же порту, но принимает запросы на внешний IP с внутренней сети и использует Authoritative как forwarder для внутренних зон.

BGP Anycast: необходимое и достаточное

BGP — это протокол, через который маршрутизаторы обмениваются информацией о доступных сетях. Для Anycast DNS мы используем iBGP (внутренний) или eBGP (с провайдером) и анонсируем один и тот же префикс из нескольких точек.

Для внутреннего анонса (между офисами компании) достаточно iBGP — без регистрации AS в RIPE. Пример на FRR:

# /etc/frr/bgpd.conf на узле DNS-01 в Москве
router bgp 65100
 bgp router-id 10.10.0.1
 neighbor 10.10.0.254 remote-as 65100
 neighbor 10.10.0.254 description MX-CORE-MSK
 !
 address-family ipv4 unicast
  network 10.99.0.10/32 route-map ANYCAST-DNS
  neighbor 10.10.0.254 activate
 exit-address-family
!
route-map ANYCAST-DNS permit 10
 set metric 100
exit

Для внешнего анонса (публичный DNS для клиентов, когда вы провайдер или хостер) нужна регистрация autonomous system в RIPE NCC и Provider Independent (PI) подсеть. Для среднего бизнеса это оверкилл — внешний DNS проще купить у Яндекса или Selectel.

Health check — без него не работает

Если узел DNS анонсирует IP, но PowerDNS на нём умер, клиенты всё равно будут попадать на мёртвый узел (BGP не знает, что внутри). Нужен внешний контроль, который снимает анонс при падении сервиса.

Вариант 1 — скрипт в systemd timer каждые 5 секунд:

#!/bin/bash
# /usr/local/bin/dns-health.sh
if ! dig @127.0.0.1 SOA corp.example.ru +time=2 +tries=1 >/dev/null; then
  vtysh -c "configure" -c "router bgp 65100" \
    -c "address-family ipv4 unicast" \
    -c "no network 10.99.0.10/32 route-map ANYCAST-DNS"
  logger "DNS health check failed, withdrew BGP route"
else
  # Если был withdraw — восстанавливаем
  vtysh -c "show ip bgp 10.99.0.10" | grep -q "not advertised" && \
    vtysh -c "configure" -c "router bgp 65100" \
      -c "address-family ipv4 unicast" \
      -c "network 10.99.0.10/32 route-map ANYCAST-DNS"
fi

Вариант 2 — BFD-сессии между DNS-узлом и роутером. Более корректно, но требует поддержки BFD на обеих сторонах. В Mikrotik ROS 7+ и FRR это работает.

Вариант 3 — «понижение приоритета» вместо withdraw. Вместо удаления маршрута меняем AS-path prepend, и трафик уходит на другой узел мягко. Этот способ предпочтительней для плановых работ.

IaC через OctoDNS + GitLab CI

Хранение зон в git даёт code review, аудит, откат одним кликом. Пример зоны в OctoDNS-формате:

# zones/corp.example.ru.yaml
---
'':
  - type: SOA
    values:
      - 'ns1.corp.example.ru. hostmaster.corp.example.ru. 2026021701 3600 900 604800 1800'
'ns1':
  - type: A
    values: [10.99.0.10]
'ns2':
  - type: A
    values: [10.99.0.11]
'1c':
  - type: A
    values: [10.10.0.50]
'mail':
  - type: A
    values: [10.10.0.60]

GitLab CI-пайплайн:

# .gitlab-ci.yml
stages: [plan, apply]

plan:
  stage: plan
  image: octodns/octodns:latest
  script:
    - octodns-sync --config-file=config.yaml --doit=false
  only: [merge_requests]

apply:
  stage: apply
  image: octodns/octodns:latest
  script:
    - octodns-sync --config-file=config.yaml --doit=true
  only: [main]
  environment: production

Когда сотрудник хочет добавить запись — делает MR, в Job plan видит дифф («будет добавлена запись A 10.10.0.77 для web-new»), коллега ревьюит, merge — apply автоматически раскатывает на все узлы через API PowerDNS. Откатить изменение — просто revert commit.

Кейс: Anycast DNS для юридической сети

В декабре 2025 к нам обратилась сеть юридических консультаций — центральный офис в Москве и филиалы в трёх областных центрах (Рязань, Калуга, Тула). Сотрудников суммарно 68. До нас DNS жил на одном Windows Server DC в Москве, все филиалы ходили через VPN. Инциденты: отключение VPN на 1-2 часа раз в пару месяцев, во время которых филиал сидит без почты, 1С, внутреннего портала. Доставало всех.

Что сделали за 3 недели:

1. Закупили 4 недорогих сервера Dell PowerEdge R250 (3 тыс долл суммарно), по одному в каждый офис.
2. Astra Linux 1.7 + PowerDNS 4.8 Authoritative + Recursor на каждом.
3. FRR для iBGP-пиринга между офисами (через Mikrotik CCR2004 на каждом объекте).
4. Anycast-адрес 10.99.0.10 и 10.99.0.11 для primary/secondary DNS клиентов.
5. Синхронизация зон через OctoDNS из gitlab.corp.example.ru (gitlab-runner на одном из узлов).
6. Health check скрипт в systemd timer каждые 5 секунд.
7. Миграция AD-зон: PowerDNS стал secondary для AD-integrated зон, клиенты переключены на Anycast-адреса.
8. Zabbix-мониторинг: qps на каждом узле, средняя задержка, состояние BGP-сессий.

Результат через 3 месяца: один из узлов (рязанский) упал из-за отказа диска, клиенты не заметили — трафик автоматически ушёл на Калугу и Москву. DNS-инциденты исчезли как класс. Стоимость проекта — 380 000 руб. + 210 тыс руб железо. Компания сравнила с часами простоя сотрудников (пакет 68 юристов × 2 часа в месяц × 3000 руб/час = 408 000 руб/мес) и выдала мне премию.

Мониторинг, который стоит настроить

• qps (запросов в секунду) по каждому узлу. Резкий рост — признак проблем на другом узле (трафик перешёл).
• Среднее время резолва. Рост на 30%+ — начинает тормозить Recursor или upstream.
• Состояние BGP-сессий. Если peer Established → Idle — есть проблема с маршрутизатором или сетью.
• Cache hit ratio на Recursor. Меньше 60% — пора увеличивать размер кэша.
• NXDOMAIN rate. Резкий рост — попытки резолва вредоносных доменов (malware в сети) или ошибка в зонах.

FAQ — Anycast DNS

Зачем среднему бизнесу Anycast DNS, если Yandex.Cloud даёт DNS-as-a-service?

Облачные DNS хороши для публичных зон. Для внутренней инфраструктуры (1С, AD, внутренние сервисы) нужен собственный DNS с полным контролем. Anycast на двух-трёх узлах даёт отказоустойчивость без зависимости от облака и быстрое резолв для удалённых офисов.

Нужен ли реально BGP или можно обойтись keepalived?

Keepalived работает в рамках одного broadcast-сегмента L2. Если у вас офисы в разных дата-центрах или разных городах — нужен BGP. Для одного офиса на 30-50 машин с двумя DNS на одном VLAN keepalived хватит, но масштабировать на Хабаровск не получится.

Что делает OctoDNS в связке с PowerDNS?

OctoDNS превращает DNS-зоны в код. Мы храним зоны в git, OctoDNS сравнивает текущее состояние на PowerDNS с YAML-файлами в репозитории и применяет разницу. Преимущества: code review, аудит изменений, откат в один коммит, автоматизация через GitLab CI.

Что такое health check для DNS и как его делать?

Демон на каждом узле периодически делает запрос к локальному PowerDNS (dig @127.0.0.1 SOA example.ru). Если ответа нет или SERVFAIL — останавливает анонс BGP-маршрута (withdraw). Можно использовать keepalived с script-check или собственный скрипт с frr vtysh. Мы предпочитаем второй вариант — прямое управление BGP.

Сколько стоит настройка Anycast DNS для компании из 3 офисов?

Базовая инсталляция — 3 Linux-сервера (по одному на офис или в дата-центре), BGP-пиринг с провайдером, PowerDNS, health checks, GitLab CI и OctoDNS — от 210 000 руб. за настройку. Плюс единоразово PI-сеть в RIPE и регистрация AS — 500-1200 евро. Окупается на первом инциденте с недоступностью DNS.