Содержание статьи

Что такое Split DNS и почему это важно в 2026

Базовое определение и простая метафора

Split DNS это подход, при котором разные домены разрешаются разными DNS-серверами, а маршрутизация запросов к этим серверам зависит от правил, профилей VPN и политик клиента. Представьте швейцара у дверей: к кому гость, туда и пропускаем. Внешние домены идут к публичным резолверам, а внутренние имена компании попадают к приватным корпоративным DNS. В результате мы получаем аккуратное разделение мира, меньше утечек, выше скорость, и контроль, который обеспечивает безопасность. Звучит просто, но дьявол в деталях, а деталей в 2026 стало больше.

Почему этот подход снова в фокусе? Мы массово ушли в гибридные облака, распределили офисы, вписались в Zero Trust, и добавили DoH, DoT и даже DNS-over-QUIC. Старый, плоский DNS не справляется: он либо слишком многое показывает Интернету, либо ломает внутренние имена. Split DNS дает золотую середину. Он словно светофор на сложной развязке: правильная полоса, правильный сигнал, и никто не подрежет. Плюс, он экономит миллисекунды, а иногда и минуты, когда речь о отладке сложных цепочек резолвинга.

Как Split DNS дружит с VPN

Через VPN мы создаем логический туннель. Дальше правила: какой домен резолвится через корпоративный DNS, а какой идет к публичному рекурсору. Обычно мы настраиваем условную переадресацию по списку зон и доменов, например corp.local, int.company, svc.cluster.local, и направляем их к адресам DNS на стороне офиса или облачного хаба. Все остальное идет к провайдеру пользователя или к управляемому DoH резолверу, который вы доверяете.

Плюс важный момент: политика работы клиента. Windows использует таблицы правил (NRPT), macOS и iOS через профили конфигураций направляют домены к определенным резолверам, Android умеет частично разделять трафик с приватным DNS, а Linux с systemd-resolved управляет маршрутом через split domains. Итог понятен: VPN не обязан тянуть весь трафик наружу, он точечно перехватывает нужные домены. Именно это делает Split DNS удобным и для производительности, и для приватности.

Чем Split DNS отличается от Split Tunneling

Путаница номер один. Split Tunneling делит трафик по подсетям или приложениям, частично минуя VPN. Split DNS делит только резолвинг доменных имен, а дальше маршрут может быть любым, в том числе полным туннелем. Мы можем использовать полный VPN-туннель для безопасности, но при этом резолвить внешние домены через публичный DoH. И наоборот, можем разделять трафик, но заставлять весь DNS идти через корпоративный резолвер. Это независимые, хотя и часто сочетающиеся механизмы.

Почему это важно? Потому что вы можете тонко настроить равновесие. Хотите меньше рисков утечки внутренних имен? Резолвите их только через внутренние DNS, а внешние — через DoH поверх туннеля. Хотите выиграть в скорости для YouTube или CDN? Позвольте внешним доменам резолвиться ближе к пользователю, при этом всё чувствительное оставив строго внутри. Гибкость огромная, а выигрыши часто измеряются десятками процентов времени отклика.

Когда Split DNS не нужен

Если у вас нет внутренних доменов, нет частных зон, нет разницы между именами внутри и снаружи, тогда и смысл тащить Split DNS минимален. Как правило, это редкость для компаний, но бывает у микрокоманд, где всё в одном SaaS и никаких внутренних серверов. Еще пример — строго изолированные тонкие клиенты без доступа к Интернету: там разрешение имен полностью внутрь, и разделять нечего.

Но в большинстве реальных организаций 2026 года внутренние имена есть всегда. Это Active Directory, сервисы Kubernetes, сервисы в VPC и VNet, приватные API, внутренние порталы, сервис-дискавери через Consul или Istio. Везде, где есть внутренние зоны, Split DNS помогает. Он сокращает ошибочные резолвы наружу, защищает приватность, и дает прозрачный пользовательский опыт: всё работает невидимо, без танцев с переносом записей в hosts.

Архитектура Split DNS: кирпичики, из которых все строится

Роли DNS-серверов: внутренний, внешний и рекурсор

В архитектуре Split DNS всегда минимум два типа резолверов: внутренние (авторитативные для приватных зон и часто рекурсор для внутренних хостов) и внешние (публичные рекурсоры или авторитативные для ваших публичных зон). Иногда добавляется третий уровень — граничные резолверы в облаке, выступающие как кэш и распределитель. Такая ступенчатая схема уменьшает задержки и снижает нагрузку на магистраль.

