Короткий ответ

Split DNS (split-horizon): имя www.contoso.example внутри отдаёт 10.0.10.10, снаружи — публичный. Поломано, когда офисный клиент спрашивает внешнюю зону (публичный DNS в NIC, утечка форвардинга, зона на DC без внутренних A) или наоборот — интернет видит внутренние RFC1918. Согласуйте записи в каждой зоне отдельно. Не «выровняйте всё на публичный IP» без hairpin NAT.

Клиенты LAN: резолвер только 10.0.10.2.

Симптомы и как отличить

  • В офисе nslookup www.contoso.example 8.8.8.8 — публичный, @10.0.10.2 должен быть внутренний, но тоже публичный;
  • сертификат на имя, IP не слушает TLS;
  • с телефона LTE сайт жив, из 10.0.10.0/24 нет.

Отличия: кеш старого внутреннего — кэш. Флап серверов — нестабильный DNS. Одна сеть из двух — сайт из одной сети.

Возможные причины

  1. Клиентский DNS = публичный.
  2. На 10.0.10.2 зона contoso.example не внутренняя, а stub/forward на интернет.
  3. Нет A для www внутри, рекурсия находит внешнюю.
  4. NRPT/VPN: суффикс уводит запросы.
  5. Два имени: contoso.example AD и внешний сайт на том же FQDN без внутренних хостов.
  6. Split в Cloudflare/другом DNS только на одной стороне, офисный AD не зеркалит нужные A.
  7. www CNAME на внешний CDN, внутренний обход потерян.

Диагностика

1. Что видит клиент из 10.0.10.0/24

Get-DnsClientServerAddress -AddressFamily IPv4
nslookup www.contoso.example
nslookup www.contoso.example 10.0.10.2
nslookup www.contoso.example 8.8.8.8
resolvectl status
dig www.contoso.example @10.0.10.2
dig www.contoso.example @8.8.8.8

Запишите оба IP. Ожидание split: разные. Если оба публичные — внутренний split не работает.

2. Авторитатив внутренней зоны

Get-DnsServerZone -Name 'contoso.example'
Get-DnsServerResourceRecord -ZoneName 'contoso.example' -Name 'www'
Get-DnsServerForwarder

Если зона на DC Primary и без www — рекурсия может сходить наружу только если имя не считается локальным. Для AD-зоны contoso.example обычно NXDOMAIN на неизвестный хост, не внешний A. Картина «внутренний сервер отдаёт публичный» чаще значит: не спросили DC, а форвардер/публичный.

Исключение: на 10.0.10.2 не AD, а резолвер без зоны, только forward — тогда split нет вообще.

3. VPN

Сравните resolvectl/NRPT с туннелем UP и DOWN. Часто split ломается только в VPN.

4. Сертификат vs IP

Test-NetConnection www.contoso.example -Port 443

Публичный IP из LAN без hairpin → timeout. Внутренний IP → должен открыться.

Решение

Сценарий A. Клиенты не используют 10.0.10.2

DHCP option 6, GPO DNS, запрет DoH. Это база split.

Сценарий B. Нужны внутренние A

Создайте www → 10.0.10.10 в внутренней зоне. Внешнюю зону не трогайте (там публичный). Проверьте, нет ли CNAME, который уводит наружу.

Сценарий C. Одно имя, хотите публичный IP из LAN

Тогда это не split A, а hairpin: оставьте внешнюю запись, настройте NAT loopback. Не смешивайте «половина ПК с внутренней A, половина с публичной».

Сценарий D. AD и веб на одном FQDN леса

Не публикуйте внутренние SRV во внешнюю зону. Для сайта используйте www или portal.contoso.example с явными двумя представлениями. Apex contoso.example в AD — NS/SOA/DC, не «как на хостинге».

Сценарий E. Резолвер без внутренней зоны

Либо держите зону на 10.0.10.2, либо view/split на BIND с match-clients { 10.0.10.0/24; }. Не forward внутренний суффикс в интернет.

