Как заставить Windows Server DNS использовать файл hosts для разрешения определенных имен хостов

[ПРИМЕЧАНИЕ: решение этого вопроса идеально, если что-то не так, как указано в названии.]

Я столкнулся с небольшой проблемой Windows Server 2003 DNS service. В моей корпорации я использую сервер Microsoft DNS ( 172.16.0.12) для разрешения имен в интрасети моей компании (доменное имя оканчивается dev.nlsразрешением на IP 172.16 . ), И он также настроен как сервер пересылки DNS для пересылки других доменных имен ( например, * .google.com, * .sf.net) в Internet real DNS servers. Этот внутренний DNS-сервер никогда не обслуживает пользователей из внешнего мира.

И мы используем почтовый сервер (обслуживающий входящую почту для реального интернет-домена @nlscan.com) внутри брандмауэра компании, к которому можно получить доступ любым способом:

1. подключившись 172.16.0.10изнутри интранета.
2. путем подключения к mail.nlscan.com(решил 202.101.116.9) из Интернета.

Обратите внимание, что 172.16.0.10и 202.101.116.9это не тот же физический компьютер. Один из 202них - это брандмауэр, который выполняет переадресацию порта 25и 110адреса в интрасети 172.16.0.10.

Теперь мой вопрос: если пользователи внутри корпоративной локальной сети хотят разрешить mail.nlscan.com, она разрешается в 202.101.116.9. Это правильно и работоспособно, НО НЕ ХОРОШО, потому что почтовый трафик направляется на компьютер брандмауэра, а затем возвращается 172.16.0.10. Я надеюсь, что наши internal DNS serverмогут перехватить имя mail.nlscan.comи разрешить его до 172.16.0.10. Итак, я надеюсь, что я могу написать запись в файле "hosts", 172.16.0.12чтобы сделать это. Но как Microsoft DNS serverраспознать этот файл "hosts"?

Может быть, вы предлагаете, почему бы не использовать интранет 172.16.0.10для доступа к моему почтовому серверу? Я должен сказать, что это неудобно, предположим, что пользователь (сотрудник) работает на своем ноутбуке, днем ​​в офисе и ночью дома. Когда он дома, он не может использовать 172.16.0.10.

Создание зоны для nlscan.comнашего внутреннего DNS serverсервера не представляется возможным, поскольку сервер имен для nlscan.comдомена находится у нашего интернет-провайдера, и он отвечает за разрешение других имен хостов и поддоменов в nlscan.com.

[РЕДАКТИРОВАТЬ]

Как и WesleyDavidпредполагалось, я следую решению просто создать именованную зону mailserver.nlscan.comи поместить безымянную запись A в эту зону . Время доказывает, что это работает хорошо.

Последняя часть этого поста неверна. У меня сложилось впечатление, основываясь на некоторых материалах, которые я прочитал в Интернете (если он есть в Интернете, это должно быть правдой!), Что часть задач службы DNS-сервера Windows по созданию своего кэша заключалась в том, чтобы также загрузить свой файл хоста в кэшировать вместе с данными локальной зоны. Я искал вокруг и не мог найти убедительных доказательств этого. Я проверил теорию на своем собственном компьютере с Server 2008 R2 и обнаружил, что файл hosts не использовался для построения кэша DNS-сервера.

Однако я считаю, что у меня есть немного более элегантное решение, чем у Massimo. Вместо создания официальной зоны для всей зоны nlscan.com, просто создайте зону с именем mailserver.nlscan.com и поместите безымянную запись A в эту зону. Безымянная запись A будет иметь то же имя, что и сама зона, и вы можете дать ей нужный IP-адрес. Все остальные домены под nlscan.com, а также сам nlscan.com будут разрешаться с помощью общедоступного DNS.

Я только что проверил это на своем собственном DNS-сервере Server 2008 R2 и смог разрешить веб-сайт моего друга (nessus.nl) через общедоступные DNS-серверы, но конкретный поддомен (blog.nessus.nl) разрешил IP-адрес Apple.com , Попробуйте и посмотрите, работает ли он для вас.

Старая, неправильная запись начинается:

Если мое понимание верно (РЕДАКТИРОВАТЬ: и это не так), когда кэш DNS встроен в машину Server 2003, он извлекает записи из файла hosts, а также данные зоны. Размещение 172.16.0.10 mailserver.nlscan.comв файле хоста вашего сервера Server 2003 должно решить проблему. Перезапустите службы DNS после изменения файла hosts.

Используйте ipconfig / displaydns на любом компьютере с Windows (в частности, на вашем компьютере с Server 2003 DNS), чтобы просмотреть записи файла хоста. Также имейте в виду, что отрицательные ответы кэшируются на ваших клиентах, поэтому всегда запускайте ipconfig / flushdns на клиентах, с которыми вы экспериментируете. В противном случае вы в конечном итоге подвергнете себя жестокому обращению с различными жесткими объектами, поскольку вы удивляетесь, почему ваши клиенты не могут разрешить имя, которое вы только что ввели в файл зоны / хоста. знак равно

