Доменный компьютер не может разрешить внутренние имена хостов, но nslookup может


15

У меня есть компьютер с Windows 7 в моем домене, который ведет себя странно.

  • Можно пинговать www.google.com
  • Он может пинговать внутренние хосты, используя их IP-адрес
  • Он может пропинговать локальный контроллер домена / DNS-сервер для этого офиса, используя свое имя хоста и IP-адрес
  • Он не может пропинговать другие внутренние хосты по их имени хоста или FQDN
  • Клиент не зарегистрировался в DNS
  • nslookup может преобразовывать внутренние имена хостов в правильные IP-адреса и использует правильный DNS-сервер
  • Клиент получает свои настройки IP через DHCP так же, как и другие клиенты - у него есть адрес в правильной подсети, применены правильные DNS-серверы и добавлен правильный суффикс для разрешения имен хостов
  • Сетевое подключение Local Area Connection показывает имя SSID, которое ранее использовалось в пространстве, которое будет использоваться для отображения имени домена или статуса WiFi - см. Изображениенечетная маркировка подключения по локальной сети

Я действительно сбит с толку относительно того, почему это может происходить. Поскольку внутреннее разрешение DNS не происходит, компьютер не может правильно связаться с доменом, поэтому нельзя применить групповую политику, и я сомневаюсь, что проверка подлинности работает правильно.

Я попытался очистить кэш DNS ipconfig /flushdns, отключив / перезапустив кэш с помощью netsh stop dnscache. Я перезагружал Winsock и стек IP и много раз перезагружался без разницы. Другие клиенты в той же сети работают просто отлично.

Текущий обходной путь - поместить записи в файл хостов для наиболее важных хостов для сервисов, которые может понадобиться пользователю. Это работает нормально, но на самом деле не является устойчивым в долгосрочной перспективе и не касается связи с Active Directory.

Любая идея, как это исправить, прежде чем я перестроить вещь?

Обновление Я установил Wireshark на установленный компьютер. Когда я это nslookup domain.localвижу, я вижу весь трафик DNS, как и ожидалось. Когда я это делаю, ping domain.localя вообще не вижу DNS-трафика - ни запроса, ни ответа. Когда я ping www.google.comвижу, я вижу и запрос DNS и ответ.

Также это ноутбук с проводной и беспроводной связью. Я получаю точно такую ​​же проблему при подключении через проводную локальную сеть или через WiFi к внутренней сети.

Странная вещь, которую я заметил, заключается в том, что под именем сетевого подключения (Local Area Network) вместо того, чтобы отображать доменное имя, как я ожидал, вместо имени VLAN, которую мы использовали. Я не решаюсь удалить компьютер из домена, на случай, если я не смогу снова присоединиться к нему. Я предпочел бы попробовать другие вещи, прежде чем идти по пути, который может включать переустановку Windows.

Обновите это выглядит подходящим

Обновление я пробовал netsh winsock reset catalog, netsh int ip resetи sfc scannowни один из них не исправил поведение. Компьютер не может покинуть и снова присоединиться к домену, так как он не может связаться с контроллером домена. ifconfig /registerdnsтакже не работает по той же причине. Я также попытался остановить службу клиента DNS безрезультатно.


Зависит от того, сколько у вас есть времени, но мне было бы любопытно, что покажет захват пакета.
Майк Б

«Список поиска DNS-суффиксов» ipconfig /allвыглядит так, как вы ожидаете?
Эван Андерсон

1
Так как nslookup работает нормально, но при проверке имени домена поиск отсутствует. Может ли быть что-то (опечатка, символ мошеннического пробела) в файле hosts, что приводит к возвращению неверного результата для domain.local?
Mike1980

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

1
nslookupи pingразрешать имена по-разному. Здесь есть хороший список blogs.msdn.com/b/nitinsingh/archive/2013/06/24/… Возможно, у вас есть что-то простое, например, NetBIOS через TCP / IP, отключенный для конкретного хоста?
Jpe

Ответы:


3

TLDR;
1. hostsфайл переопределяет DNS.
2. Сброс, обновление, сброс.
3. Резервное копирование данных, форматирование, переустановка


