В облачной инфраструктуре DNS управляет не только именами, но и косвенно реальным маршрутом трафика. Один и тот же app.example.com может вести внешнего пользователя на публичный балансировщик, а сервис внутри VPC или VNet — на приватный endpoint. Поэтому DNS нужно проектировать не от записи, а от вопроса: кто делает запрос и какой адрес должен получить в ответ.
Базовая модель такая:
- Public DNS обслуживает внешний контур: пользователей, партнёров, публичные API, CDN и внешние балансировщики.
- Private DNS zones обслуживают внутренние сети: VPC, VNet, project network, гибридные подключения, приватные базы данных и внутренние сервисы.
- Split-horizon DNS позволяет одному имени отдавать разные ответы в зависимости от источника запроса: снаружи — публичный endpoint, внутри — приватный.
- TTL задаёт, как долго DNS-ответ может жить в кэше. Это компромисс между скоростью изменений и стабильностью кэша.
- DNS failover переключает новые DNS-запросы на резервный endpoint, но не работает как мгновенный рубильник.
Главный риск в том, что DNS-ответ зависит не только от записи в зоне. На результат влияют источник запроса, привязка private zone к сети, рекурсивный резолвер, кэш ОС, кэш приложения, TTL и состояние сервиса. Поэтому проверка DNS с ноутбука разработчика не доказывает, что тот же ответ получит pod в Kubernetes, VM в приватной подсети или сервис из гибридной сети.
TTL тоже нельзя воспринимать как гарантированное время переключения. Если запись долго жила с TTL 3600, снижение TTL до 60 секунд прямо перед аварией не очистит уже существующие кэши. Низкий TTL помогает быстрее вытеснять старые ответы у корректных клиентов, но увеличивает число DNS-запросов и не управляет уже открытыми соединениями.
DNS failover полезен как часть отказоустойчивости, но не заменяет DR-план. Он может изменить ответ для новых разрешений имени, но не восстановит данные, не выполнит репликацию, не гарантирует RPO/RTO и не закроет проблемы приложения. Для критичных систем DNS должен быть одним из слоёв общей схемы восстановления: вместе с балансировщиками, health checks, репликацией данных, процедурами переключения и регулярными тестами.
Зачем проектировать DNS от источника запроса
В простой инфраструктуре DNS часто воспринимают как справочник: есть имя — есть IP-адрес. В облаке эта модель быстро становится слишком узкой. У компании может быть публичный API, внутренние сервисы в VPC или VNet, приватные базы данных, несколько регионов и гибридное подключение к офисной или дата-центровой сети.
В такой среде DNS начинает влиять на маршрут трафика. Один и тот же FQDN может быть виден по-разному из интернета, из приватной подсети, из Kubernetes-кластера или из гибридной сети. Ошибка в зоне, привязке private DNS или TTL может отправить сервис не к тому endpoint, увеличить задержку, открыть лишний публичный маршрут или сломать failover.
Поэтому проектирование стоит начинать не с выбора записи A, CNAME или Alias, а с базовой модели разрешения имени: кто делает DNS-запрос, через какой резолвер он проходит, какая зона должна ответить и какой endpoint считается правильным.
Public DNS и private DNS: кто спрашивает и какой endpoint получает
После вводной главный вопрос в Cloud DNS звучит не “как называется зона”, а “откуда пришёл запрос”. DNS-имя само по себе не определяет маршрут. Один и тот же FQDN может дать разные ответы в зависимости от того, какой резолвер обрабатывает запрос: публичный DNS из интернета или приватный резолвер внутри VPC, VNet либо гибридной сети.
Public DNS: внешний клиент получает публичный endpoint
Для интернет-пользователя www.example.com обычно должен вести на публичную точку входа: CDN, CNAME внешнего сервиса, публичный IP или публичный балансировщик. Такой ответ отдаёт public DNS zone, доступная из интернета.
Internet user
→ recursive resolver
→ public DNS zone
→ public endpoint / CDN / public load balancer
Это внешний контур. Его задача — правильно направить пользователей, партнёров и внешние системы к публичному приложению или API.
Private DNS: внутренний сервис получает private endpoint
Другой пример — db.internal.example.com. Это имя не нужно внешнему пользователю. Его запрашивает VM, контейнер, Kubernetes workload или внутренний сервис в VPC/VNet.
Ответом обычно будет private IP базы данных, приватный балансировщик, внутренний API или адрес для service discovery. Такой ответ отдаёт private DNS zone, связанная с конкретными сетями.
Service in VPC
→ cloud/private resolver
→ private DNS zone
→ private IP / private load balancer
Отсюда важное практическое следствие: проверка DNS с ноутбука разработчика не доказывает, что сервис внутри VPC получит тот же ответ. Запросы идут через разные резолверы и могут попадать в разные зоны. Поэтому DNS нужно проверять из того окружения, где реально работает клиент: из браузера внешнего пользователя, из контейнера приложения, с VM в нужной подсети или из подключённой гибридной сети.
Как не смешивать public, private и split-horizon
Чтобы не путать модели DNS-разрешения, их удобно сравнить по источнику запроса и типу endpoint:
| Подход | Кто делает запрос | Какой endpoint возвращается | Основной риск |
| Public DNS | Пользователь или внешний сервис из интернета | Публичный IP, CDN, CNAME, публичный балансировщик | Направить внешний трафик не туда или раскрыть лишние публичные имена |
| Private DNS | Сервис внутри VPC/VNet, project network или гибридной сети | Private IP, приватный балансировщик, внутренний API, база данных | Проверить из неправильной сети и получить ложную картину |
| Split-horizon DNS | Внешние и внутренние клиенты для одного FQDN | Разные ответы в public и private контуре | Получить неожиданный ответ из-за неверной зоны или источника запроса |
Public и private DNS решают разные задачи. Первый обслуживает внешний контур, второй — внутренние сети. Private DNS при этом не является полноценной защитой сервиса: он скрывает записи от публичного DNS, но не заменяет IAM, firewall/security groups, сетевые политики и контроль доступа на уровне приложения.
Такое разделение даёт архитектурную ясность: публичные имена ведут к публичным точкам входа, приватные — к внутренним ресурсам. Но в реальных облачных схемах часто нужен единый FQDN для внешних и внутренних клиентов. В этом случае появляется split-horizon DNS: одно имя существует в двух представлениях и возвращает разные ответы в зависимости от того, откуда пришёл запрос.
Split-horizon DNS: одно имя, разные ответы из разных сетей
Как работает split-horizon
Split-horizon DNS, или split-view DNS, означает, что одно полное доменное имя существует в двух представлениях: публичном и приватном. Ответ зависит не от самого имени, а от того, через какой резолвер и какую зону прошёл запрос.
Схема выглядит так:
Internet user
→ public resolver
→ public DNS zone
→ app.example.com
→ public endpoint
Service in VPC/VNet
→ private resolver
→ private DNS zone
→ app.example.com
→ private endpoint
Одинаковый FQDN не означает одинаковый DNS-ответ. Поэтому тестировать нужно не имя само по себе, а имя из конкретного сетевого контура: из интернета, из VPC/VNet, из Kubernetes-кластера, с VM в нужной подсети или из гибридной сети.
Практический пример — SaaS-приложение с именем api.example.com. Снаружи это имя ведёт на публичный балансировщик или CDN. Внутри облака то же имя возвращает адрес приватного балансировщика или внутреннего API. Приложениям удобно: не нужно держать отдельные public-api.example.com и internal-api.example.com, меньше условной логики в конфигурации.
Где split-horizon ломается
Главный риск — пересечение зон. Если private zone не привязана к нужной VPC или VNet, сервис внутри облака может не увидеть приватный ответ и получить публичный endpoint. В гибридной схеме похожая ошибка возникает, когда офисный или дата-центровый резолвер отправляет запрос не в облачный private resolver, а в публичный DNS.
В результате Kubernetes-кластер, CI/CD runner, виртуальная машина и ноутбук разработчика могут видеть разные ответы для одного имени. И каждый ответ будет “правильным” в рамках своего пути разрешения.
Перед вводом split-horizon полезно проверить:
- Из какой сети выполняется DNS-запрос;
- Какая зона должна ответить — public или private;
- Какой endpoint ожидается в ответе;
- Привязана ли private zone к нужным VPC/VNet;
- Нет ли конфликтующей зоны в гибридном DNS;
- Не уходит ли внутренний сервис случайно на публичный endpoint.
Такая проверка снижает риск тихой маршрутизации по неправильному пути. Иначе внутренний сервис может пойти через публичную точку входа: с другой задержкой, лишним исходящим трафиком, другими правилами firewall/security groups, возможными проблемами с сертификатами и доступностью.
Split-horizon решает задачу единых имён, но требует дисциплины в управлении зонами и проверок из разных сетей. Даже когда клиент получает правильный ответ, остаётся следующий вопрос: как долго этот ответ будет жить в кэше и как быстро изменения дойдут до клиентов. Здесь уже важен TTL.
TTL: компромисс между скоростью переключения и стабильностью кэша
TTL — это время жизни DNS-ответа в кэше. Он не означает, что запись “применится у провайдера через 60 секунд”, и не гарантирует, что все клиенты одновременно увидят новый IP. Авторитетный DNS-сервер может уже отдавать новое значение, но рекурсивный резолвер, кэш ОС или кэш приложения ещё могут хранить старый ответ.
Простой пример: api.example.com переводят с одного балансировщика на другой. Если запись несколько часов жила с TTL 3600, снижение TTL до 60 секунд прямо перед переключением не заставит существующие кэши забыть старый адрес. Они уже получили ответ с часовым сроком жизни и будут использовать его до истечения TTL, если ведут себя корректно.
Как выбирать TTL
TTL нельзя выбирать по принципу “чем меньше, тем лучше”. Низкий TTL ускоряет вытеснение старых ответов у корректных клиентов, но увеличивает число DNS-запросов и зависимость от резолверов. Высокий TTL снижает шум и нагрузку, но делает изменения медленнее.
| TTL | Где уместен | Плюс | Ограничение |
| 30–60 секунд | Подготовленные переключения, динамичные записи | Старые ответы живут меньше | Больше DNS-запросов, нет гарантии мгновенного перехода |
| 300 секунд | Многие прикладные сервисы | Баланс между управляемостью и нагрузкой | Изменения всё равно имеют задержку |
| 3600+ секунд | Стабильные и редко меняемые имена | Меньше запросов, стабильнее кэш | Медленные изменения и переключения |
Для критичных изменений TTL нужно снижать заранее. Корректный план выглядит так: сначала уменьшить TTL, дождаться истечения старого высокого TTL, затем изменить запись и проверить разрешение имени из нужных VPC/VNet, гибридных сетей и внешних точек. После стабилизации можно вернуть более высокий TTL для постоянной эксплуатации.
Высокий TTL полезен там, где запись стабильна. Он снижает нагрузку на DNS, уменьшает число внешних зависимостей при повторных обращениях и делает поведение клиентов менее шумным. Поэтому короткий TTL — не универсальное улучшение, а инструмент для записей, где действительно нужна быстрая управляемость.
Почему TTL не равен времени failover
TTL — это настройка компромисса, а не обещание времени восстановления. Он только ограничивает срок хранения ответа у тех участников цепочки, которые соблюдают TTL.
На будущий DNS failover это влияет напрямую: чем выше TTL перед аварией, тем дольше часть клиентов может использовать старую конечную точку. Снижать TTL в момент отказа поздно — старые ответы уже разошлись по кэшам.
Даже низкий TTL не закрывает все задержки. У клиента может быть кэш приложения, кэш ОС, рекурсивный резолвер с собственным поведением и увеличенным TTL или уже открытое соединение к старому endpoint. DNS не отзывает такие соединения и не заставляет приложение мгновенно пересоздать пул подключений.
Поэтому TTL объясняет, почему DNS-изменения имеют инерцию. А DNS failover нужно рассматривать не как мгновенный рубильник, а как механизм, который меняет ответы для новых DNS-запросов с учётом health checks, кэшей и поведения клиентов.
DNS failover: как переключаются новые резолвы и почему это не мгновенно
Как работает DNS failover
Типичный сценарий: api.example.com ведёт на основной балансировщик в us-east, а резервная конечная точка находится в eu-west. Health check фиксирует отказ основного региона, политика маршрутизации срабатывает, и авторитетный DNS-сервер начинает отдавать адрес eu-west.
Упрощённо это выглядит так:
Health check detects failure
→ authoritative DNS returns secondary endpoint
→ new DNS queries go to secondary endpoint
Но переключение увидят прежде всего клиенты, которые делают новый DNS-запрос после изменения ответа. Остальные могут ещё использовать старый кэш или держать открытое соединение к основному endpoint.
Фактическое время переключения складывается из нескольких факторов:
- Обнаружение отказа
- Обновление DNS-ответа
- Срок жизни кэшей
- Поведение клиента
Это не SLA, а модель задержки. Она показывает, почему низкий TTL помогает, но не делает failover мгновенным.
Что остаётся за пределами DNS
DNS не управляет уже открытыми TCP-соединениями, keep-alive, пулами подключений и логикой повторов в приложении. Если клиент держит соединение с основным балансировщиком, он может продолжать пытаться использовать его, пока не сработают тайм-ауты, retries или пересоздание соединения.
Для private endpoints есть отдельное ограничение: внешняя проверка состояния часто не видит private IP внутри VPC или VNet. Поэтому состояние приватного сервиса нужно проверять из доступного ему сетевого контура или передавать наружу через внутренний сигнал состояния.
Из-за этого DNS failover стоит воспринимать как постепенное переключение новых разрешений имени, а не как единое событие для всех клиентов. Он полезен как слой маршрутизации при отказе, но не заменяет балансировщик, retries на уровне приложения и полноценный DR-план.
Заключение
DNS в облачной инфраструктуре нужно проектировать от источника запроса и ожидаемого endpoint. Public DNS обслуживает внешний контур, private zones — внутренние сети, а split-horizon DNS позволяет одному FQDN возвращать разные ответы для разных сетей, но требует точной привязки зон и проверок из реальных окружений.
TTL задаёт инерцию DNS-ответов в кэше, а DNS failover меняет маршрут только для новых разрешений имени. Поэтому для критичных систем DNS должен быть частью общей схемы отказоустойчивости: вместе с балансировщиками, health checks, репликацией данных, RTO/RPO, процедурами восстановления и регулярными тестами.
FAQ
Чем private DNS zone отличается от public DNS zone?
Public DNS zone отвечает на запросы из интернета и обычно возвращает публичный endpoint: CDN, публичный IP, CNAME на внешний сервис или внешний балансировщик. Private DNS zone доступна только из связанных VPC, VNet или гибридных сетей и возвращает внутренние адреса: private IP, приватный балансировщик, внутренний API или endpoint базы данных.
Когда стоит использовать split-horizon DNS?
Split-horizon DNS уместен, когда один FQDN должен работать и для внешних клиентов, и для внутренних сервисов, но возвращать разные endpoints. Например, снаружи api.example.com ведёт на публичный балансировщик, а внутри VPC — на приватный. Такой подход стоит использовать только при контроле зон, сетевых привязок и DNS-проверок из всех важных контуров.
Почему низкий TTL не гарантирует мгновенный failover?
TTL ограничивает срок хранения DNS-ответа у корректных кэшей, но не управляет всеми участниками цепочки. Рекурсивные резолверы, кэш ОС, кэш приложения и уже открытые соединения могут удерживать старое состояние дольше ожидаемого. Поэтому низкий TTL ускоряет вытеснение старого ответа, но не превращает DNS failover в мгновенное переключение.
Какой TTL выбрать для облачного сервиса?
Универсального значения нет. Для изменяемых записей часто используют короткий TTL, например 30–300 секунд, но учитывают рост числа DNS-запросов и зависимость от резолверов. Для стабильных имён можно ставить более высокий TTL, если медленное переключение не нарушает требования к доступности.
DNS failover заменяет load balancer?
Нет. DNS failover меняет ответ для новых DNS-запросов. Load balancer работает с трафиком и backend-пулами уже после того, как клиент получил адрес и начал подключение. В отказоустойчивой архитектуре DNS failover и балансировщик могут дополнять друг друга, но не выполняют одну и ту же функцию.
Что особенно важно для private endpoints при failover?
Health check должен видеть приватный сервис из подходящего сетевого контура. Внешние проверки часто не имеют доступа к private IP внутри VPC или VNet, поэтому нужен внутренний сигнал состояния, метрика, агент в нужной сети или интеграция с облачным мониторингом.
Список источников
1. Google Cloud — Cloud DNS zones overview
2. AWS Route 53 — Considerations when working with a private hosted zone
3. AWS Route 53 — Configuring failover in a private hosted zone
