[ПРИМЕЧАНИЕ: решение этого вопроса идеально, чем-то отличается от того, что указывает название.]
У меня небольшая проблема с Windows Server 2003 DNS service. В своей корпорации я использую DNS-сервер Microsoft (172.16.0.12) для разрешения имен в интрасети моей компании (имя домена заканчивается на dev.nls. разрешение до IP 172.16..), и он также настроен как сервер пересылки DNS для пересылки других доменных имен (например, * .google.com, * .sf.net) на Internet real DNS servers. Этот внутренний DNS-сервер никогда не обслуживает пользователей из внешнего мира.
И у нас есть почтовый сервер (обслуживающий входящую почту для настоящий Интернет-домен @nlscan.com) внутри брандмауэра компании, к которому можно получить доступ любым способом:
172.16.0.10 из внутренней сети.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 в этой зоне . Время показывает, что это хорошо работает.
Последняя часть сообщения неверна. У меня сложилось впечатление, основываясь на некоторых материалах, которые я прочитал в Интернете (если он в сети, это должно быть правдой!), Что часть задач службы Windows DNS Server по созданию своего кеша заключалась в том, чтобы также загрузить файл хоста в cache вместе с данными локальной зоны. Я поискал вокруг и не нашел убедительных доказательств этого. Я проверил теорию на своем собственном компьютере Server 2008 R2 и обнаружил, что файл hosts не использовался для создания кэша DNS-сервера.
Однако я считаю, что у меня есть чуть более элегантное решение, чем у Массимо. Вместо создания авторитетной зоны для всей зоны 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 в файле hosts вашей машины Server 2003 должно решить проблему. После изменения файла hosts перезапустите службы DNS.
Используйте ipconfig / displaydns на любом компьютере с Windows (в частности, на вашем сервере DNS Server 2003), чтобы увидеть записи файла вашего хоста. Также имейте в виду, что отрицательные ответы кэшируются в ваших клиентах, поэтому всегда запускайте 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-серверы, настроенные в его свойствах TCP \ IP, которые должны указывать на себя), кеш 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-адрес локального почтового сервера ;-)