Внутренние DNS знают ваши приватные зоны: например corp.local, priv.company, internal.zone, svc.cluster.local. Публичные резолверы ничего об этом не знают и не должны знать. Рекурсор обычно кэширует результаты, а авторитативные серверы отдают финальный ответ. Критично выстроить четкое разграничение: внутренние зоны остаются внутри, а внешние не должны случайно попасть внутрь без контроля. Тогда у нас чистота путей, предсказуемость и контроль.

Зоны, условная переадресация, stub и forward

Классика Split DNS — это Conditional Forwarding, когда вы задаете правило: если домен заканчивается на .corp.local — отправить на 10.10.10.10 и 10.10.10.11. Forward-зоны отлично подходят для интеграции между бизнес-юнитами или при M&A: разные команды могут обслуживать свои зоны, но единая политика распределяет запросы правильно. Stub-зоны упрощают делегирование: вы не копируете записи, вы указываете, кто авторитетен, и резолвер знает, куда идти.

Почему это удобно? Вы избегаете дублирования. Нет необходимости вносить те же записи в два разных места и рисковать рассинхронизацией. В 2026 большинство корпоративных DNS умеют и forward, и stub, и смешанные режимы. Плюс, мы можем накрутить RPZ для фильтрации вредоносного контента и заблокировать рискованные домены на границе, не затронув внутренние зоны. Результат — логичный, управляемый маршрут для каждого имени.

Резолвер на клиенте: порядок, кэш и время жизни

Клиент — наш маленький дирижер. Он решает, к кому первой обращаться, как учитывать TTL, и сколько хранить кэш. В Windows это регулируется NRPT и приоритетами интерфейсов. В macOS и iOS — профилями конфигурации, где вы задаете DNS-сервер и список доменов для него. В Android — политики с частным DNS и иногда MDM управляющий приложениями. В Linux — systemd-resolved, который умеет route по доменам и интерфейсам, а это идеальный друг Split DNS.

Кэширование важно. Вы не хотите каждую минуту ходить в облако за одним и тем же A-запросом. Но и заигрываться нельзя: слишком длинный TTL ломает обновления сервисов и мешает миграциям. В 2026 разумный TTL для динамических внутренних сервисов — 30–300 секунд, для стабильных — 15–60 минут. Этого достаточно, чтобы не задушить резолверы и не застопорить релизы. А еще стоит включить негативный кэш, чтобы NXDOMAIN не бомбил систему снова и снова.

Зашифрованный DNS: DoH, DoT и DNS-over-QUIC

Шифрование DNS стало стандартом де-факто. DoH и DoT, а также DNS-over-QUIC защищают от подглядывания и подмены. Но через VPN у нас уже есть шифрование. Нужно ли двойное? Иногда да. Если вы хотите защититься от DNS-спуфинга в локальной сети пользователя до входа в туннель, либо хотите заставить клиента резолвить внешние домены строго через доверенный DoH, даже при активном VPN. Тогда вы включаете DoH на клиенте, но внимательно настраиваете правила, чтобы внутренние домены не ушли наружу.

Главное не допустить конфликтов. Если клиент форсирует DoH для всех запросов, он может не увидеть ваши приватные зоны. Решение — политика Split DNS, которая чётко описывает: внутренние домены идут к корпоративному резолверу по адресам внутри туннеля, а внешние по DoH к утвержденному провайдеру или вашему управляемому резолверу. В 2026 многие MDM и клиентские приложения VPN поддерживают это из коробки, остается только аккуратно проставить правила.

Сценарии корпоративного применения Split DNS

Active Directory и внутренние зоны

Если у вас есть AD, Split DNS буквально просится в архитектуру. Домены вроде corp.local или ad.company.internal должны резолвиться строго на контроллерах домена или на доверенных внутренностях. Причина проста: SRV и LDAP записи критичны для входа, GPO и сервисов. Если случайно увести их наружу, получим очереди из тикетов и беспокойные ночи. Split DNS направит AD-запросы по внутренним каналам и убережет от неприятных сюрпризов.

Плюс, AD любит четкость: PTR записи, грамотные CNAME, корректный GC и сайты. Разделение DNS упрощает диагностику. Вы видите, что внутренняя зона обслуживается определенным набором серверов, и проверяете их репликацию отдельно. Мы так снижаем время поиска ошибки. Вместо охоты по всем хостам, вы сразу идете в нужный уголок и чините там. В условиях удаленной работы и гибридных подключений это спасает часы, а иногда и дни.