6. Таблица двух миров в тикете

Для каждого спорного FQDN запишите: внутренний A (ожидание 10.0.10.10 или иной RFC1918), внешний A (публичный), какой резолвер обязан отдавать какой. Затем с ПК LAN: nslookup FQDN 10.0.10.2 и nslookup FQDN 8.8.8.8. Если оба публичные — split на 10.0.10.2 нет: либо нет внутренней записи, либо клиент не спрашивает DC. Если внутренний правильный, а браузер всё равно идёт на публичный — DoH/hosts/кэш. Из LAN к публичному без hairpin TCP/443 умрёт: это не «сломанный IIS», а дизайн. VPN: NRPT может слать contoso.example в туннель или наоборот в интернет; снимайте с туннелем UP и DOWN.

Не копируйте внешнюю зону в AD целиком: затрёте SRV и NS леса. Не публикуйте _msdcs наружу. Apex contoso.example в AD — не место для «как на хостинге A на CDN». Используйте www/portal. IPv6 AAAA только снаружи при IPv4 внутреннем ломает Happy Eyeballs. После появления внутренних A сбросьте кеш точечно, не зону. Проверка: LAN открывает по внутреннему IP, LTE — по публичному, сертификат совпадает с именем. Если сознательно хотите публичный IP из LAN — hairpin, и тогда внутренняя A не обязана существовать. Выберите одну модель на имя, не «у половины ПК так, у половины иначе».

Резолвер без зоны, только forward на интернет, не может делать split. Либо зона/view на 10.0.10.2, либо клиенты не должны использовать этот ящик для corp имён.

На Windows дополнительно Get-DnsClientNrptPolicy: корпоративный VPN часто держит split здесь, а не в NIC. Ubuntu resolvectl domain и DNS Domain: суффикс contoso.example должен уходить на 10.0.10.2, не в публичный DoT. Если админ «для проверки» прописал 8.8.8.8 вторым, внутренние имена будут флапать — это пересекается с нестабильным DNS, но корень тот же: публичный резолвер не знает вашей внутренней зоны. После правок зоны подождите TTL или сбросьте кеш на нужном уровне. Не используйте внешний ping по имени как доказательство split: ICMP может уйти на CDN, а HTTPS — на origin.

Как проверить, что проблема устранена

С ПК в LAN:

nslookup www.contoso.example 10.0.10.2
Test-NetConnection 10.0.10.10 -Port 443

С рекурсии «как интернет» (с узла, которому можно): публичный IP. VPN-клиент: по политике (часто внутренние). Кеш сброшен. Браузер без DoH.

Если не помогло

  • IPv6 AAAA внешний, A внутренний — браузер берёт AAAA.
  • Кеш после смены.
  • Портал на 10.0.10.10, имя резолвится верно, HTTP 502 — уже приложение.
  • Wild-card *.contoso.example во внешней зоне перебивает ожидания.

Профилактика

  • Таблица: FQDN × внутренний IP × внешний IP.
  • Клиенты домена только внутренние DNS.
  • Регулярно сравнивать dig @internal vs @external для ключевых имён.
  • Не делегировать AD-зону на публичный NS.

FAQ

Это split-brain DNS?

В разговорной речи часто да. В AD «split-brain» ещё путают с двумя мастерами. Здесь — разные ответы по месту клиента.

Выровнять внутренний A на публичный проще?

Только с рабочим hairpin. Иначе офис потеряет сайт.

Нужен ли BIND view, если есть AD?

Часто достаточно зоны на DC с внутренними A + внешний хостинг отдельно. BIND views — когда один сервер служит обоим мирам.

Почему nslookup без 8.8.8.8 всё равно внешний?

Потому что NIC/DoH/форвардер. Get-DnsClientServerAddress важнее ощущений.

Можно ли держать одинаковые записи «на всякий»?

Только те, что должны совпадать (MX обычно внешние; внутренние MX — отдельная схема). Слепое копирование всей внешней зоны в AD сломает SRV.