Comment System.Net.Sockets effectue-t-il ses recherches DNS dans le contexte de la recherche d'un service WCF?

Question

J'ai une application Web et un service WCF hébergés sur le même serveur de développement Windows 2003. Ils ont chacun leur propre nœud de site Web IIS répondant respectivement aux en-têtes d'hôte drs.displayscreen.web et drs.displayscreen.service. Le fichier hosts contient des entrées pour les deux en-têtes pointant vers 127.0.0.1. Le site Web contient une référence de service à drs.displayscreen.service.

Les deux applications fonctionnent parfaitement lorsque leur pool d'applications utilise le compte 'Service réseau'.

J'ai besoin d'effectuer un traitement COM sous le capot sur le service, donc je veux exécuter les applications sous une identité personnalisée. Les deux sites fonctionnent sur un nouveau pool d'applications.

Quand je change l'identité du pool d'applications pour utiliser un nouveau compte Windows créé dans le but, je reçois l'exception suivante (intérieure): [EndpointNotFoundException: Impossible de se connecter à http://drs.displayscreen.service/Handler.svc. Code d'erreur TCP 10060: Une tentative de connexion a échoué car la partie connectée n'a pas répondu correctement après un certain temps ou la connexion établie a échoué car l'hôte connecté n'a pas répondu à la requête 192.168.98.2:8080. ]

192.168.98.2:8080 est l'adresse d'un serveur DNS qui n'est plus utilisé. Il n'est référencé nulle part dans la solution. Il n'est pas référencé par ipconfig du tout.

Je me suis assuré que le nouveau compte est membre de IIS_WPG et j'ai lancé aspnet_regiis -ga. J'ai également donné au compte l'autorisation explicite de lire le fichier hosts.

Pourquoi l'application tente-t-elle d'utiliser le serveur DNS défunt pour résoudre l'URL temporaire (drs.displayscreen.service) au lieu de l'entrée du fichier hosts? Il doit s'agir d'une autorisation quelconque car il ne présente pas ce problème lors de l'exécution sous le compte de service réseau. Aidez-moi!!

Answer 1

Eh bien, il semble que la réponse pourrait impliquer un bug dans le framework .Net. J'ai trouvé a blog posting qui m'a clued dans le fait que l'implémentation MS .Net de SocketCache.GetSocket peut mettre en cache des sockets non valides et another one qui suggère une solution de contournement/piratage sous la forme d'un paramètre explicite de configuration de ne pas utiliser-proxies.

Nous n'utilisons pas réellement un serveur proxy dans l'environnement où ce problème est apparu, mais il semble que SocketCache.GetSocket soit remplacé ou se comporte différemment lorsque le paramètre ne pas utiliser-proxies est en place. Étrangement, la suppression du paramètre entraîne le retour du problème, si bien que le SocketCache n'est pas réparé lorsqu'un IP/nom d'hôte valide est découvert et utilisé avec succès. Selon l'auteur du premier post mentionné ci-dessus, le bug n'existe pas dans Mono. :)