L'ordinateur du domaine ne peut pas résoudre les noms d'hôte internes, mais nslookup peut
J'ai un ordinateur Windows 7 sur mon domaine qui se comporte bizarrement.
- Il est possible d'envoyer une requête ping à www.google.com
- Il peut envoyer une requête ping aux hôtes internes en utilisant leur adresse IP
- Il peut envoyer une requête ping au contrôleur de domaine/serveur DNS local pour ce bureau en utilisant son nom d'hôte et son adresse IP
- Il ne peut pas cingler d'autres hôtes internes par leur nom d'hôte ou leur nom de domaine complet
- Le client ne s'est pas enregistré dans DNS
nslookuppeut résoudre les noms d'hôtes internes en leurs adresses IP correctes et utilise le bon serveur DNS- Le client obtient ses paramètres IP via DHCP de la même manière que les autres clients - il a une adresse dans le sous-réseau correct, les serveurs DNS corrects sont appliqués et le suffixe correct est ajouté pour résoudre les noms d'hôte
- La connexion réseau de la connexion au réseau local affiche un nom SSID qui était précédemment utilisé dans l'espace qui serait utilisé pour afficher le nom de domaine ou l'état WiFi - voir l'image
![odd Local Area Connection labelling]()
Je suis vraiment perplexe quant à la raison pour laquelle cela pourrait se produire. Étant donné que la résolution DNS interne ne se produit pas, l'ordinateur n'est pas en mesure de communiquer correctement avec le domaine, donc la stratégie de groupe ne peut pas être appliquée et je doute que l'authentification fonctionne correctement.
J'ai essayé d'effacer le cache DNS avec ipconfig /flushdns, désactivation/redémarrage du cache avec netsh stop dnscache. J'ai réinitialisé Winsock et la pile IP et redémarré plusieurs fois sans différence. D'autres clients du même réseau fonctionnent très bien.
La solution de contournement actuelle consiste à placer des entrées dans le fichier hosts pour les hôtes les plus importants pour les services que l'utilisateur peut avoir besoin d'utiliser. Cela a bien fonctionné, mais n'est pas vraiment durable à long terme et ne traite pas de la communication avec Active Directory.
Une idée de comment résoudre ce problème avant de reconstruire la chose?
Mise à jour J'ai installé Wireshark sur l'ordinateur affecté. Quand je fais nslookup domain.local Je vois tout le trafic DNS comme prévu. Quand je fais ping domain.local Je ne vois aucun trafic DNS - aucune demande et aucune réponse. Quand je fais ping www.google.com Je vois à la fois la demande et la réponse DNS.
En outre, il s'agit d'un ordinateur portable avec LAN câblé et sans fil. J'obtiens exactement le même problème lorsque je suis connecté via un réseau local câblé ou via WiFi au réseau interne.
Une chose étrange que j'ai remarquée est que sous le nom de la connexion réseau (réseau local) plutôt que d'afficher le nom de domaine comme je m'y attendais, mais plutôt le nom d'un VLAN que nous utilisions auparavant) . J'hésite à supprimer l'ordinateur du domaine, au cas où je ne pourrais plus le rejoindre. Je préfère essayer d'autres choses avant de suivre une voie qui pourrait impliquer la réinstallation de Windows.
Mise à jour cela semble pertinent
Mise à jour J'ai essayé netsh winsock reset catalog, netsh int ip reset, et sfc scannow dont aucun n'a corrigé le comportement. L'ordinateur ne peut pas quitter et rejoindre le domaine, car il ne peut pas communiquer avec un contrôleur de domaine. ifconfig /registerdns ne fonctionne pas non plus pour la même raison. J'ai également essayé d'arrêter le service client DNS en vain.
TLDR;
1. hosts le fichier remplace DNS.
2. Réinitialiser, actualiser, réinitialiser.
3. Sauvegarder les données, formater, réinstaller
Cela peut être dû à une mauvaise entrée dans le hosts fichier qui se trouve ici:
C:\Windows\System32\drivers\etc\hosts
Assurez-vous de ne pas avoir d'entrée dans le hosts fichier remplaçant domain.local
nslookup domain.local vérifiera le serveur DNS pour une adresse associée à domain.local - cependant si vous avez une entrée dans votre hosts pour domain.local puis ping domain.local utiliserait cette adresse et non celle du DNS.
Cela peut également valoir la peine de réinitialiser quelques éléments :
Réinitialisez les entrées WINSOCK aux paramètres d'installation par défaut:
netsh winsock reset catalog
Réinitialiser la pile TCP/IP aux paramètres d'installation par défaut:netsh int ip reset reset.log
Vider le cache du résolveur DNS:ipconfig /flushdns
Renouveler l'enregistrement du client DNS et actualiser les baux DHCP:ipconfig /registerdns
Table de routage de vidage:route /f(redémarrage nécessaire)
Recherchez les fichiers système corrompus:sfc /scannow
En outre, s'il s'agit vraiment de la même machine que celle du numéro d'origine que vous avez publié dans novembre 2014 , cela peut également valoir la peine de consacrer du temps et des efforts pour formater simplement le disque dur et réinstaller le système d'exploitation . Cela vous ramènera à un état connu qui devrait fonctionner.
J'ai eu le même problème.
J'ai découvert que la mise en œuvre coopérative de la connectivité Microsoft DirectAccess en était la raison.
Faites un clic droit sur l'icône de la barre des tâches et choisissez "Utiliser la résolution DNS locale", puis exécutez une gpupdate et mes problèmes sont résolus.
Si ce n'est pas votre problème, la nature d'un logiciel de connectivité d'assistance (il y en a beaucoup) est défectueuse, mais est très probable.
Meilleures salutations
Keiko
Ce problème est exactement ce que j'avais. Il s'avère que mon certificat pour https://nls.my.domain.com pour la connectivité DirectAccess a été revocké. Par conséquent, mes clients ont utilisé la table de résolution des noms (NRPT) depuis mon réseau local et bloquent toutes les connexions aux ressources internes.
Je voulais juste partager cette information car cela pourrait être le même pour certains d'entre vous.
TL; DR; - Assurez-vous que si votre réseau DHCP publie également IPv6, vous mettez également l'adresse IPv6 du DNS, car cela a priorité sur les configurations statiques IPv4 sous Windows 10.
J'ai rencontré ce problème hier et je voulais partager un autre problème et une solution possibles.
Je reconfigurais le réseau et je me connectais à un routeur plus récent. J'ai rencontré le même problème - tous mes systèmes existants ne pouvaient plus atteindre l'AD en utilisant mydomain.local - cela fonctionnait bien avant.
En parcourant Internet, j'ai essayé différentes choses - le DNS fonctionnait bien. Quand je ferais nslookup, cela lancerait une erreur disons inexistante - mais quand je
nslookup mydomain.local {LOCAL-DNSSERVER-IP} cela résoudrait.
Le problème s'est résolu à avoir vu la résolution, mais j'ai manqué qu'elle renvoyait également une adresse IPv6 lors de cette opération.
Le nouveau routeur par défaut publiait sa propre adresse DNS IPv6 (héritée du modem) qui, même si j'avais un DNS statique assigné pour IPv4, il utilisait celui IPv6 qui allait sur pub-internet pour résoudre, d'où il n'existe pas.
J'ai pris l'adresse IPv6 des serveurs de contrôleur de domaine et ajouté au routeur DHCP pour le DNS IPv6 et la résolution de voila!
J'ai eu un problème très similaire avec mon ordinateur portable dans le réseau de domaine. Je n'ai pas pu me connecter au domaine mais j'ai pu cingler et travailler avec d'autres appareils en utilisant des adresses IP (les noms d'hôte étaient interdits). La modification du fichier hosts était une solution temporaire, mais le faire pour chaque périphérique réseau et ne pas pouvoir/gpupdate était un peu frustrant.
En fin de compte, mon problème (et ma situation, pourrait ne pas s'appliquer au vôtre) a été résolu par ce blog particulier: http://setspn.blogspot.nl/2015/05/corrupt-local-gpo-files. html
- Renommez (ou supprimez) C:\Windows\System32\GroupPolicy\Machine\Registry.pol
- Démarrer> exécuter> cmd (en tant qu'administrateur)
- Gpedit.msc
- Les modèles administratifs ci-dessous modifient un paramètre (peu importe lequel), puis le rétablissent. Cela déclenchera la création d'un nouveau fichier Registry.pol
- gpupdate/force
- Les Gpo devraient maintenant fonctionner correctement.
Le problème réside dans une erreur Registry.pol, en générer une nouvelle a corrigé mon problème et j'ai pu gpupdate! J'espère que cela aide les gens à résoudre les problèmes. Assurez-vous cependant d'avoir supprimé toutes les entrées manuelles du fichier hosts.
Lorsque vous exécutez ipconfig /all quel est le type de noeud? Cela ressemble beaucoup à un mauvais type de nœud et peut-être pas de serveur WINS sur votre réseau, une situation similaire à ce qui est arrivé à cette personne .
S'il n'y a aucun trafic réseau, cela pourrait être un problème avec fichier hosts/lmhosts . Sinon, il pourrait y avoir NetBIOS-NS résolutions de nom en cours, et regarder les détails des paquets pourrait montrer plus d'indices.
J'ai eu le même problème et j'ai pu résoudre ce problème sans reconstruire le PC.
- Propriétés de la carte réseau ouverte
- Propriétés sélectionnées de "Protocole Internet version 4 (TCP/IPv4)"
- Cliquez sur le bouton Avancé de l'onglet Général
- Sélectionné l'onglet WINS
- Dans le paramètre NetBIOS, la sélection par défaut a la description suivante, "Utiliser le paramètre NetBIOS du serveur DHCP. Si une adresse IP statique est utilisée ou si le serveur DHCP ne fournit pas de paramètre NetBIOS, activez NetBIOS sur TCP/IP"
- J'ai changé le paramètre en "Activer NetBIOS sur TCP/IP et j'ai ensuite obtenu des réponses lors du ping du FDQN!
Cela peut être évident. Vérifiez les suffixes DNS appliqués manuellement à 3 endroits, 1 dans les propriétés système et 2 dans (chaque) onglet DNS TCP/IP réseau. Dans un monde parfait, le vôtre devrait ressembler au mien.
Peut également être utile pour enquêter sur secpol.msc> Stratégies du gestionnaire de liste réseau pour déterminer les paramètres de l '"emplacement" qui est détecté
En outre, vous mentionnez qu'il ne s'enregistre pas lui-même dans DNS même après ipconfig/registerdns. Vérifiez le journal système pour l'erreur et publiez ici.
J'ai également vu une situation où PING ajoute automatiquement le suffixe DNS supplémentaire. Pour tester, essayez vos pings avec une fuite. (ping domaine.local.)