Гибридные мультиоблачные среды

AWS, Azure, GCP, плюс on-prem — стандартная реальность 2026. Каждая платформа хранит свои приватные зоны или интегрируется с локальным DNS. Split DNS позволяет прокладывать маршруты между ними прозрачно: сервис в AWS резолвится через Route 53 Private Hosted Zone, сервис в Azure через Private DNS, а локальные системы — через BIND или Windows DNS. Пользователь ничего не замечает, а вы управляете всем с одной панели политик.

Добавим еще Kubernetes. Внутренние имена типа svc.cluster.local должны резолвиться строго внутри кластера или через корпоративный резолвер, который знает, куда отправить запросы CoreDNS. conditional forwarder помогает связать миры. Это особенно важно при сервис-мешах и межкластерном взаимодействии. Без Split DNS вы рискуете получить непредсказуемые таймауты и странные петли резолвинга. С ним — чёткое направление и ожидаемое поведение.

Разделение по бизнес-юнитам и M&A

Когда одна компания покупает другую, первая проблема — коллизии имен и зон. У обеих сторон есть internal.local, mail.internal, api.int, плюс старые исторические хвосты. Split DNS с forward и stub зонами помогает пережить этот период мягко. Вы делегируете зоны на переходный период, сближаете политики, и постепенно унифицируете схему имен. Пользователи не замечают, что под капотом два мира, потому что у них работает единый резолвер с правилами.

Внутри одной группы тоже удобно делить. Например, безопасность банкинга будет управлять собственными зонами и фильтрацией RPZ, а отдел RnD — своими экспериментальными зонами с короткими TTL. Через Split DNS вы задаете рельсы, но не мешаете локальным командам двигаться быстро. Это баланс контроля и скорости. Чем быстрее бизнес, тем важнее не душить его единой монолитной конфигурацией, а давать гибкость на краю.

Удаленные филиалы, SD-WAN и SASE

Филиалы работают через SD-WAN и SASE, пользователи в дороге сидят на LTE. Split DNS позволяет назвать резолвер для каждого сценария. В филиале — локальный кэш и forward на хаб. В мобильном сценарии — клиентский агент, который знает, какие домены отправлять в туннель, а какие резолвить локально через DoH. Временно офлайн? Кэш и негативный кэш помогают переждать, пока не поднимется связь.

В SASE-архитектуре резолвер становится политическим контроллером. Он проверяет категории доменов, метки риска, статусы угроз, и решает, разрешить, переадресовать или заблокировать. Split DNS в таком ландшафте — это карта: какие домены доверяем, какие — только в туннеле, а какие — в карантине. И всё это без ломки привычек пользователей. Они набирают адреса, кликают ссылки, а система под капотом бесшовно выбирает верный путь.

Безопасность и приватность: держим DNS под контролем

DNS-утечки: как их обнаружить и закрыть

DNS-утечка — это когда запросы на внутренние имена или чувствительные внешние домены уходят не туда. Например, во внешнюю сеть минуя VPN или в публичный резолвер, который логирует всё подряд. Проверяем тремя способами: системные журналы клиента, мониторинг на гейтвее, и синтетические тесты, которые прогоняют списки доменов и сравнивают, куда пришел ответ. В 2026 появились доступные агенты, которые пассивно наблюдают за DNS-стеком и сигналят, если политика нарушена.

Закрываем утечки политикой и приоритетами. Прописываем явные правила для приватных зон, отключаем автоматические публичные резолверы на клиенте, и используем DoH/DoT к корпоративному резолверу, когда нужно защититься от перехвата. Не забывайте про Wi-Fi гостевых сетей, где злоумышленник может внедрить поддельный DHCP. Клиент с четкой Split DNS политикой не поведется. Он знает, какие домены куда идут, и не примет лживые подсказки.

Фильтрация, RPZ и Zero Trust

RPZ — Response Policy Zone — наш фильтр токсинов. Вы можете блокировать фишинг, малварь и C2 домены на уровне DNS, не ожидая реакции антивируса. В сочетании с Split DNS это тонкий инструмент: внутренние домены обходят фильтр, если так задумано, а внешние проверяются и отсекаются. Zero Trust добавляет контекст: кто пользователь, какой у него риск-профиль, и с какого устройства он зашел. Решение может отличаться для одного и того же домена, если срабатывают сигналы риска.

