Windows ajoutant le suffixe de domaine à toutes les recherches

J'ai un problème DNS récurrent qui a tourmenté nos utilisateurs occasionnant à leurs ordinateurs portables d'ajouter le domaine de notre entreprise à la fin de toutes les requêtes DNS. Le problème se produit uniquement lorsque les utilisateurs sont hors site et il semble être assez aléatoire. Cela fonctionnera un jour, puis à l'improviste, il affichera l'entrée invalide. Cela affecte principalement les utilisateurs de Windows XP mais a récemment été vu sur Vista également. Voici un exemple utilisant nslookup.

C:\Users\Username>nslookup www.yahoo.com 
Server: Linksys
Address: 192.168.0.1

Non-authoritative answer:
Name: www.yahoo.com.EXAMPLE.COM
Address: 192.0.2.99

J'ai remplacé l'adresse IP signalée par un espace réservé, mais je peux vous dire que ce qu'elle renvoie est l' *.entrée par défaut de notre configuration Network Solutions. Puisqu'il www.yahoo.com.EXAMPLE.COMn'existe évidemment pas, cela a du sens. Je pense que l'équipement interne de l'utilisateur fonctionne correctement. En interne, nous exécutons un Active Directory Windows 2k3 avec des serveurs DHCP et DNS basés sur Windows. Finalement, le problème se résout généralement en quelques heures ou plusieurs redémarrages.

Quelqu'un a-t-il déjà vu ce comportement?

Si vous lancez nslookup et activez le débogage, vous verrez que Windows essaie toujours d'ajouter son suffixe en premier.

C:\>nslookup
Default Server:  itads.example.com
Address:  0.0.0.0

> set debug=true
> www.yahoo.com
Server:  itads.example.com
Address:  0.0.0.0

------------
Got answer:
    HEADER:
        opcode = QUERY, id = 2, rcode = NXDOMAIN
        header flags:  response, auth. answer, want recursion, recursion avail.
        questions = 1,  answers = 0,  authority records = 1,  additional = 0

    QUESTIONS:
        www.yahoo.com.example.com, type = A, class = IN
    AUTHORITY RECORDS:
    ->  example.com
        ttl = 3600 (1 hour)
        primary name server = itads.example.com
        responsible mail addr = itads.example.com
        serial  = 12532170
        refresh = 1200 (20 mins)
        retry   = 600 (10 mins)
        expire  = 1209600 (14 days)
        default TTL = 3600 (1 hour)

------------
------------
Got answer:
    HEADER:
        opcode = QUERY, id = 3, rcode = NOERROR
        header flags:  response, want recursion, recursion avail.
        questions = 1,  answers = 4,  authority records = 0,  additional = 0

    QUESTIONS:
        www.yahoo.com, type = A, class = IN
    ANSWERS:
    ->  www.yahoo.com
        canonical name = www.wa1.b.yahoo.com
        ttl = 241 (4 mins 1 sec)
    ->  www.wa1.b.yahoo.com
        canonical name = www-real.wa1.b.yahoo.com
        ttl = 30 (30 secs)
    ->  www-real.wa1.b.yahoo.com
        internet address = 209.131.36.158
        ttl = 30 (30 secs)
    ->  www-real.wa1.b.yahoo.com
        internet address = 209.191.93.52
        ttl = 30 (30 secs)

------------
Non-authoritative answer:
Name:    www-real.wa1.b.yahoo.com
Addresses:  209.131.36.158, 209.191.93.52
Aliases:  www.yahoo.com, www.wa1.b.yahoo.com

Comme vous pouvez le voir ci-dessus, ma machine a d'abord essayé de rechercher www.yahoo.com.example.com, et le serveur DNS a répondu NXDOMAIN(entrée introuvable). Vous pouvez le confirmer en exécutant nslookup www.yahoo.com.(notez le point à la fin de .com!) Et vous verrez qu'il est résolu normalement.

Ce qui se passe, c'est que votre serveur DNS externe répond qu'il a une entrée pour "www.yahoo.com.example.com" et renvoie votre adresse IP pour la racine de votre site. Je ne sais pas quel service vous utilisez, mais je suppose que vous avez un mappage générique qui dit à votre serveur de répondre à toute requête inconnue avec une réponse valide, plutôt que de revenir NXDOMAIN. Vous devez vérifier vos paramètres pour le serveur et vérifiez qu'il est uniquement réglé pour répondre aux requêtes des entrées qu'il a fait ( example.com, www.example.com, mail.example.com, etc.).