Это может быть вызвано неправильной записью в hostsфайле, который находится здесь:

C:\Windows\System32\drivers\etc\hosts

Убедитесь, что у вас нет записи в hostsфайле переопределенияdomain.local

nslookup domain.localбудет проверять сервер DNS для адреса , связанного с domain.local - однако , если у вас есть запись в вашем hostsдля domain.localзатем ping domain.localбудет использовать этот адрес , а не один из DNS.


Может также стоить вашего времени сбросить несколько вещей :

Сбросить записи WINSOCK по умолчанию для установки: netsh winsock reset catalog
Сброс стека TCP / IP к настройкам по умолчанию: netsh int ip reset reset.log
очистить кэш распознавателя DNS: ipconfig /flushdns
обновить регистрацию DNS-клиента и обновить аренду DHCP: ipconfig /registerdns
очистить таблицу маршрутизации: route /f(требуется перезагрузка)
Проверить наличие поврежденных системных файлов: sfc /scannow


Кроме того, если это действительно тот же компьютер, что и в оригинальном выпуске, который вы опубликовали в ноябре 2014 года, возможно, стоит потратить время и силы на то, чтобы просто отформатировать жесткий диск и переустановить ОС . Это вернет вас в известное состояние, которое должно работать.


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

1

Эта проблема - именно то, что у меня было. Оказывается, мой сертификат для https://nls.my.domain.com для подключения DirectAccess был отозван. Поэтому мои клиенты использовали таблицу политики разрешения имен (NRPT) из моей локальной сети и блокировали все подключения к внутренним ресурсам.

Просто хотел поделиться этой информацией, как это может быть то же самое для некоторых из вас.


Интересно - если я когда-нибудь увижу это снова, я буду знать, где искать. Срок действия сертификата не истек (Direct Access работал на сотнях других компьютеров), но в следующий раз стоит проверить NRPT.
dunxd

Если сервер сетевых расположений недоступен клиентом, но они находятся в сети, Direct Access может запуститься, и это вызывает проблемы. Благодарность!
dunxd

1

У меня такая же проблема.

Я узнал, что причиной была совместная реализация Microsoft DirectAccess Connectivity.

Щелкните правой кнопкой мыши значок панели задач и выберите «Использовать локальное разрешение DNS», а затем запустите gpupdate и мои проблемы были решены.

Если это не ваша проблема, скорее всего, природа программного обеспечения для подключения (их много) ошибочно.

С наилучшими пожеланиями

Keiko


Благодарю. Мы также используем прямой доступ - я исследую это в следующий раз, когда он появится!
dunxd

1

У меня была очень похожая проблема с моим ноутбуком в доменной сети. Мне не удалось подключиться к домену, но я мог пропинговать и работать с другими устройствами, используя IP-адреса (имена хостов были запрещены). Редактирование файла hosts было временным решением, но делать это для каждого сетевого устройства и отсутствие возможности / gpupdate было своего рода разочарованием.

В конце концов моя проблема (и моя ситуация, возможно, не относится к вашей) была решена этим конкретным блогом: http://setspn.blogspot.nl/2015/05/corrupt-local-gpo-files.html

  • Переименуйте (или удалите) C: \ Windows \ System32 \ GroupPolicy \ Machine \ Registry.pol
  • Пуск> Выполнить> CMD (как администратор)
  • Gpedit.msc
  • Ниже административные шаблоны изменяют (независимо от того, какой) параметр, а затем возвращают его. Это приведет к созданию нового файла registry.pol
  • gpupdate / force
  • Теперь Gpo должны корректно работать.

Проблема связана с ошибкой Registry.pol, создание новой исправило мою проблему, и я смог gpupdate! Надеюсь, что это помогает людям устранять неполадки. Убедитесь, что вы удалили все ручные записи в файле hosts.


1

TL; DR; - Убедитесь, что ваш сетевой DHCP публикует IPv6, а также укажите IPv6-адрес DNS-сервера, поскольку он имеет приоритет над статическими конфигурациями IPv4 в Windows 10.

Я столкнулся с этой проблемой вчера и хотел поделиться другой возможной проблемой и решением.