Не перегните. Слишком агрессивная фильтрация приводит к ложным срабатываниям, особенно при DevOps и тестовых средах, где доменные имена генерируются динамически. Хорошая практика — белые списки для критических зон, чёткие процессы исключений на 24–72 часа, и мониторинг откатов. Фильтрация должна быть как ремень безопасности: не мешает ехать, но спасает в критический момент.

Приватность и минимизация логов

DNS — это история вашей жизни в Интернете. Мы не обязаны хранить лишнее. Минимизируйте персональные данные: не логируйте полные запросы там, где это не нужно; обрезайте IP-адреса до префикса; храните агрегированную статистику. В 2026 всё больше компаний переходят на модели с коротким retention 7–30 дней для сырых логов и долговременное хранение только агрегатов. Этого достаточно для расследований и трендов, но безопаснее для пользователей.

Помните про согласие и юридические требования. Обозначайте в политике, какие домены проходят фильтрацию, а какие нет, и как долго хранятся записи. Звучит как бюрократия? Частично да. Но это экономит нервы при любых проверках, и помогает выстроить доверие внутри команды. Когда люди знают правила игры, они работают спокойнее, и меньше ломают систему «на глаз».

DNSSEC, DANE и почтовая гигиена

DNSSEC подписывает ответы, защищая их от подмены. Для внутренних зон он иногда избыточен, но для публичных зон это уже стандарт. DANE дополняет картину, связывая сертификаты с DNS. В связке со Split DNS вы разделяете ответственность: внутри быстро и гибко, снаружи строго и подписано. Это снижает риск MITM и помогает автоматизировать проверки.

Почтовые записи SPF, DKIM и DMARC — отдельная песня. Убедитесь, что они согласованы между внутренними и внешними зонами. Если у вас есть разные домены для внутренних и внешних систем почты, Split DNS должен гарантировать, что клиенты и серверы видят именно те записи, которые вы задумали. Иначе получите нестабильную доставку, репутационные потери и переполненные очереди.

Пошаговая настройка Split DNS для популярных стеков

Windows Server DNS и VPN IKEv2 или Always On VPN

Начинаем с зон. В Windows DNS создайте внутренние forward lookup зоны для приватных доменов. Затем настройте Conditional Forwarders на адреса авторитативных серверов смежных доменов, если они в другом сегменте или в облаке. Проверьте репликацию зоны, включите разумный TTL, и добавьте PTR там, где это важно для AD и журналов. Дальше — политика клиента: через Group Policy внедрите NRPT, где вы укажете, что домены *.corp.local и *.svc.company идут к DNS в туннеле.

Для VPN IKEv2 или Always On VPN пропишите в профиле подключения адреса корпоративных DNS и список искомых доменов. Включите фильтрацию сплит-доменных правил, чтобы клиент не пытался резолвить приватные имена через публичный резолвер. Тестируйте по шагам: сначала внутренние зоны, затем внешние, потом смешанные сценарии, например внешнее имя, которое перенаправляется на внутренний reverse-proxy.

BIND или Unbound с WireGuard и OpenVPN

BIND даёт гибкость, Unbound — скорость и встроенный кэш. Создайте forward zone для приватных доменов и пропишите адреса авторитативных серверов. Для внешних доменов разрешите рекурсию, но направьте её к вашему DoH/DoT upstream или к локальным корневым подсказкам. В WireGuard добавьте в конфиг списки доменов в клиентском резолвере или примените скрипты, которые обновляют systemd-resolved маршрут для нужных зон. В OpenVPN используйте push dhcp-option DOMAIN-ROUTE для обозначения доменных маршрутов, если клиент это поддерживает.

Проверка — ключ. Посмотрите dig или drill для внутренних и внешних имен. Сравните время ответа с включенным и выключенным кэшем. Оцените нагрузку на резолвер при пиковой активности. Включите логи на время внедрения, затем снизьте уровень до умеренного. Иначе будете тонуть в событиях, теряя важный сигнал на фоне шума.

pfSense или OPNsense и DoT/DoH

В pfSense и OPNsense есть встроенные резолверы и форвардеры. Вы можете задать Conditional Forwarding на уровне GUI, указав приватные зоны и адреса. Подключите DoT для внешних запросов к доверенным провайдерам, а для внутреннего трафика оставьте обычный UDP или TLS, если это требуется политикой. Включите кэш и разумные лимиты. Настройте Health Check: резолвер должен быстро переключаться на запасной upstream, чтобы пользователи не застревали в тайм-аутах.

