Использование частных и общедоступных DNS с DNSSEC
Моя компания ' example.com ' имеет общедоступный хост www.example.com . Внутренняя сеть (устаревшая управляемая Windows) имеет несколько внутренних хостов internalhost1.example.com , internalhost2.example.com и т. Д.
Внутренняя сеть имеет внутренний частный уполномоченный DNS-сервер для example.com . Общедоступный DNS-сервер размещен где-то в Интернете. Внешние пользователи в Интернете не могут разрешить внутренние узлы, они недоступны на общедоступном DNS-сервере. Внутренние пользователи могут разрешать внутренние хосты, потому что они используют для разрешения внутренний DNS-сервер.
Теперь общедоступный DNS находится в процессе защиты с помощью DNSSEC. Я убедился, что в настоящее время внутренние клиенты, похоже, не заботятся о том, чтобы внешний DNS был защищен DNSSEC, они просто продолжают доверять внутреннему DNS-серверу, клиенты «не проверяют».
Теперь мой вопрос: есть ли какой план или план действий, чтобы заставить всех клиентов проверять DNSSEC? Как долго будет работать указанная выше настройка, если мы защитим общедоступный DNS с помощью DNSSEC и оставим частный DNS не-DNSSEC? Год? Десять лет? Навсегда? Должны ли мы преобразовать наш внутренний домен в example.local или мы можем оставить его example.com ?
TLDR; если вы управляете своими рабочими станциями, ваши рабочие станции всегда будут работать так, как вы ожидаете.
Внутренние системы должны были быть субдоменом общедоступного домена, и тогда вы могли бы делегировать/подписывать внутреннюю зону с вашим родительским доменом, а также больше не нуждались бы в разделенном DNS в качестве ваших внешних записей (www.example. com) будет разрешаться извне, вы МОЖЕТЕ добавить записи A, которые указывают внутрь, наружу, но вы не можете добавлять связующие записи для внутренних IP-адресов. Также я бы рекомендовал всегда использовать доменное имя, которым вы управляете, а не поддельный example.local и ни в коем случае не domain.companytld
Windows (Таблица политики именованного разрешения (NRPT)) и linux (systemd-resolve) поддерживают настройки на стороне клиента для проверки DNSSEC, а также возможность указать, какие домены всегда должны быть подписаны.
Другие вещи, которые следует учитывать, DoH (DNS через HTTPS), который может обойти все ваши существующие средства безопасности и манипуляции с DNS.