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.