Я пытаюсь определить поддомен для частной сети (RFC1918) за брандмауэром NAT; назовем его priv.example.com. Обычно и из того, что я могу собрать на различных веб-сайтах, это можно сделать, делегировав поддомен с общедоступного и внешнего DNS-сервера, например example.com, другому DNS-серверу, который является внутренним и авторитетным для priv.example.com.
Однако у меня есть пара проблем, которые нужно решить с помощью этого решения. Во-первых, мне не нужно, и я не хочу, чтобы общедоступный Интернет знал о priv.example.com. Я полагаю, что это можно было бы обработать с помощью представлений привязки, но я еще не совсем понял это (и я не уверен, поддерживает ли наш DNS-хост представления). Во-вторых, мне пришлось бы открыть брешь в брандмауэре и создать преобразование адресов, чтобы внешний DNS-сервер мог видеть внутренний. Это похоже на ненужную угрозу безопасности.
Есть ли способ создать этот сценарий, не сообщая общедоступному DNS-серверу, например, example.com, о частном DNS для Priv.example.com? Я использую bind9 для внутреннего частного сервера. Есть ли лучшее общее решение для предоставления службы имен для моей частной сети? Я видел и другие, более противоречивые решения, такие как использование частного TLD или определение дублирующего «главного» DNS для домена второго уровня в частной сети. Мне они кажутся уродливыми.
Какой DNS-сервер (преобразователь) используют компьютеры в вашей локальной сети? Если они используют администрируемый вами внутренний сервер привязки, вы можете просто настроить зону для своего домена и добавить соответствующие записи для своих внутренних служб. DNS-сервер по-прежнему будет нормально работать как преобразователь для получения внешних адресов, но будет обслуживать локальные зоны для локальных пользователей вашего локального домена.
Конечно, все компьютеры должны будут использовать DNS-сервер, который вы для них настроили, а не другие DNS-серверы (например, opendns, google и т. Д.).
Вы можете настроить привязку с разделенным DNS. Тогда у вас будет два отдельных файла зоны для домена. Тот, который будет представлен публике, будет содержать только те записи, которые вы хотите сделать общедоступными. Файл зоны для того же домена, который будет обслуживаться внутри, будет содержать ту же информацию плюс любые дополнительные ресурсы, которые вы хотите использовать для внутренних клиентов. Этот файл внутренней зоны может также обслуживать внутренние адреса ресурсов, а не публичный адрес, если это необходимо.
Вам необходимо, чтобы все системы внутри сети разрешались на внутренний DNS-сервер.
Как только все хосты будут использовать внутренний DNS-сервер, вы можете либо определить поддомен как зону, как предлагает mulaz, либо использовать DNS Forwarding, что позволит вам выбрать, какие хосты переопределить, а остальные разрешить извне. В любом случае внутренний DNS-сервер будет ретранслировать (и кэшировать) любые запросы, о которых он не знает (например, google.com).