GeoDNS: один сайт для России и всего мира

/// <reference types="@bunny.net/scriptable-dns-types" />
// GeoDNS: Россия и Беларусь — на сервер в Петербурге, остальные — в Хельсинки.
const RU_IP = "203.0.113.10";      // сервер в Петербурге — впишите свой
const WORLD_IP = "198.51.100.20";  // сервер в Хельсинки — впишите свой
const RU_COUNTRIES = ["RU", "BY"];
const TTL = 60;                    // секунд: столько резолверы помнят ответ

/** @param {DnsRequest} query */
export default function handleQuery(query) {
  const req = query.request;

  // Страна посетителя. Google DNS и часть других резолверов присылают
  // подсеть посетителя (EDNS Client Subnet) — по ней точнее.
  let country = req.geoLocation.country;
  if (req.ednsIP && req.ednsIP !== "0.0.0.0") {
    country = GeoDatabase.resolve(req.ednsIP).country;
  }

  const home = RU_COUNTRIES.indexOf(country) !== -1 ? RU_IP : WORLD_IP;
  const spare = home === RU_IP ? WORLD_IP : RU_IP;

  // Свой сервер лежит, а второй жив — отправляем на второй.
  if (!Monitoring.getStatus(home).isOnline && Monitoring.getStatus(spare).isOnline) {
    return new ARecord(spare, TTL);
  }
  return new ARecord(home, TTL);
}

Домен: <site.ru>. Сайт сейчас: <где лежит и на чём собран: статика / Next.js / WordPress / другое>.
Серверы: Россия <IP_RU> (ssh <алиас или user@IP>), за рубежом <IP_WORLD> (ssh <алиас или user@IP>).
Запасной домен: <site-ru.ru>, DNS у регистратора <название>. Ключ API Bunny лежит в <путь к .env> — в чат его не выводи.

Ты — администратор Linux. Собери GeoDNS: один домен, две одинаковые копии сайта; посетители из России и Беларуси — на российский сервер, остальные — на зарубежный. Делай сам, спрашивай меня только то, без чего не обойтись. Перед необратимыми шагами (смена NS у регистратора, отключение старого хостинга) остановись и спроси.

ШАГИ
1. Разведка. Опиши, как устроен сайт: статика или CMS с базой, где формы и куда уходят заявки. Сними снимок текущей зоны DNS: A, AAAA, CNAME, MX, TXT, CAA, NS — для корня, www и всех известных поддоменов, каждый тип отдельным запросом (ANY не используй). Сохрани снимок в файл. Покажи мне план до того, как что-то менять.
2. Копии сайта. На обоих серверах — одинаковая ОС и веб-сервер (Caddy или nginx). Файрвол пускает SSH, 80, 443 и ping.
   - Статика: сборка один раз, выкладка на оба сервера одним скриптом deploy-both.sh; в конце скрипт сравнивает хэши файлов на обоих серверах, расхождение — ошибка выкладки.
   - CMS с базой: основная база и админка — только на российском сервере, на зарубежном — копия только для чтения (репликация базы или выгрузка по расписанию, загрузки — rsync). Вариант предложи мне до того, как делать.
3. Заявки. Формы с обоих серверов пишут в одну базу на российском сервере или в российскую CRM: по 152-ФЗ персональные данные граждан России записываются в базу на территории России. Зарубежный сервер пересылает заявку на российский; если тот недоступен — держит её в очереди и досылает.
4. Сертификаты. Let's Encrypt проверяет домен со своих точек за рубежом и по GeoDNS попадёт на зарубежный сервер, поэтому HTTP-проверка на российском не пройдёт. На ОБОИХ серверах выпускай сертификат через DNS-проверку по API Bunny: Caddy с модулем caddy-dns/bunny или acme.sh с dns_bunny. Ключ — в .env с правами 600.
5. Зона в Bunny. Создай зону и перенеси ВСЕ записи из снимка шага 1. Скрипт GeoDNS возьми с vasinki.ru/guides/geodns/, впиши мои IP, опубликуй и привяжи записью Script к корню и www.
6. Проверка до смены NS. Спрашивай Bunny напрямую с подсетью: dig +short @kiki.bunny.net <домен> A +subnet=77.88.8.0/24 должен вернуть IP_RU, с +subnet=8.8.8.0/24 — IP_WORLD. Проверь AAAA: ответ пустой или правильный IPv6; если на AAAA-запрос приходит A-запись — заведи IPv6 на обоих серверах и отвечай AaaaRecord по request.queryType. Сверь почтовые и TXT-записи со снимком.
7. Смена NS. Скажи мне, что поставить у регистратора: kiki.bunny.net и coco.bunny.net. Дождись, пока dig NS покажет Bunny с нескольких публичных резолверов.
8. Запасной вход. Запасной домен — с DNS у российского регистратора, НЕ в Bunny и НЕ поддоменом основного: поддомен резолвится через те же NS. A-запись — на российский сервер, сертификат — обычной HTTP-проверкой. На всех страницах canonical — абсолютный адрес основного домена; если сейчас он относительный, исправь. В sitemap — только адреса основного домена.
9. Проверка по-настоящему. Через Globalping (api.globalping.io, без токена) из России, Беларуси, Германии и США: DNS-ответ (кто какой IP получил) и HTTP 200 главной и одной глубокой страницы. Сравни HTML с обоих серверов: curl -s --resolve <домен>:443:<IP> https://<домен>/ | sha256sum — запускай с сервера, не с моего компьютера: под VPN --resolve может показать не тот сервер. Проверь сертификаты на обоих IP.
10. Отказ. Останови веб-сервер на зарубежном, подожди 2 минуты, повтори dig с +subnet=8.8.8.0/24 — должен прийти IP_RU. Верни сервер. То же для российского.
11. Отчёт мне: схема, где что лежит, одна команда выкладки на оба сервера, как проверить, что копии не разъехались, что делать, если заблокируют Bunny.

ПРАВИЛА
- Ключи, пароли и токены в чат не выводи — только пути к файлам.
- Выкладка всегда на оба сервера сразу. Копия, отставшая на одну статью, — ошибка: Яндекс и Google увидят разные сайты.
- До шага 7 работающий сайт не трогай без моего согласия.
- Всё, что запускал для проверки, за собой гаси.

# Россия → должен прийти IP Петербурга
dig +short @kiki.bunny.net site.ru A +subnet=77.88.8.0/24
# США → должен прийти IP Хельсинки
dig +short @kiki.bunny.net site.ru A +subnet=8.8.8.0/24

# Копии одинаковые: хэши главной с обоих серверов совпадают
curl -s --resolve site.ru:443:<IP_RU> https://site.ru/ | sha256sum
curl -s --resolve site.ru:443:<IP_WORLD> https://site.ru/ | sha256sum