Як DNS для Windows Server використовує файл хостів для вирішення конкретних імен хостів

[ПРИМІТКА. Рішення цього питання є ідеальним, чимось відхиленим від того, що вказує назва.]

Я стикаюся з невеликою проблемою 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розпізнати цей файл "хостів"?

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

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

[EDIT]

Як було WesleyDavidзапропоновано, я слідую за рішенням просто створити зону з назвою mailserver.nlscan.comта розмістити в цій зоні безіменний запис . Час доводить, що це працює добре.

Остання частина цієї публікації неправильна. Я опинився під враженням, виходячи з деяких речей, які я прочитав в Інтернеті (якщо це в Інтернеті, це повинно бути правдою!), Що частина завдань Сервісу Windows DNS для створення кешу повинна була також завантажити його хост-файл у кеш-пам'ять разом з даними про локальну зону. Я обшукував і не міг знайти важких доказів цього. Я перевірив теорію на власній машині Server 2008 R2 і виявив, що файл хостів не використовувався для створення кешу сервера DNS.

Однак я вважаю, що у мене є трохи більш елегантне рішення, ніж Массімо. Замість того, щоб створювати авторитетну зону для всієї зони nlscan.com, просто створіть зону з назвою mailserver.nlscan.com та поставте безіменний запис у цій зоні. Безіменний Запис матиме те саме ім'я, що і сама зона, і Ви можете надати йому потрібну IP-адресу. Усі інші домени під nlscan.com, а також nlscan.com вирішуватимуться загальнодоступними DNS.

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

Починається старша, неправильна публікація:

Якщо я розумію, правильно (EDIT: а це не так), коли кеш DNS вбудований в машині Server 2003, він забирає записи з файлу хостів, а також дані про зону. Розміщення 172.16.0.10 mailserver.nlscan.comу файлі хостів машини вашого сервера 2003 має вирішити проблему. Перезавантажте служби DNS після зміни файлу хостів.

Використовуйте ipconfig / displaydns на будь-якій машині Windows (зокрема, на сервері DNS на сервері 2003), щоб переглянути записи хост-файлів. Також пам’ятайте, що негативні відповіді зберігаються у ваших клієнтах, тому завжди запускайте ipconfig / flushdns на клієнтах, з якими експериментуєте. Інакше ви зловживаєте собою різними жорсткими об'єктами, оскільки вам цікаво, чому ваші клієнти не можуть вирішити ім’я, яке ви тільки що ввели у файл зони / хостів. =)

Ви пробували це і не вдалося?

Бажання мати внутрішніх користувачів отримувати внутрішні IP-адреси для ресурсів, тоді як зовнішні користувачі отримують зовнішні IP-адреси для тих самих ресурсів. Це називається роздвоєним DNS мозку. У вас є один DNS-сервер, який стикається з Інтернетом, та інший внутрішній DNS-сервер для місцевих користувачів. Внутрішні користувачі використовують DHCP у вашій мережі, а ваш DHCP-сервер ви рекламуєте внутрішній DNS-сервер. Коли ваші користувачі не в офісі, їх DHCP-сервер призначить їх на DNS-сервер, який буде знати лише про зовнішню зону.

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

Нарешті, я не думаю, що у вас буде успіх із проханням сервера DNS обслуговувати записи з файлу хостів на сервері DNS. Сервер DNS обслуговує записи з файлів своїх зон. Файл локальних хостів на цьому сервері DNS розповсюджує записи в кеш розв’язання локального клієнта, застосовний лише до пошуку на цій машині. Ці записи не обслуговуються сервером DNS, який є іншим механізмом.

Читайте про розділений DNS мозку - це нормальний спосіб вирішити цю ситуацію.

Уес: Я не впевнений, хто вас заграв, але я хотів би уточнити використання файлу хостів: Файл хостів використовується компонентом DNS-клієнта, а не компонентом сервера DNS. Запис у файлі хостів на DNS-сервері буде використовуватися DNS-сервером, коли він виступає в ролі клієнта DNS. Наприклад, запис у файлі хостів 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, включаючи будь-які записи попередньо -завантажений з файлу хостів. Тільки тоді, коли клієнтський компонент 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; це нормально, тож ви створюєте на внутрішньому сервері DNS зону "nlscan.com" і вкладаєте в неї "mail.nlscan.com -> 172.16.0.10".
Але тепер ваші внутрішні клієнти не можуть вирішити "www.nlscan.com", оскільки сервер вважає його авторитетним для цієї зони, тому він не відповість на запит (тому що він не знає про цей хост), але також не передаватимемо його нікому.
Щоб вирішити це, вам потрібно помістити "www.nlscan.com" всередину вашої внутрішньої зони; він може вказувати на його справжню загальнодоступну IP-адресу, якщо ви хочете, щоб ваші клієнти мали доступ до нього таким чином, або ви могли б використовувати те саме переспрямування, яке ви використовуєте для "mail.nlscan.com", якщо "www" ваш брандмауер також пересилається на якийсь внутрішній сервер.
Цей же принцип застосовується до будь-якої назви в зоні.

Ця налаштування не матиме жодного впливу на зовнішніх клієнтів або на будь-кого з ваших користувачів, який тимчасово знаходиться поза вашою мережею, оскільки ця внутрішня "тіньова" зона ніколи не буде видно з Інтернету.

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