Важно: если используете DoH на клиентах, убедитесь, что ваши правила не ломают внутренние домены. Часто помогает принудительное указание исключений для внутренних зон и жесткая маршрутизация DNS по туннелю. Тестируйте из разных сетей — домашний роутер, мобильная сеть, гостевой Wi-Fi — чтобы поймать сетевые «чудачества» до того, как их поймут пользователи.

MikroTik, Conditional Forwarding и маршруты

MikroTik с RouterOS давно научился работать как форвардер и кэш. Создайте статические доменные маршруты для приватных зон, укажите адреса внутренних резолверов и включите кэш с ограничением TTL. Пропишите резервные адреса, чтобы при падении одного узла всё продолжало работать. Если у вас гибридный доступ, настройте правила по интерфейсу VPN, чтобы DNS для внутренних зон всегда ходил через туннель.

Проверяйте любые изменения на небольших группах пилотных пользователей. Реальность упряма: где-то старый роутер, где-то нестандартное ПО. Лучше поймать несовместимость на пилоте, чем в продакшене. И держите шаблоны конфигураций под версионированием — это экономит часы на восстановление после случайного отката.

Клиентские платформы и политики

Windows 11 и 12: NRPT, приоритеты и DoH

Windows умеет явно направлять домены к определенным резолверам через NRPT. Используйте GPO или MDM, чтобы раздать правила: для *.corp.local, *.int.company и *.svc.cluster.local — внутренние DNS по адресам в туннеле. Включите Prefer DoH для внешних резолверов, если хотите шифровать внешние запросы; при этом добавьте исключения, чтобы внутренние домены не уходили по DoH. Проверьте порядок интерфейсов, чтобы VPN-интерфейс имел приоритет для нужных зон.

Не забудьте про Split DNS при Always On VPN. Клиент должен понимать, какие запросы пойдут в туннель. В 2026 клиенты научились лучше работать со смешанными сценариями, но тонкие конфликты все еще встречаются. Логируйте на этапе внедрения, используйте Test Lab, и прогоняйте чек-листы перед релизом на широкую аудиторию.

macOS и iOS: профили, per-app VPN и NetworkExtension

macOS и iOS используют конфигурационные профили, где можно задать списки доменов и резолверов, а также правила per-app VPN. Это удобно: вы можете направлять корпоративные приложения по туннелю с внутренним DNS, а браузер оставлять на внешний DoH. Важна синхронизация: если приложение использует собственный резолвер, убедитесь, что его политика не конфликтует с системой.

В 2026 Apple ускорила стек DNS и улучшила кэш. Но помните о ретрай-логике: если резолвер отвечает медленно, система может переключаться на другой профиль. Тонкая настройка таймаутов и приоритетов помогает избежать ложных переключений. А еще — оптимизируйте списки доменов, не делайте из него энциклопедию. Короткие, четкие правила всегда работают стабильнее.

Android 14 и 15: Private DNS и MDM

Android позволяет включить Private DNS по DoT и частично управлять правилами через MDM. Если у вас корпоративный агент, используйте его для Split DNS: внутренние домены к корпоративному резолверу, все остальное по DoT к доверенному провайдеру. Per-app VPN помогает разделить трафик по приложениям, что важно для BYOD, где вы не хотите трогать личные приложения сотрудника.

Проверяйте устройства разных вендоров. Производители любят «творчески» интерпретировать стандарты. Одинаковая политика на бумаге работает по-разному на двух моделях. Пилоты, обратная связь, быстрые исправления — и вы избежите шквала негативных отзывов. И да, объясните сотрудникам, зачем им это. Когда люди понимают выгоду, они охотнее обновляют профили и меньше ломают настройки.

Linux: systemd-resolved и маршруты по доменам

systemd-resolved прекрасен для Split DNS. Вы можете назначить резолверы на интерфейсы и домены, определить приоритеты, включить кэш и негативный кэш. Интеграция с NetworkManager упрощает жизнь: VPN поднимается — правила применяются, VPN падает — правила снимаются. Для WireGuard можно применить скрипты, которые добавляют доменные маршруты при поднятии интерфейса.

Учтите нюансы контейнеров и Kubernetes на хосте. Если вы запускаете dev-кластеры или тяжелые контейнеры, они могут использовать свои резолверы. Следите, чтобы корпоративные зоны не уходили в никуда. Лучше явно прописать правила и в контейнерной среде, чем ловить странные таймауты от сервисов, которые «вдруг сами починились» через полчаса из-за TTL.

