Заметка для платформенных инженеров, которым в одном ревью нужно подписать и кросс-региональный SSH, и крупные бинарные загрузки. Она дополняет широкую матрицу PoP в материале GeoDNS, задержка SSH и региональная приёмка (2026), углубляясь в поведение резолверов, выбор типов записей и чеклист приёмки p95 для обратной вытяжки артефактов. Начните с русской главной vpshalo или откройте региональные витрины: японская, корейская, упрощённый китайский, традиционный китайский (Тайвань), немецкая, французская и английская — затем сверьте DNS и мониторинг с таблицами ниже.
Матрица: split-horizon и GeoDNS
Split-horizon DNS отдаёт разные ответы внутри корпоративной сети (или CI-VPC) и в публичном интернете. GeoDNS (часто с учётом EDNS Client Subnet) направляет публичных клиентов к региональной цели по подсказкам резолвера и весам политики. Один другого не заменяет: split-horizon снимает неоднозначность для автоматизации; GeoDNS удобен для людей и ноутбуков за одним брендовым hostname.
| Измерение | Split-horizon (внутренний вид) | GeoDNS (публичный вид) |
|---|---|---|
| Главный выигрыш | Детерминированные цели CI и раннеров | Низкое трение: одно глобальное имя для людей и ноутбуков |
| Позиция по TTL | Часто 300–3600 с; можно агрессивнее — вы контролируете резолверы | Короче в окнах изменений (60–300 с); дольше в стабильном режиме (600–1800 с) |
| Риск липкости кэша | «Липкие» форвардеры или прозрачные DNS-прокси в офисах | Кэши ISP и публичных рекурсивов без ECS; устаревшие континентальные карты |
| История рукопожатия SSH | Jump-хосты и бастионы 1:1 к идентификаторам PoP | Рукопожатие следует за тем, что закэшировал резолвер; валидируйте по рынкам |
| Источник артефактов | Проще привязать registry.internal к региональным VIP |
Нужны ALIAS/ANAME или правила apex; следите за расхождением dual-stack CDN |
| Типичный отказ | Дрейф между внутренним каталогом и публичным маркетинговым DNS | Частичное управление при перекрытии TTL; «дребезг» health checks |
Типы DNS-записей: исполняемый справочник
Берите минимальный набор записей, при котором failover возможен без переименования hostname. Стабильные «владельцы» вроде ssh-asia.prod.example и CNAME-индирекция для сервисов, которые мигрируют между облаками; apex оставляйте на ALIAS/ANAME провайдера или «сплющенных» A/AAAA.
| Запись | Типичная роль | Когда выбирать |
|---|---|---|
| A / AAAA | SSH-бастионы, legacy VPN, «голые» edge | Минимум индирекции; обе семьи для dual-stack Mac-сборщиков |
| CNAME | Псевдонимы сервисов на взвешенные цели или hostname CDN | Не на apex, если нет flattening у DNS-провайдера |
| ALIAS / ANAME (vendor) | Apex на динамические цели (пулы GeoDNS, управляемые шлюзы) | Корень маркетингового домена с меняющимся набором PoP |
| SRV | Обнаруживаемый SSH или внутренний gRPC, если клиенты умеют | Удобно для каталогов автоматизации; многим SSH-клиентам нужны обёртки |
| TXT | Владение доменом, ACME, canary-токены | Коротко; не складывайте операционное состояние в TXT |
| NS / делегирование | Дочерние зоны по регионам | Когда юридика или биллинг требуют разных владельцев SOA |
Диапазоны TTL и пробы липкости кэша
TTL — не «скорость обновления DNS по миру»: это верхняя граница времени жизни ответа в рекурсивном кэше, который уважает TTL. Липкость добавляют пулы соединений приложений, happy eyeballs и CDN, которые «пришивают» вас к edge-PoP. Считайте одной метрикой пару «TTL + наблюдаемый остаточный TTL».
| Фаза | Рекомендуемый TTL | Зачем |
|---|---|---|
| Стабильный прод | 600–1800 с для региональных A/AAAA; 300–900 с для быстро меняющихся пулов | Меньше шума на резолверах, но правки в тот же день ещё возможны |
| Плановая миграция | Заранее снизить до 60–120 с на срок не меньше прежнего TTL | Большинство кэшей успевает обновиться до cutover |
| Аварийный откат | 30–60 с только при автоматизации с health checks | Короткий TTL множит QPS — следите за лимитами авторитативных серверов |
| Внутренний split view | 300–3600 с с привязкой к DHCP-арендам | Согласовать с кэшем кампусных форвардеров; описать пути override |
# Публичный и внутренний ответ (подставьте HOST)
dig +ttlunits A ssh.example.com @8.8.8.8
dig +ttlunits A ssh.example.com @10.0.0.2 # пример корпоративного резолвера
# Цепочка с учётом CNAME / flattening
dig +trace +ttlunits A ssh.example.com
# «Липкость» HTTPS edge: DNS, TCP, TLS, TTFB — повторить с двух ISP
curl -sS -o /dev/null -w 'dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer}\n' \
https://registry.example.com/v2/dig) вместе с SSH- и HTTP-пробами. Если после «зелёного» DNS в Сеуле по-прежнему виден Вирджиния, чаще виновата липкость кэша, а не BGP.Пробы кросс-регионального рукопожатия SSH
SSH добавляет обмен ключами и проверку host key поверх TCP. Для сессий на удалённом Mac измеряйте настенные часы от SYN до первого удалённого приглашения, а не только ICMP. Гоняйте пробы и из подсетей CI, и из «домашних» сетей разработчиков: GeoDNS между ними может расходиться.
- Бюджет рукопожатия: ведите p50 / p95 для
time ssh … exit; алерт, если p95 для пары PoP вырос на 40 % неделя к неделе. - Ключи: в автоматизации —
-o BatchMode=yes; host key стабилен на PoP, чтобы не «дребезжало» доверие. - MTU / VPN: повторите пробы в split-tunnel VPN; при black hole только на шифрованном пути — clamp MSS.
# Настенные часы SSH (read-only учётка автоматизации)
for i in $(seq 1 30); do
/usr/bin/time -p ssh -o BatchMode=yes -o ConnectTimeout=12 \
-o StrictHostKeyChecking=accept-new user@HOST 'exit' 2>&1 | awk '/^real/{print $2}'
sleep 1
done | sort -n | awk 'NR==1{min=$1} {sum+=$1; a[NR]=$1} END{
print "samples:", NR, "min:", min, "max:", a[NR], "p95:", a[int(0.95*NR)] }'
# Подробный OpenSSH один раз на окно изменений (ключи в лог не класть)
ssh -vvv -o BatchMode=yes user@HOST true 2>&1 | tee /tmp/ssh-trace.txtОбратная вытяжка артефактов: чеклист приёмки по p95
Слои контейнеров, бинарные артефакты SwiftPM и объекты Git LFS нагружают DNS иначе, чем один SSH: много параллельных HTTPS, range-запросы и редиректы CDN. Подписывайте сквозной p95 с NIC сборщика, а не только дашборды CDN.
| Проверка | Критерий прохода (staging → prod) | Идея пробы |
|---|---|---|
| DNS совпадает с PoP | ≥ 99 % джоб в стабильном режиме резолвятся в региональные цели | Лог getent / вывода резолвера в начале джобы; сверка с allow list |
| TLS и глубина редиректов | ≤ 2 HTTP-редиректа; p95 установки TLS ≤ 250 ms внутри региона | Шаблон curl -w выше с -L --max-redirs |
| Нижняя граница скорости | p95 времени вытягивания фикстуры 500 МБ ≤ базовая линия команды × 1,25 | Отдельная джоба в пайплайне; архивировать тайминги в observability |
| Range / докачка | Обрыв не требует полной перекачки | Kill посреди передачи; сверить byte ranges в access logs |
| Учения failover | После окна TTL ≥ 95 % джоб берут вторичный origin без ручного /etc/hosts | Смена весов записи + синтетический canary-регион |
| Паритет IPv6 | Путь AAAA не медленнее только-A более чем на 20 % по p95 | Парный прогон curl с -4 и -6 |
Когда матрица, план TTL и чеклист p95 сходятся, поднимайте сборщиков в том же метро, что и зеркала реестра: DNS и «гравитация» бинарников переезжают синхронно. У vpshalo — помесячная ёмкость удалённого Mac в нескольких регионах: выберите PoP под политику резолверов и источник артефактов.