Гео-маршрутизация и failover для трекера: как это работает и как настроить

Трафик в трекер приходит не «в трекер» — он приходит на tracking-домен, и первым на запрос отвечает DNS. Значит, маршрутизацию по странам и отказоустойчивость дешевле всего решить именно здесь: до HTTP, до клоакинга, до приложения. Если узел лёг — резолвер отдаёт другой IP, а ссылки в источниках остаются теми же. Если ГЕО нужно другое — меняется одна запись, а не вся кампания.

Ниже — как это устроено в DNS-платформе MTA.LAB: четыре режима правил, генерация Lua-строк, настройка через UI и API, проверка через dig и чек-лист, который закрывает 90% проблем.

Зачем маршрутизировать на уровне DNS

• Мульти-ГЕО лендинги. Один tracking-домен отдаёт разным странам разные IP: ближе по сети, проще разделить потоки, меньше зависимость от одного сервера.
• Скрытие трекера за гео-A-записью. «Белым» резолверам уходит спокойный IP (заглушка или лендинг), рабочий узел виден только нужной гео-ветке. Адрес трекера не светится в общих списках и сканерских выгрузках.
• Отказоустойчивость. Основной узел недоступен — DNS отдаёт backup. Переключение занимает один TTL, а не часы на правку ссылок в кабинетах источников.
• Скорость. Ответ ближайшего по сети узла снижает время первого байта: у гео-веток задержка меньше на десятки миллисекунд, а на мобильных сетях разница видна в отвалах.

Экономика простая: одна ошибка в A-записи стоит весь трафик по кампании. TTL 60 секунд превращает аварию в минутный простой; TTL 3600 — в часовой.

Как это работает под капотом

Правила хранятся как PowerDNS Lua-записи и выполняются в момент ответа на DNS-запрос. Логика видит запрос и решает, какой IP вернуть. Ключевой момент, вокруг которого потом возникает больше всего вопросов:

Почему так, а не «по-другому»: ECS передают не все резолверы, и решение на его основе получается нестабильным. Привязка к IP резолвера предсказуема: пользователи одного публичного резолвера получают один и тот же ответ. Для лендингов и раздачи ближайших узлов этого достаточно; для тонкого гео-таргета по каждому пользователю — нет, и это надо помнить при планировании.

Второй рычаг — TTL. Он применяется к ответу и определяет, как долго резолверы и клиенты держат кэш. Рабочие диапазоны: 60–120 секунд для failover-веток (быстрое переключение) и 300 секунд для стабильных гео-веток, где важнее меньше запросов. Ниже 60 опускаться стоит только при реальной необходимости.

Четыре режима: когда какой

Режим	Что делает	Когда выбирать	На что смотреть
geo	Ветка по стране или континенту резолвера	Мульти-ГЕО лендинги, разделение потоков, скрытие трекера	Обязательная дефолтная ветка; TTL 300
closest	Возвращает ближайший по сети IP из пула	Один лендинг на нескольких PoP / anycast	Не заменяет failover: ближайший узел тоже может лечь
failover	Health-check primary и выдача backup при падении	Отказоустойчивость трекера и лендингов	TTL 60–120, интервал и таймаут проверки
geo_failover	Гео-ветки, внутри каждой — свой health-check	Мульти-ГЕО + HA одновременно	Вдвое больше проверок; следить за дефолтом

Простое правило выбора: есть гео-условия, но нет требований к доступности — geo. Один пул узлов без гео, но важна доступность — failover. Нужны и гео, и доступность — geo_failover. closest — когда узлов много и они равнозначны.

Примеры сгенерированных Lua-строк

Панель не заставляет писать Lua руками: вы заполняете ветки, а правило собирается само. Ниже — что именно уходит в запись в каждом режиме.

geo — страна резолвера решает, какой IP вернуть:

if country() == "RU" then
  return "1.1.1.1"
end
if country() == "KZ" then
  return "2.2.2.2"
end
-- дефолтная ветка: обязательна
return "9.9.9.9"

