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

Привет! Я Евгений Семёнов, директор ITFresh. Представьте такую картину: сентябрь 2025 года, у нашего клиента – крупной торговой сети с московским офисом и пятью магазинами по Подмосковью – полнейший коллапс. Их единственный DNS-сервер в центральном офисе буквально «заснул» на 4 часа. И что произошло? Вся работа встала! 1С, почта, внутренний портал, даже корпоративный WiFi с 802.1X – ничего не функционировало. А уж про кассы в магазинах и говорить нечего. Почему? Да просто никто не мог резолвить хосты Active Directory. Мы не стали мириться с этим. Уже спустя неделю мы внедрили им 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, автоматически подключаются к ближайшему – и, что самое главное, *рабочему* серверу. Если один из узлов вдруг выйдет из строя? Никаких долгих ожиданий – трафик моментально, буквально за секунды, переключается на другой доступный сервер. И никто ничего не замечает!

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

Как выглядит типовая архитектура для компании с тремя офисами? Покажем:

• Вам понадобится три 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 секунд клиенты переходят на другой узел.

Все DNS-зоны – включая A, AAAA, MX, SRV, CNAME, TXT – мы храним в git-репозитории, причём не просто так, а в удобном формате YAML. Затем в игру вступает OctoDNS: эта система считывает файлы и мгновенно, через API, синхронизирует их с базой PowerDNS. Как вносятся изменения? Строго через pull request! Как только PR принят (произошёл merge), тут же стартует процесс CI, который применяет все новшества сразу на *всех* наших узлах. Полный контроль, никаких сюрпризов.

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

BIND? Да, когда-то он был королём DNS, настоящий исторический лидер! Но, честно говоря, он довольно тяжёл в администрировании и совсем не дружит с современными инструментами IaC. Пять лет назад это ещё можно было стерпеть, но сегодня мы крайне редко его используем.

dnsmasq – прекрасное решение для домашней сети или маленького офиса, где хватает IoT-роутера. Но для *боевого* DNS в серьёзном бизнесе? Однозначно нет, это просто не его уровень. У него нет полноценной схемы master/slave, никакого API, а поддержка DNSSEC, на наш взгляд, оставляет желать лучшего. Не рискуйте.

А вот PowerDNS — это уже совсем другая история! Здесь мы видим идеальное разделение: есть Authoritative-часть, отвечающая за наши собственные DNS-зоны, и Recursor, который занимается резолвом запросов к чужим. Что ещё? У него превосходный HTTP API и поддержка огромного количества бэкендов – хотите MySQL, PostgreSQL, SQLite, LDAP? Да хоть обычный BIND-файл! И работает, между прочим, невероятно быстро: десятки тысяч запросов в секунду (qps) выдаёт даже на самой скромной виртуальной машине. Мы им очень довольны.

Для бизнеса я ставлю 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, если нужно общаться с провайдером. Главная фишка в том, что мы можем анонсировать один и тот же IP-префикс сразу из нескольких географических точек.

Если говорим о внутреннем анонсе – то есть между офисами вашей же компании – то вполне хватит 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 для ваших клиентов, например, если вы провайдер или хостер – тогда придётся попотеть. Это потребует регистрации автономной системы (AS) в RIPE NCC и получения подсети Provider Independent (PI). Для среднего бизнеса такие сложности – откровенный оверкилл. Проще и дешевле купить внешний DNS у проверенных игроков вроде Яндекса или Selectel, поверьте.

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

Представьте ситуацию: узел DNS исправно анонсирует IP, но сам PowerDNS на нём уже «мёртв». Что произойдёт? Клиенты всё равно будут продолжать стучаться в эту закрытую дверь! Почему? Потому что BGP не видит, что происходит *внутри* узла. Нам критически необходим внешний механизм контроля, который вовремя «отключит» анонс, если сервис вдруг перестанет работать.

Вот первый вариант решения проблемы: можно использовать простой скрипт в 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

Или вот второй вариант: настроить BFD-сессии между DNS-узлом и роутером. Это, безусловно, более элегантное и корректное решение. Но есть одно «но»: оно требует поддержки BFD на обеих сторонах. Хорошая новость – в Mikrotik ROS 7+ и FRR это отлично работает.

Третий подход: вместо полного «отзыва» маршрута мы можем просто «понизить его приоритет». Как это делается? Меняем AS-path prepend, и трафик плавно, без рывков, перетекает на другой узел. Такой способ особенно хорош для плановых работ, когда нужно аккуратно вывести узел из ротации.

IaC через OctoDNS + GitLab CI

Знаете, почему хранить DNS-зоны в 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 (Merge Request), а в Job plan чётко видит, что изменится — ну, например, "будет добавлена запись A 10.10.0.77 для web-new". Коллега спокойно всё ревьюит, утверждает, и после мержа изменения автоматически раскатываются на все узлы через API PowerDNS. А если вдруг что-то пошло не так? Откатить изменение — проще некуда, просто делаем revert commit.

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

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

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

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

И каков же результат, всего через три месяца? Фантастика! Один из узлов, тот самый, что в Рязани, внезапно «упал» — диск дал сбой. Но что самое потрясающее — клиенты компании этого даже не заметили! Весь трафик автоматически перенаправился на серверы в Калуге и Москве. В итоге 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.