Я перенастраивал сеть и подключился к более новому роутеру. Я столкнулся с той же проблемой - все мои существующие системы больше не могли достичь AD с помощью mydomain.local - раньше она работала нормально.

Прочесывая интернет, я попробовал пару разных вещей - DNS работал нормально. Когда я делал nslookup, он выдавал ошибку, скажем, несуществующую, но когда я запускал

nslookup mydomain.local {LOCAL-DNSSERVER-IP} это решило бы.

Проблема сводилась к тому, что я видел разрешение, но мне не хватало того, что при этом он возвращал адрес IPv6.

По умолчанию новый маршрутизатор публиковал свой собственный DNS-адрес IPv6 (унаследованный от модема), который, несмотря на то, что у меня был статический DNS, назначенный для IPv4, использовал IPv6, который собирался паб-интернет для разрешения, следовательно, не существует.

Я взял адрес IPv6 серверов контроллеров домена и добавил к маршрутизаторам DHCP для DNS IPv6 и разрешение вуаля!


0

Когда вы запускаете, ipconfig /allкакой тип узла? Похоже, у вас неправильный тип узла и, возможно, нет WINS-сервера в вашей сети, ситуация, аналогичная той, которая произошла с этим человеком .


Ваш ответ - это скорее серия вопросов, а не ответ. Хотя я согласен, проблема может быть в NodeType. Hoverver, который неизвестен без дополнительной информации от @dunxd
Signal15

1
Задавая вопрос, я связался с решением и документацией по тому, что я подозреваю. Несовершенный ответ на несовершенный вопрос (не предоставлено достаточной информации о конфигурации ключа).
dialt0ne

Вы получаете награду. Возможно, это не решило проблему (я не могу знать сейчас, так как мне пришлось предпринять решительные действия), но вы кое-что записали в ответ и предоставили ссылки на полезный материал - я не знал о типе узла раньше и теперь я делаю, так что спасибо.
dunxd

Есть ли у вас WINS-сервер в домене? DHCP распределяет IP-адреса серверов WINS, но сервер WINS фактически не присутствует? Правильно ли установлен тип узла на других узлах? У вас есть тестовая коробка, где вы можете попытаться воссоздать проблему, изменив тип узла для эксперимента? В интересах науки, конечно ...
dialt0ne


0

У меня была та же проблема, и я смог ее решить, не перестраивая компьютер.

  1. Свойства открытого сетевого адаптера
  2. Выбранные свойства «Протокол Интернета версии 4 (TCP / IPv4)»
  3. Нажмите кнопку «Дополнительно» на вкладке «Общие»
  4. Выбранная вкладка WINS
  5. В настройке NetBIOS выбор по умолчанию имеет следующее описание: «Использовать настройку NetBIOS с DHCP-сервера. Если используется статический IP-адрес или DHCP-сервер не предоставляет настройки NetBIOS, включите NetBIOS через TCP / IP».
  6. Я изменил настройку на «Включить NetBIOS через TCP / IP, а затем получил ответы при пинге FDQN!

Я попробую это. Я попытался отключить NetBIOS, но это не решило проблему.
dunxd

0

Это может быть очевидным. Проверьте DNS-суффиксы, примененные вручную, в 3 местах, 1 в Системных свойствах и 2 в (каждая) сетевой вкладке TCP / IP DNS. В идеальном мире ваш должен выглядеть как мой.

Также может быть полезно изучить secpol.msc> Политики диспетчера списка сетей, чтобы определить параметры обнаруживаемого местоположения.

Кроме того, вы упоминаете, что он не регистрирует себя в DNS даже после ipconfig / registerdns. Проверьте системный журнал на наличие ошибок и опубликуйте здесь.

Я также видел ситуацию, когда PING автоматически добавляет дополнительный DNS-суффикс. Чтобы проверить, попробуйте свой пинг с трейлингом. (ping domain.local.)

/superuser/93055/windows-using-the-dns-suffix-search-list-on-all-lookups-even-valid-fqdns-how-t

Компьютерный Суффикс Специфичное соединение


Список сетей и информация о местонахождении сети действительно стоит проверить - спасибо!
dunxd
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.