N'oubliez pas que DNS fonctionne en vérifiant le serveur configuré et en remontant à partir de là. La requête DNS peut prendre un chemin comme le modèle suivant (bien sûr, ce n'est qu'un exemple, c'est probablement faux): Machine -> DNS du routeur local (linksys) -> ISP DNS -> (2nd ISP DNS?) -> Root Serveur DNS -> TLD DNS -> Votre serveur DNS externe. Quelqu'un sur ce chemin dit que cela www.yahoo.com.example.comexiste. Il y a de fortes chances que ce soit votre serveur DNS externe.

MODIFIER

Je me suis dit que j'inclurais une autre friandise sur le caractère aléatoire que vous mentionnez. Si cela se produit vraiment sporadiquement, vous pouvez avoir un serveur DNS externe mal configuré ou leur FAI peut fournir un service de détournement de DNS. Malheureusement, j'ai vu de plus en plus de FAI résidentiels fournir un "service de recherche" pour les noms de domaine invalides. Étant donné que presque tous les utilisateurs finaux utilisent leurs serveurs DNS FAI, les FAI commencent maintenant à rediriger les entrées de domaine non valides vers une page de recherche - une généralement chargée de publicités, de liens non pertinents et d'un petit "Vouliez-vous dire www.example.com?" avec certains résultats qui peuvent ou non être liés au nom de domaine. Je sais que Verizon et Comcast commencent à le faire, je crois que Quest commence également à le faire. OpenDNS est une autre possibilité, car ils fournissent la même "recherche d'un domaine associé" s'il ne le fait pas.

Mon problème avec le fait de suggérer que le problème, cependant, est le fait que vous dites qu'il renvoie l'adresse de votre enregistrement racine, ce qu'aucun ne ferait s'ils essayaient de le rechercher, ils vous donneraient une IP d'un de leurs serveurs Web pour gérer la recherche.

Après avoir bu au total mes paramètres de registre tcpip Windows 7, j'ai eu le même problème. Dans:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters

assurez-vous que votre entrée pour le domaine est la même que votre entrée pour dhcpdomain, alors vous êtes prêt à partir.

Je me suis débattu sur le même problème, que mes fenêtres ajoutent le suffixe de domaine principal lors de l'utilisation de nslookup. La solution que j'ai trouvée était que l'ajout du point pour la demande empêche Windows de le faire. Donc au lieu d'utiliser:

nslookup yahoo.com 192.168.0.1

utilisation

nslookup yahoo.com. 192.168.0.1.

Selon la source, les autres requêtes ne devraient pas montrer ce comportement.

Source (3e message) ici https://social.technet.microsoft.com/Forums/windows/en-US/a34896f6-d784-4e52-8252-54f6520bc495/dns-queries-all-have-my-internal-domain-- nom-appliqué-aux-requêtes-eg-googlecommydomaincom? forum = winserverNIS

Problème la plupart du temps lié à la configuration des routeurs résidentiels. Dans la configuration générale de ces routeurs, vous trouverez deux champs, le nom du système et le nom de domaine.

Exemple, si votre nom de domaine ISP est x.com et que vous mettez le nom de domaine dans ce champ comme y.com. Le routeur donnera toujours le DNS configuré dans l'interface WAN et LAN comme DNS faisant autorité, mais sans autorité sera donné à partir de ce y.com.

J'ai trouvé la réponse. Dans ce paramètre de registre HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ services \ Tcpip \ Parameters, recherchez la liste de recherche. Double-cliquez dessus et supprimez le contenu de la boîte. Correction du mien. Maintenant, nslookup est correct. J'avais quelque chose d'un employeur que j'utilisais mon ordinateur personnel pour le travail à distance. Je ne travaillerai plus jamais pour cette entreprise. Je trouve toujours des entrées escrocs.

J'ai eu le même problème.

Était fourni par le serveur DHCP

La suppression de la valeur de registre de domaine résout le problème HKLM \ SYSTEM \ CurrentControlSet001 \ Services \ Tcpip \ Parameters

Pour moi, en utilisant bind9 comme serveur de noms local faisant autorité et serveur de noms faisant autorité pour le même domaine, je peux résoudre ce problème en supprimant l' *.example.comenregistrement (commenté ci-dessous).

À partir du fichier de zone /etc/bind/example.com

; *. example.com. EN CNAME example.com. ; GLOBALOK

Cela a été défini pour plus de commodité, sans avoir à définir manuellement tous les sous-domaines redirigés par le port vers la même IP publique.

L'effet secondaire est tel que le parent le décrit. Toutes les requêtes sont résolues à la même adresse IP publique. Les programmes et les services fonctionnent bien, mais nslookup ne renvoie jamais les adresses IP, ce qui est une petite gêne que j'ai supportée pendant six mois avant de découvrir cette page et de me conduire au correctif ci-dessus.