closest — выбор ближайшего адреса из пула:

local pool = {"1.1.1.1", "5.5.5.5", "9.9.9.9"}
return pickclosest(pool)

failover — health-check порта, при неудаче отдаётся backup:

if ifportup(443, {"10.0.0.10"}, {timeout=1000, retries=2}) then
  return "10.0.0.10"
end
return "10.0.0.20"

Тот же режим с проверкой URL — полезно, когда приложение живёт на нестандартном порту или нужно проверить сам эндпоинт:

if ifurlup("http://10.0.0.10/healthz", {"10.0.0.10"},
           {timeout=1500}) then
  return "10.0.0.10"
end
return "10.0.0.20"

geo_failover — комбинация: гео-ветка, внутри неё primary/backup, снаружи общий дефолт:

if country() == "RU" then
  if ifportup(443, {"10.0.0.10"}) then return "10.0.0.10" end
  return "10.0.0.20"
end
if continent() == "EU" then
  if ifportup(443, {"10.0.1.10"}) then return "10.0.1.10" end
  return "10.0.1.20"
end
return "9.9.9.9"

Пошаговая настройка

В UI всё живёт на странице зоны — в секции «Гео-маршрутизация и отказоустойчивость». Порядок такой:

API: curl-примеры

Список правил зоны и создание гео-правила:

TOKEN=...; ZONE=go.example.com

curl -s -H "Authorization: Bearer $TOKEN" \
  https://dns.mtalab.cc/api/v1/zones/$ZONE/lua

curl -s -X POST -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"type":"geo","ttl":300,
       "rules":[{"country":"RU","answer":"1.1.1.1"}],
       "default":"9.9.9.9"}' \
  https://dns.mtalab.cc/api/v1/zones/$ZONE/lua

Правка и удаление правила по идентификатору, предпросмотр без сохранения:

curl -s -X PUT -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"ttl":60,"enabled":true}' \
  https://dns.mtalab.cc/api/v1/zones/$ZONE/lua/<id>

curl -s -X DELETE -H "Authorization: Bearer $TOKEN" \
  https://dns.mtalab.cc/api/v1/zones/$ZONE/lua/<id>

curl -s -X POST -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"type":"geo_failover","default":"9.9.9.9"}' \
  https://dns.mtalab.cc/api/v1/zones/$ZONE/lua/preview

Справочник стран для условий:

curl -s -H "Authorization: Bearer $TOKEN" \
  https://dns.mtalab.cc/api/v1/lua/countries

Проверка через dig

Базовый ответ:

dig @ns1.go.example.com go.example.com A +short

А теперь нюанс, который путает всех. Запрос с подставленным subnet не изменит ответ:

dig @ns1.go.example.com go.example.com A +subnet=5.5.5.5 +short

Проверка failover: остановите приложение на primary (или закройте порт) и повторите dig — после health-check ответ сменится на backup. Время смены = интервал проверки плюс TTL, который держат резолверы.

Чек-лист настройки

Типичные ошибки

Ошибка	Последствие	Как правильно
TTL 3600 на failover-ветке	Резолверы держат упавший IP до часа	60–120 секунд на время активного failover
Забыли дефолт	Часть гео получает NXDOMAIN или пустоту	Дефолтная ветка с рабочим IP всегда
Проверка через +subnet	Ожидание «правильной» страны, которого не будет	Тестировать с узла или резолвера нужного гео
Health-check на URL с самоподписанным сертификатом	Проверка всегда «упала», трафик постоянно на backup	Валидный TLS или проверка порта вместо URL
Primary и backup — один хост	Падение узла = падение обеих веток	Разные машины и сети
Гео «по пользователю»	VPN и публичные резолверы искажают картину	Планировать по гео резолвера, тестировать реальными резолверами
Правка правила без предпросмотра	Сломанная запись на живом домене	preview → сохранение → проверка dig

Смежные темы — в других материалах: как защитить воронку от ботов на уровне трекера — гайд по антибот-фильтрации, а как перевезти кампании без потерь — план переезда на свой трекер.