Anycast не делает DNS «магическим»: разберем мифы и реальные риски

Anycast не делает DNS «магическим»: разберем мифы и реальные риски

Anycast решает задачу маршрутизации к ближайшему узлу, но не отменяет физику сети и ошибки в эксплуатации. Распространённый миф: если префикс анонсируется везде, отказа не будет. На практике сбой может затронуть один POP, а клиент всё равно увидит деградацию из-за BGP-конвергенции, потери state на промежуточных устройствах и кривой фильтрации у провайдера.

Давайте разберем флоу запроса. Клиент идёт к адресу, который выбирается маршрутизацией, а не «умным» DNS-решателем. Если анонс ушёл, трафик переедет на следующий доступный узел; если анонс остался, но backend на месте сломан, Anycast честно доставит запрос в поломку. Отсюда правило: health-check должен не только снимать анонс, но и проверять реальную готовность сервиса. ⚙️

Ещё один миф: Anycast автоматически уменьшает RTT. Иногда да, иногда нет. При неудачной политике маршрутизации клиент может попасть не в ближайший, а в «удобный» для аплинка узел. Проверим влияние на RTT и консистентность зон: latency без контроля распределения трафика превращается в лотерею, а рассинхрон данных — в тихую проблему, которую заметят уже пользователи.

Стабильность DNS — это фундамент, а не опция. Anycast работает хорошо только там, где есть строгая синхронизация зон, отказоустойчивый контроль анонсов и понятная деградация при частичном отказе. Исключаем Human Error через автоматизацию: один и тот же policy для анонсов, health-check и деплоя конфигурации.