Split DNS: как сравнить внутренний и публичный ответ домена

Если сайт открывается только из офиса, через VPN или, наоборот, только из внешней сети, сначала сравните DNS-ответ для одного и того же полного имени. Внутренний и публичный резолверы могут возвращать разные адреса: это признак split DNS, но не обязательно ошибка.

Проверку нужно выполнить минимум из двух сетей и сохранить результат до очистки кэша. Сравнивайте не только IP-адрес, но и код ответа, A, AAAA, CNAME, TTL и DNS-сервер, который дал ответ.

Что такое split DNS и когда разница нормальна

Split DNS, или разделённая DNS-зона, намеренно показывает разные данные внутренним и внешним клиентам. Например, имя portal.example.ru в офисе может вести на внутренний адрес, а вне корпоративной сети — на публичный шлюз. В BIND такой сценарий реализуют через разные views одной зоны.

Сама разница ответов не означает сбой. Проблема начинается, когда одна из зон устарела, нужной записи в ней нет, клиент обращается не к тому резолверу или один из адресов недоступен из предназначенной для него сети.

Как сравнить внутренний и публичный DNS-ответ

1. Зафиксируйте точное имя и ожидаемую схему

Не проверяйте «домен вообще». Запишите полное имя, на котором возникает проблема: www.example.ru, api.example.ru или portal.example.ru. Отдельно сформулируйте ожидание: какой адрес должен получать сотрудник в офисе и какой — внешний посетитель.

Если ожидаемой схемы нет, два разных ответа нельзя уверенно назвать ни правильными, ни ошибочными. Сначала найдите владельца внутренней и публичной зон и определите источник истины для каждой.

2. Узнайте, какой резолвер использует устройство

На Windows посмотрите DNS-серверы командой:

ipconfig /all
nslookup portal.example.ru

На macOS подойдут scutil --dns и dig portal.example.ru. На Linux с systemd-resolved можно использовать resolvectl status и resolvectl query portal.example.ru.

Сохраните имя сервера, код ответа и полученные записи. Учтите VPN: после подключения он может заменить системный DNS или направить только корпоративные имена во внутренний резолвер.

3. Повторите запрос из внешней сети

Отключитесь от корпоративного VPN и повторите запрос через мобильный интернет или другую независимую сеть. Дополнительно спросите выбранный публичный рекурсивный резолвер напрямую:

dig @<публичный-резолвер> portal.example.ru A
dig @<публичный-резолвер> portal.example.ru AAAA
dig @<публичный-резолвер> portal.example.ru CNAME

Запросы должны относиться к одному имени и быть сделаны близко по времени. Иначе изменение зоны между проверками исказит сравнение.

4. Отделите split DNS от ошибки публичной зоны

Запросите публичную запись у каждого авторитетного NS:

dig +norecurse @ns1.provider.example portal.example.ru A
dig +norecurse @ns2.provider.example portal.example.ru A

Если авторитетные серверы расходятся между собой, это отдельная проблема публичной зоны. Её разбор описан в статье как сравнить каждый NS и SOA serial.

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

5. Проверьте уровни, которые могут подменить результат

Если командная строка и браузер показывают разное поведение, проверьте:

• файл hosts на устройстве;
• защищённый DNS в браузере или операционной системе;
• активный VPN и правила раздельной маршрутизации;
• локальный, системный и браузерный DNS-кэш;
• прокси, межсетевой экран и TLS-сертификат на каждом целевом сервере;
• записи AAAA: браузер может пытаться использовать IPv6, хотя проверяли только A.

Не очищайте кэш первым действием. Сначала сохраните исходный ответ и TTL: после очистки важное доказательство исчезнет.

Как интерпретировать результат

| Наблюдение | Что проверять дальше | |---|---| | В офисе внутренний адрес, снаружи публичный, оба доступны | Split DNS работает по ожидаемой схеме | | В офисе NXDOMAIN, снаружи правильный адрес | Внутренняя зона перекрывает публичную, но нужной записи в ней нет | | В офисе старый адрес, снаружи новый | Запись или кэш внутреннего резолвера не обновлены | | DNS-ответы ожидаемые, но сайт не открывается только в офисе | Ищите причину в маршруте, прокси, firewall или TLS, а не в DNS | | dig и браузер ведут на разные адреса | Проверьте защищённый DNS, hosts, VPN и кэш браузера | | Публичные NS дают разные записи | Сначала устраните рассинхронизацию авторитетных серверов |

Таблица задаёт направление, но не доказывает первопричину. Например, правильный адрес ещё не подтверждает, что по нему доступны нужный порт, сертификат и виртуальный хост.

Безопасный порядок исправления

1. Сохраните ответы из офиса и внешней сети вместе со временем проверки.
2. Подтвердите ожидаемые записи и владельца каждой зоны.
3. Исправьте только ошибочное представление: внутреннее или публичное.
4. Если используется CNAME, проверьте также конечное имя и обе цепочки A/AAAA.
5. Повторите запросы через те же резолверы после обновления.
6. Откройте сайт из обеих сетей и проверьте сертификат, редиректы и нужную страницу.

Не удаляйте split DNS только потому, что ответы отличаются. Это может нарушить доступ к внутренним сервисам. И не меняйте публичную запись, если ошибка находится во внутренней зоне: внешним посетителям такое изменение добавит новый сбой.

Что публичная проверка не увидит

Внешний сервис видит только публичный DNS и доступный из интернета адрес. Он не может подтвердить ответ корпоративного резолвера или доступность внутреннего сервера. Web-Puls помогает регулярно контролировать публичную доступность сайта, но внутреннюю часть split DNS нужно проверять из офисной сети отдельным наблюдением.

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