Практические советы и чек-лист

Планирование доменов и обратных зон

Начните с карты. Какие зоны внутренние, какие внешние, где авторитет, где рекурсия. Определите обратные зоны для ключевых подсетей и заведите PTR там, где это нужно для журналов и безопасности. Не берите экзотические TLD для внутренностей, используйте штатные private зоны или субдомены существующих доменов. Это упрощает жизнь при интеграциях и убирает риск коллизий.

Оцените, как пользователи вводят адреса. Если все привыкли к коротким именам, придётся поддерживать search suffixes и грамотные Suffix Search Lists. Но не перегибайте: слишком много суффиксов создают лишние запросы и задержки. Баланс — 1–3 суффикса для большинства сценариев, плюс чёткие правила, когда использовать FQDN.

Производительность, кэш и лимиты

Кэш — ваш лучший друг, если контролируете TTL. Для динамических сервисов ставьте короткий TTL и используйте агрессивный кэш на периферии: филиальские резолверы разгрузят центральные узлы. Включите анти-шторм: лимиты на одно имя и запреты на бесконечные ретраи. В 2026 популярны эластичные резолверы, которые автоматически наращивают capacity под нагрузкой и возвращаются назад ночью.

Профилируйте время ответа. Нормальный DNS обычно укладывается в 20–40 мс для внутренних зон и 40–120 мс для внешних. Если видите всплески до 300–500 мс, копайте: перегруженный кэш, проблемы с upstream, или же конфликты DoH и VPN. Локализуйте узкие места и держите SLO. Мы живем в эпоху SRE, и DNS — это тоже SRE-история.

Мониторинг, алерты и SLO

Включите три уровня мониторинга: синтетические тесты по списку доменов, метрики резолверов (QPS, NXDOMAIN, SERVFAIL, кеш-хиты), и трассировку отдельных пользовательских сеансов для сложных инцидентов. Настройте оповещения не на каждое чихание, а на устойчивые отклонения. Пусть система 10 минут терпит скачок, прежде чем звать инженера ночью.

Заведите дашборды: внутренние зоны, внешние, ошибки по типам, latency-percentiles. Смотрите на p95 и p99, они честнее среднего. И да, учите команду читать эти графики. Хорошая визуализация экономит часы совещаний. Быстро понял — быстро починил — быстро вернулся к задачам бизнеса.

Документация, обучение и режим изменений

Опишите правила простым языком. Где какая зона, кто за что отвечает, какие исключения допустимы и как их оформлять. Новички и смежники должны понимать картину за 10–15 минут. Это возможно, если убрать жаргон и оставить суть. Внутренний портал с короткими инструкциями делает чудеса.

Внедрите change management: малые батчи, канареечные развертывания, быстрые откаты. Проверяйте каждое изменение на пилоте и фиксируйте результат. Ошибки в Split DNS обычно не смертельны, но очень раздражают пользователей. Избежать их реально, если соблюдать дисциплину и не менять всё сразу.

Реальные кейсы: что сработало и что нет

Банк на 30 000 сотрудников

У банка было три зоны AD и две приватные облачные зоны, плюс публичная витрина в отдельном домене. Пользователи жаловались на задержки до 1,5 секунд при входе в клиент-банки и CRM. Мы внедрили Split DNS с forward для облачных зон, оптимизировали TTL до 120 секунд для стабильных сервисов и до 30 секунд для Kubernetes. Добавили RPZ для фишинга. Результат — p95 резолва упал с 420 мс до 110 мс, логины стали ощущаться «моментальными».

Что не сработало сразу? Слишком агрессивный DoH на клиентах. Он перехватывал внутренние домены через публичный резолвер. Исправили политикой исключений, и всё стабилизировалось. Урок: не доверяйте настройкам по умолчанию, особенно на разнородном парке устройств.

Multi-cloud стартап с быстрыми релизами

Стартап держал прод в AWS и тест в GCP, при этом CICD мигрировал между зонами каждые пару недель. Разруливали через Split DNS с динамическими forward-зонами, автоматизированными из Git. Разработчики получали новые записи в течение минуты, а пользователи — стабильно резолвили нужные адреса. Кэш на периферии экономил пропускную способность.

Однажды они поймали забавный баг с CDN и ECS: геолокационный кэш выбирался неверно из-за расширения EDNS. Решили, ограничив ECS для некоторых доменов. Да, иногда тонкая настройка — это магия. Но в итоге доставка контента стала быстрее на 12–18 процентов по p95.

