Anycast не делает DNS «магически быстрым»: мифы ломаются на первом инциденте

Anycast не делает DNS «магически быстрым»: мифы ломаются на первом инциденте

Anycast часто продают как универсальную таблетку: объявил /24 или /48, и сеть сама всё разрулит. На практике она решает только одну задачу — доставить запрос до ближайшей живой точки входа по BGP. Дальше начинается обычная инженерия: ёмкость, health-check, синхронизация зон и контроль отказов.

Давайте разберем флоу запроса. Клиент идёт к anycast-адресу, маршрутизация выбирает ближайший префикс, а сервер обязан:
— быстро ответить на UDP;
— корректно пережить потери узла без «долгого хвоста»;
— не развалить консистентность при раскатке изменений.
Если один PoP стал медленным, anycast не исправит RTT внутри него. Он лишь перестанет быть выбранным, когда BGP-сигнал дойдёт до сети.

Главный миф — «anycast снижает нагрузку сам по себе». Нет. Он перераспределяет трафик, но не спасает от перекоса по регионам, кривого маршрута или blackhole при ошибочной анонсации. Второй миф — «достаточно поднять одинаковый конфиг». На деле важны одинаковые ответы, одинаковые таймауты и одинаковая политика отказа; иначе клиент увидит рандом, а не отказоустойчивость. Исключаем Human Error через автоматизацию.

Проверяем влияние на RTT и консистентность зон: анонс должен сниматься быстрее, чем узел начнёт отвечать мусором; health-check — смотреть не только на процесс, но и на реальную способность обслуживать DNS; изменения зон — проходить через предсказуемый pipeline. Стабильность DNS — это фундамент, а не опция.