Вы пробовали это и потерпели неудачу?

Желание, чтобы внутренние пользователи получали внутренние IP-адреса для ресурсов, в то время как внешние пользователи получают внешние IP-адреса для этих же ресурсов, является распространенным явлением. Это называется разделенным мозгом DNS. У вас есть один DNS-сервер, подключенный к Интернету, и другой внутренний DNS-сервер для локальных пользователей. Внутренние пользователи используют DHCP в вашей сети, а на вашем DHCP-сервере вы рекламируете внутренний DNS-сервер. Когда ваши пользователи находятся за пределами офиса, их DHCP-сервер назначит их DNS-серверу, который будет знать только о внешней зоне.

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

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

Читайте о разделенном мозге DNS - это нормальный способ справиться с этой ситуацией.

Уэс: Я не уверен, кто вас отозвал, но я хотел бы уточнить использование файла hosts: файл hosts используется компонентом распознавания клиента DNS, а не компонентом DNS-сервера. Запись в файле hosts на DNS-сервере будет использоваться DNS-сервером, когда он выступает в качестве DNS-клиента. Например, запись в файле hosts моего DNS-сервера W2K8 выглядит следующим образом:

1.1.1.1 test.test.com

загружается в кеш DNS-сервера DNS-сервера (не кеш сервера). Если я пингую test.test.com с моего DNS-сервера, он возвращает 1.1.1.1, как и ожидалось. Если я затем запускаю nslookup на DNS-сервере и запрашиваю у него test.test.com, он возвращает правильный общедоступный IP-адрес, зарегистрированный для test.test.com, поскольку клиентский компонент DNS на DNS-сервере теперь запрашивает разрешение у DNS-сервера. (так же, как любой другой DNS-клиент). Это запутанная идея, чтобы обернуть голову, но DNS-сервер также является DNS-клиентом, и когда клиентский компонент DNS запускается в действие, он действует так же, как любой другой DNS-клиент, просматривая собственный кеш DNS-клиента, включая любые предварительно записанные записи. - загруженный из файла hosts. Только когда клиентский компонент DNS использует компонент DNS-сервера (путем запроса настроенных в нем DNS-серверов)

Любой DNS-клиент, запрашивающий DNS-сервер, всегда получает «реальный» ответ, а не запись хостов, поскольку кэш DNS-клиента DNS-сервера используется самим сервером (в качестве DNS-клиента), а не компонентом DNS-сервера.

Насколько я знаю, нет способа заставить Windows DNS использовать hostsфайл для обработки разрешения имен; но это не нужно.

Вы можете безопасно создать зону на своем внутреннем DNS-сервере с тем же именем, что и общедоступная интернет-зона; что произойдет, ваш сервер будет обрабатывать запросы на имена в этой зоне, используя свои собственные данные, вместо того, чтобы пересылать эти запросы авторитетным серверам имен для этой зоны; это иногда называют «теневым копированием», потому что это делает «настоящую» публичную зону недоступной для внутреннего клиента, вместо этого отвечая «поддельными» данными.

Вы должны быть осторожны: вы должны заполнить эту внутреннюю зону всеми необходимыми именами, даже используя публичные IP-адреса, где это необходимо; в противном случае внутренние клиенты не смогут разрешить эти имена.

Допустим, ваша публичная зона выглядит так:

www.nlscan.com    202.101.116.8
mail.nlscan.com   202.101.116.9

Вы хотите, чтобы внутренние клиенты разрешали mail.nlscan.com как 172.16.0.10; это нормально, поэтому вы создаете зону «nlscan.com» на своем внутреннем DNS-сервере и помещаете в нее «mail.nlscan.com -> 172.16.0.10».
Но теперь ваши внутренние клиенты не могут разрешить "www.nlscan.com", потому что сервер считает, что он является полномочным для этой зоны, поэтому он не будет отвечать на запрос (потому что он не знает об этом хосте), но также не буду никому пересылать.
Чтобы решить эту проблему, вы должны поместить "www.nlscan.com" тоже внутри вашей внутренней зоны; он может указывать на свой реальный публичный IP-адрес, если вы хотите, чтобы ваши клиенты обращались к нему таким образом, или вы можете использовать то же перенаправление, которое вы используете для «mail.nlscan.com», если «www» также пересылается вашим брандмауэром на какой-то внутренний сервер.
Тот же принцип применим к любому имени в зоне.

Эта настройка не окажет никакого влияния на внешних клиентов или любых ваших пользователей, которые временно находятся за пределами вашей сети, поскольку эта внутренняя «теневая» зона никогда не будет видна из Интернета.

Не обращайте внимания на файл хоста, просто добавьте новую зону в DNS mail.domain.com и добавьте хост в зону. оставьте имя пустым (оно будет автоматически использовать имя зоны) и введите IP-адрес локального почтового сервера ;-)