У веб-браузері не вдається роздільна здатність DNS, але nslookup успішний

Ми невелика організація на 300 місць зі змішаним середовищем BYOD та Active Directory (Windows Server 2012 Standard, Windows 7 Enterprise), і у нас виникає дуже дивна проблема, пов’язана з відмовами дуже конкретного масштабу для вирішення доменного імені нашої організації на нашому домені -поєднані, керовані фірмою машини. Для цього обговорення я буду використовувати company.com замість нашого доменного імені.

Фон:

• Контролер домену Active Directory знаходиться за адресою 172.16.1.3
• Машина AD / DC також працює на DHCP, DNS та HTTP (IIS)
• Веб-сайти наших організацій на company.com та subdomain.company.com розміщуються IIS на пристрої AD / DC
• У нас є сценарій розділеного DNS, в якому сервер AD / DC використовується для внутрішньої роздільної здатності DNS, але інший, позаміський сервер забезпечує роздільну здатність DNS для публічних запитів
• IP-адреса, що відповідає company.com та subdomain.company.com - це загальнодоступна IP-адреса, яка використовується брандмауером на краю нашої мережі (як на сервері DNS AD / DC, так і на зовнішньому DNS-сервері)
• Брандмауер правильно налаштований для NAT для передачі запитів HTTP та HTTPS, які він отримує за своєю загальнодоступною IP-адресою, до внутрішнього IP-адреси сервера AD / DC і відображає

Сценарій 1:

• Користувач на машині Windows 7 Enterprise підключений до домену підключений безпосередньо до нашої локальної мережі з локальною адресою 172.16.6.100 / 16, виданою сервером DHCP.
• Запис DNS-сервера забезпечується DHCP (172.16.1.3)
• Цей користувач може отримати доступ до веб-сайтів, розміщених на сайті company.com та subdomain.company.com
• Редагувати: nslookup був запущений у цьому сценарії і правильно повертає належний запис DNS з внутрішнього DNS-сервера (172.16.1.3)

Сценарій 2:

• Один і той же користувач на тому ж пристрої Windows 7 Enterprise, який приєднався до дому, йде додому та підключається до Інтернету за допомогою свого житлового провайдера
• Записи IP-сервера та DNS для клієнтської машини забезпечуються DHCP
• Цей користувач може отримати доступ до будь-яких Інтернет-ресурсів, таких як google.com
• Цей користувач не може отримати доступ до веб-сайту за адресою company.com або subdomain.company.com (повертається помилка "хост не вирішено")
• Коли цей користувач запускає nslookup на company.com, він дійсно отримує правильну загальнодоступну IP-адресу, надану DNS
• HTTP / HTTPS запити на IP-адресу успішно, і веб-сторінка повертається належним чином сервером
• Ця проблема переважає у всіх веб-браузерах
• Використання tracert company.com повертає "не в змозі вирішити ім'я цільової системи"
• Використання ping company.com повертає "не вдалося знайти хоста company.com"
• Під час запуску Wireshark на клієнті до / під час невдалого запиту клієнтська машина не надсилає жодних пакетів (або для роздільної здатності DNS, або для початкового запиту HTTP / ping / tracert)
• Перезапуск служби DNS-клієнта не вирішує проблему
• Припинення послуги DNS-клієнта не вирішує проблему
• Використання ipconfig / flushdns не вирішує цю проблему
• Використання маршруту / f не вирішує цю проблему
• Скидання мережевих з'єднань за допомогою скидання netsh int ip не вирішує цю проблему
• Редагувати: nslookup був запущений за цим сценарієм і правильно повертає належну запис DNS з сервера DNS, визначений налаштуваннями DHCP мережі, що використовується користувачем

Сценарій 3:

• Цей самий користувач на персональному (не приєднаному до домену) комп'ютері Windows 7 Professional може мати доступ до веб-сайтів на сайті company.com та subdomain.company.com під час підключення до нашої локальної мережі
• Редагувати: nslookup був запущений у цьому сценарії і правильно повертає належний запис DNS з внутрішнього DNS-сервера (172.16.1.3)

Сценарій 4:

• Цей самий користувач на персональному (не приєднаному до домену) комп'ютері Windows 7 Professional може мати доступ до веб-сайтів на сайті company.com та subdomain.company.com, коли підключається їхня домашня мережа
• Редагувати: nslookup був запущений за цим сценарієм і правильно повертає належну запис DNS з сервера DNS, визначений налаштуваннями DHCP мережі, що використовується користувачем

Заключні примітки:

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

Комп'ютери, що приєдналися до домену, шукатимуть свого постійного струму, а не просто здійснювати пошук на основі DNS. Оскільки домен такий самий, як і загальнодоступний веб-сайт, вони шукатимуть запис SRV, щоб сказати, як дістатися до постійного струму та отримати інформацію про домен. Оскільки у віддаленій мережі немає постійного струму, вони не можуть вирішити цю назву, використовуючи звичайні частини вікна, що знають AD.

Коли ви використовуєте ping або (майже) будь-яку програму Windows, він використовує повний стек IP-адреси Windows, включаючи частини, які спілкуються з AD. Тоді як NSLookup насправді просто запит DNS. Ви перевірили це за допомогою своїх слідів Wireshark, Windows не здійснює пошуку, коли намагається потрапити на company.com, але nslookup показує правильний пошук DNS. Ось чому ви не можете вирішити домен через ping або веб-браузер, але nslookup чудово.

Вирішенням першої частини цього є використання www.company.com для переходу на веб-сайт як всередині, так і зовні, щоб клієнти повністю ігнорували пошук DC.

Рішення другої частини складніше, залежно від того, на що посилається subdomain.company.com як внутрішньо, так і зовні. Чи DC має запис DNS для субдомену, або ці запити просто надсилаються на зовнішній сервер DNS? Якщо у нього є запис DNS, куди ця точка запису?

Я перевірив би файл HOSTS ( http://en.wikipedia.org/wiki/Hosts_%28file%29#Location_in_the_file_system ), який не містить записів для хостів, до яких ви намагаєтесь потрапити. Я думаю, що інструмент NSLOOKUP обходить файл хостів, але веб-браузер не буде.

Я також переконався, що у вас немає проксі-сервера, налаштованого у веб-браузері, оскільки деякі типи проксі також вирішують DNS.

Я б також спробував запустити браузер у його "безпечному режимі" (тобто з усіма додатками та плагінами вимкнено) за допомогою IE ("iexplore -extoff") або Firefox (утримуючи клавішу зсуву при запуску або "firefox -safe-mode").

В ідеалі, якщо можливо, спробуйте з іншим веб-браузером, щоб звузити, чи це веб-браузер чи ОС.

Тоді, якщо я все ще нікуди не дістався, я би перевірив, які послуги пов'язані з мережевим адаптером (божевільний брандмауер із конкретними правилами, що заважають?)

Нарешті, і це залишається все більш малоймовірним, але NSLOOKUP автоматично додає до запиту комп'ютер або підключення конкретного доменного імені. Наприклад, мій маршрутизатор встановлює доменне ім'я як "маршрутизатор", тому будь-який nslookup для чогось типу "matthew" насправді шукає DNS для "matthew.router", можливо, веб-браузер не робить цього .. як ви сказали, що ви зробили пакет захоплення це не звучить так, як це ваша проблема .. але на випадок, якщо ви пропустили його в пакеті захоплення або ваше середовище захоплення було не зовсім правильним :-).

Це я б спробував, і, сподіваюся, це теж допоможе вам :-).