Производство и сети филиалов

Заводы, станки, SCADA и куча старых контроллеров. Здесь Split DNS спасал от хаоса: приватные имена заводских систем резолвились локально и предсказуемо. Мы подняли легкие кэширующие резолверы на каждом филиале, настроили forward на хаб, и ввели строгие TTL. Когда связь падала, производство не останавливалось, потому что кэш держал критичные записи.

Проблемой стали старые принтеры, неожиданные рекурсоры и «умные» коммутаторы с собственным DHCP. Мы отключили сторонние раздачи, усилили контроль, и добавили мониторинг на порталах, чтобы видеть, откуда валятся запросы. После недели чистки сеть стала тише, а проблемы — редкими.

Госсектор и соответствие требованиям

Здесь особенно строга приватность. Мы распределили зоны, внедрили DNSSEC на публичных доменах, ограничили логирование персональных данных, и ввели четкий срок хранения логов. Внешние запросы шли по DoH к доверенным резолверам, внутренние оставались внутри периметра через VPN. Команда аудита осталась довольна, а пользователи не заметили ничего — и это главный комплимент.

Ключевой момент — документация и повторяемость. Без понятных регламентов любой аудит превращается в тяжёлую драму. С Split DNS вы демонстрируете прозрачность: правила вот, мониторинг вот, логи вот, исключения вот. Спокойно, по-человечески, без загадок.

Частые ошибки и способы исправления

Дублирование записей и split-horizon

Самая коварная ошибка — держать две копии одних и тех же записей в разных местах. Сегодня совпали, завтра разошлись, послезавтра пользователи в отчаянии. Решение — forward или stub вместо копирования. Пусть один источник будет авторитетом, а остальное — маршрутизация. Так проще жить и проще объяснять, почему ответ такой, а не другой.

Split-horizon сам по себе не зло, но требует железной дисциплины. Если у вас разные ответы для внутренних и внешних клиентов, следите за TTL и обновляйте обе стороны одновременно. Иначе получите странные кейсы, когда мобильный пользователь видит одну картину, а коллега в офисе — другую. Это очень сбивает с толку.

Неправильный порядок резолверов на клиентах

Еще один хит. Клиент может сначала спросить публичный резолвер, а только потом корпоративный. В результате внутренние имена «не существуют». Лечим приоритетами интерфейсов, правилами NRPT, и явным указанием доменных маршрутов. Проверьте поведение на каждой платформе. Не надейтесь, что «по умолчанию всё умно».

Добавьте диагностику для службы поддержки: короткий чек-лист из 5–7 шагов, чтобы понять, куда ушел запрос. Это снижает время решения в разы. Команда не будет мучить инженеров базовыми вопросами, а быстро соберет нужные факты и направит тикет правильно.

EDNS, ECS и неожиданности CDN

Расширения EDNS и ECS влияют на георазмещение кэша CDN. Иногда из-за них пользователи получают не самый близкий узел. Проверьте, передает ли ваш резолвер ECS и каким образом. Для некоторых доменов лучше ограничить ECS, чтобы выдача стала более стабильной. Результат нередко удивляет: задержка падает, скачки исчезают, а жалобы уменьшаются.

Не бойтесь экспериментировать на малой группе. Измеряйте прежде чем внедрять глобально. CDN любят «крутить ручки» на своей стороне, и ваша тонкая настройка может дать плюс 10–20 процентов к скорости, если попасть в резонанс с их политиками.

Сертификаты, PTR и обратные зоны

SSL и mutual TLS не любят бардака в DNS. Если CN и SAN ссылаются на домены, которые иногда резолвятся неправильным путем, получите ошибки рукопожатия. Наведите порядок: внутренние имена — строго внутренним резолвером, внешние — внешним. А PTR поддерживайте для ключевых систем, иначе диагностика и SIEM могут выглядеть как кроссворд без подсказок.

Обратные зоны часто забывают. Потом удивляются, почему не бьется аналитика или почему система аудита всё метит как «неопознанные гости». Включите PTR там, где это важно, и установите разумный TTL. Мелочь, а экономит нервы.

Тренды 2026 и что внедрять уже сейчас

ZTNA и программно-определяемый периметр

Zero Trust и SDP меняют архитектуру доступа. Split DNS тут становится частью контекстной политики: резолвер видит пользователя, устройство, приложение, риск, и уже потом решает, куда направить запрос и какой ответ отдать. Мы шагаем от простого «куда спросить» к интеллектуальному «зачем и кому ответить».

