Как split-horizon DNS позволяет одному имени возвращать разные адреса клиентам из разных сетей?
Split-horizon DNS использует разные DNS-зоны или наборы записей для разных источников запросов. Поэтому одно и то же имя может разрешаться во внутренний адрес для клиентов приватной сети и во внешний адрес для клиентов из интернета.
Изначально DNS обычно публиковал единый набор записей, доступный всем клиентам. Такой подход неудобен для сервисов, которые должны быть доступны и из интернета, и внутри инфраструктуры: внутренний трафик начинает идти через внешний адрес, усложняется контроль доступа и может появиться лишняя задержка.
Разделение DNS-представлений возникло как способ сохранить единое доменное имя для приложения, но направлять клиентов по разным сетевым маршрутам. В облачной инфраструктуре это особенно полезно для приватных конечных точек, внутренних балансировщиков и сервисов, доступных через VPN или выделенные соединения.
Пусть имя api.example.com должно использоваться и внешними клиентами, и приложениями внутри виртуальной сети. Внешнему клиенту нужен публичный адрес, а внутреннему — приватный адрес, чтобы запрос не покидал сеть и не зависел от доступности внешнего маршрута.
Если всем клиентам вернуть только публичный адрес, внутренний трафик может проходить через интернет-шлюз или внешний балансировщик. Это повышает задержку и стоимость, усложняет правила безопасности и иногда делает соединение невозможным из-за отсутствия поддержки маршрута обратно внутрь сети.
Если всем вернуть только приватный адрес, внешние клиенты не смогут подключиться. Ошибочная настройка DNS также может привести к непредсказуемому поведению при миграции, поскольку разные резолверы будут некоторое время использовать разные ответы из-за кэширования.
Для внутренних клиентов настраивают приватное DNS-представление имени, например с записью на приватный адрес балансировщика. Внешний авторитетный DNS продолжает возвращать публичный адрес для того же имени.
Клиент обычно не выбирает нужную зону сам. Он отправляет запрос настроенному DNS-резолверу, а тот определяет, какое представление использовать: по источнику запроса, по подключённой сети, по правилам пересылки или по собственной привязке к приватной зоне.
В облаках это часто реализуется через приватную DNS-зону, связанную с конкретными виртуальными сетями. Резолверы, обслуживающие эти сети, видят приватную запись, а публичные резолверы продолжают получать публичную запись.
Важно различать DNS-маршрутизацию и сетевую маршрутизацию. DNS лишь возвращает адрес; после этого соединение должно быть разрешено таблицами маршрутов, правилами межсетевого экрана, security group или network policy. Приватный ответ сам по себе не создаёт сетевую связность.
Главное ограничение — кэширование. Изменение записи не обязательно сразу увидят все клиенты: результат может сохраняться до истечения TTL, а локальные резолверы и приложения иногда имеют собственные кэши. Поэтому при переключениях заранее уменьшают TTL, учитывая дополнительную нагрузку на DNS.
Ещё один компромисс — сложность диагностики. На разных узлах одно имя законно может разрешаться в разные адреса, поэтому при расследовании нужно проверять источник DNS-запроса, использованный резолвер, полученную запись, TTL и сетевой маршрут.
Компания перенесла внутренние приложения в облако, но сохранила имя payments.example.com. Внешние пользователи должны обращаться к публичному балансировщику, а серверы обработки платежей внутри виртуальной сети — к его приватному варианту.
Рассматривались два варианта. Первый — использовать для всех клиентов публичный адрес: это проще, но создаёт зависимость от внешнего маршрута и может потребовать разрешать внутренний трафик через пограничную инфраструктуру. Второй — выдать всем приватный адрес: это уменьшает поверхность доступа, но ломает подключение внешних клиентов.
Выбрали split-horizon DNS: приватную зону связали с виртуальной сетью, а публичную запись оставили во внешнем DNS. В результате внутренние запросы пошли по приватному маршруту, внешние сохранили доступ через публичный балансировщик; при этом правила доступа к обоим адресам настроили отдельно.
1. Что произойдёт, если клиент из приватной сети использует внешний DNS-резолвер?
Он может получить публичный адрес, потому что внешний резолвер не видит приватную DNS-зону. Тогда split-horizon не сработает для этого клиента, даже если сетевой маршрут до приватного адреса существует. Нужно обеспечить использование корпоративного или облачного резолвера, настроить DNS-пересылку либо явно организовать доступ к нужному представлению зоны.
2. Достаточно ли вернуть внутренний адрес, чтобы соединение гарантированно заработало?
Нет. После DNS-разрешения клиент должен иметь маршрут до адреса, а промежуточные устройства и правила безопасности должны разрешать нужный протокол и порт. Дополнительно балансировщик или сервис должен принимать соединения из этой подсети; DNS не проверяет доступность приложения и не заменяет health check.
3. Почему после изменения DNS часть клиентов продолжает обращаться к старому адресу?
Потому что DNS-ответы кэшируются на рекурсивных резолверах, операционных системах и иногда внутри приложений. Пока не истечёт соответствующий TTL, клиент может законно использовать старый адрес. Поэтому миграцию планируют с учётом времени жизни кэшей, проверяют фактические ответы из разных сетей и не рассчитывают на мгновенное переключение после изменения записи.