Anycast не магия: 5 мифов, из-за которых ломают DNS-архитектуру

Anycast не магия: 5 мифов, из-за которых ломают DNS-архитектуру

Anycast ускоряет доставку запросов, но не отменяет физику сети. Да, клиент попадет в «ближайшую» точку, но ближайшая по BGP не всегда ближайшая по RTT. Поэтому сравнивать Anycast и Unicast как «быстро/медленно» — ошибка. Сначала смотрим, как анонсы выбираются, потом — что делает резолвер и где находится реальный узел.

Миф 1: один IP решает все. На практике Anycast требует строгой идентичности конфигурации, данных и policy на всех нодах. Иначе получите расхождение ответов при одинаковом адресе — и привет, недетерминированность. Миф 2: отказ одной ноды незаметен. Если health-check и withdrawal анонса сделаны грубо, часть трафика еще какое-то время будет идти в пустоту. Здесь важны таймеры, graceful withdrawal и понимание convergence.

Миф 3: Anycast сам балансирует нагрузку. Нет. Он распределяет по маршрутам, а не по CPU, QPS или размеру ответов. Без планирования capacity можно получить перегрузку «ближайшего» POP и простую схему с очень дорогим RTT. Проверим влияние на RTT и консистентность зон: логика выдачи должна быть одинаковой, а наблюдаемость — по каждому узлу отдельно.

Практика простая: Anycast работает там, где вы готовы управлять BGP, health-checks, синхронизацией зон и деградацией как штатным сценарием. Стабильность DNS — это фундамент, а не опция.