Практически это выглядит так: агент на устройстве, политика в облаке, управляемый резолвер с фильтрацией, и динамическая маршрутизация через ZTNA-шлюз. Простая идея, сложная реализация. Но выигрыш в контроле и безопасности огромный. Начните с малого и растите по мере зрелости команды.

DNS-over-QUIC и Encrypted ClientHello

QUIC ускоряет и делает связь устойчивее к потере пакетов. DNS-over-QUIC — логичное продолжение. В 2026 его поддержку активно добавляют и клиенты, и резолверы. Параллельно набирает обороты Encrypted ClientHello, скрывающий детали TLS-рукопожатия. Для Split DNS это дополнительный плюс к приватности: меньше метаданных у периметра, сложнее слежке.

Где подвох? Совместимость и диагностика. Тестируйте тщательно. Включение QUIC может повлиять на поведение старых прокси или IDS. Но тренд очевиден: через год-два это станет доминирующим способом шифрования для множества сценариев.

Управляемые резолверы с AI-подсказками

Управляемые резолверы в 2026 умеют много: автотюнинг TTL, адаптивное кеширование, подсказки по проблемным зонам, и аномалики на базе машинного обучения. Они видят, что конкретный домен стал отвечать медленнее, и предлагают снизить TTL или переключить upstream. Или же замечают, что подсеть пользователей перегружает кэш, и советуют переместить ребро.

Это не магия, но почти. Главное — не терять контроль. Любые автоправки должны проходить через Change Review, пусть и ускоренный. Ошибка резолвера сегодня — полдня хаоса завтра. Да, мы хотим скорость, но не хотим сюрпризов. Умные подсказки — да. Автономные решения — осторожно и постепенно.

Регуляторика, комплаенс и данные

Требования к приватности растут. Компании пересматривают политики хранения логов, вводят псевдонимизацию, и отделяют операционные метрики от персональных данных. Split DNS здесь на стороне добра: он помогает сократить «лишние глаза» и направляет чувствительные запросы только к доверенным резолверам. Логи становятся чище, риск утечек меньше, а аудит спокойнее.

Совет на каждый день: документируйте, какие категории доменов куда идут, кто видит какие данные, и что логируется. Это скучно, но чудесно спасает, когда случается инцидент. Вы быстро отвечаете на главные вопросы, и не теряете время на хаотичный поиск.

FAQ: коротко о главном

Что такое Split DNS простыми словами

Это когда разные домены резолвятся разными DNS-серверами по правилам. Внутренние имена идут к корпоративному резолверу через VPN, внешние — к публичному или управляемому резолверу. Пользователь видит просто «все работает», а вы контролируете приватность, скорость и безопасность.

Чем Split DNS отличается от Split Tunneling

Split DNS делит только DNS-разрешение имен. Split Tunneling делит весь сетевой трафик. Их можно использовать отдельно или вместе. Например, держать полный туннель для всего трафика, но внешние домены резолвить по DoH, а внутренние — по корпоративному DNS.

Как понять, что у меня DNS-утечка

Признаки: внутренние имена не резолвятся, иногда появляются странные ответы, логин в AD или корпоративные порталы подвисают. Проверьте логи резолвера, прокатайте синтетические тесты, и посмотрите, какой резолвер отвечает на приватные зоны. Если это не ваш корпоративный DNS — у вас утечка.

Нужно ли включать DoH или DoT, если уже есть VPN

Иногда да. DoH или DoT защищают запросы от подмены и подглядывания до попадания в туннель и после выхода из него, если используете внешний резолвер. Но важно прописать исключения для внутренних зон, чтобы не сломать доступ к приватным сервисам. Баланс безопасности и совместимости — ключ к успеху.

Можно ли делать Split DNS без прав на клиентских устройствах

Частично. Вы можете настроить резолвер на периметре и использовать принудительную переадресацию. Но идеальный вариант — централизованная политика на клиентах через MDM или групповые политики. Тогда правила работают одинаково, а неожиданные обходы минимальны.

Какие ошибки встречаются чаще всего

Дублирование записей вместо forward, неправильный приоритет резолверов на клиенте, слишком длинные TTL, конфликт DoH с внутренними зонами, и недонастроенный мониторинг. Лечится дисциплиной, пилотами, чек-листами и разумными дефолтами. И да, не бойтесь упрощать, когда можете.