Comment faire pour que Windows Server DNS utilise le fichier hosts pour résoudre des noms d'hôtes spécifiques
[NOTE: La solution de cette question est parfaite, par quelque chose qui s'éloigne de ce que le titre indique.]
Je fais face à un petit problème avec Windows Server 2003 DNS service. Dans ma société, j'exécute un serveur DNS Microsoft (172.16.0.12) pour résoudre le nom de mon intranet d'entreprise (le nom de domaine se termine par dev.nls. résolution à IP 172.16. . ), et il est également configuré en tant que redirecteur DNS pour transférer d'autres noms de domaine (par exemple * .google.com, *. sf.net) à Internet real DNS servers. Ce serveur DNS interne n'a jamais tendance à servir des utilisateurs du monde extérieur.
Et, nous exécutons un serveur de messagerie (qui sert le courrier entrant pour un réel domaine Internet @nlscan.com) à l'intérieur du pare-feu de l'entreprise accessible de l'une ou l'autre manière:
- en vous connectant à
172.16.0.10à partir de l'intranet. - en vous connectant à
mail.nlscan.com(résolu à202.101.116.9) à partir d'Internet.
Notez que 172.16.0.10 et 202.101.116.9 n'est pas la même machine physique. Le 202 l'un est un pare-feu qui fait la redirection de port du port 25 et 110 à l'adresse intranet 172.16.0.10.
Maintenant, ma question: si les utilisateurs du réseau local d'entreprise veulent résoudre mail.nlscan.com, il se résout en 202.101.116.9. C'est correct et réalisable, MAIS PAS BON, car le trafic de messagerie va à la machine pare-feu puis rebondit sur 172.16.0.10. J'espère que notre internal DNS server peut intercepter le nom mail.nlscan.com et résolvez-le en 172.16.0.10. J'espère donc pouvoir écrire une entrée dans le fichier "hosts" sur 172.16.0.12 pour faire ça. Mais comment Microsoft DNS server reconnaître ce fichier "hosts"?
Vous suggérez peut-être pourquoi les utilisateurs de l'intranet devraient utiliser 172.16.0.10 pour accéder à mon serveur de messagerie? Je dois dire que ce n'est pas pratique, supposons qu'un utilisateur (employé) travaille sur son ordinateur portable, de jour au bureau et de nuit à la maison. Lorsqu'il est à la maison, il ne peut pas utiliser 172.16.0.10.
Création d'une zone pour nlscan.com sur notre interne DNS server n'est pas réalisable, car le serveur de noms pour nlscan.com Le domaine est sur notre FAI, et il est responsable de la résolution des autres noms d'hôte et sous-domaines sous nlscan.com.
[ÉDITER]
Comme WesleyDavid l'a suggéré, je suis la solution de simplement créer une zone nommée mailserver.nlscan.com et placez un enregistrement A sans nom dans cette zone . Le temps prouve que cela fonctionne bien.
La dernière partie de ce message est erronée. J'avais l'impression, sur la base de certaines choses que j'avais lues sur le Web (si c'est sur le Web, cela doit être vrai!) Qu'une partie des tâches du service Windows DNS Server pour créer son cache consistait également à charger son fichier hôte dans cache avec ses données de zone locale. J'ai cherché autour et je n'ai pas trouvé de preuves tangibles de cela. J'ai testé la théorie sur ma propre machine Server 2008 R2 et j'ai constaté que le fichier hosts n'était pas utilisé pour créer le cache du serveur DNS.
Cependant, je crois avoir une solution légèrement plus élégante que Massimo. Au lieu de créer une zone faisant autorité pour toute la zone nlscan.com, créez simplement une zone nommée mailserver.nlscan.com et placez un enregistrement A sans nom dans cette zone. L'enregistrement A sans nom aura le même nom que la zone elle-même et vous pouvez lui donner l'adresse IP que vous souhaitez. Tous les autres domaines sous nlscan.com ainsi que nlscan.com lui-même seront résolus par DNS public.
Je viens de tester cela sur mon propre serveur DNS Server 2008 R2 et j'ai pu résoudre le site Web de mon ami (nessus.nl) via des serveurs DNS publics, mais le sous-domaine spécifique (blog.nessus.nl) se résout en une adresse IP Apple.com . Essayez-le et voyez si cela fonctionne pour vous.
n ancien message erroné commence:
Si ma compréhension est correcte (EDIT: et ce n'est pas le cas), lorsque le cache DNS est créé sur la machine Server 2003, il extrait les entrées du fichier hosts ainsi que ses données de zone. Placement 172.16.0.10 mailserver.nlscan.com dans le fichier d'hôtes de votre machine Server 2003 devrait résoudre le problème. Redémarrez vos services DNS après avoir modifié votre fichier d'hôtes.
Utilisez ipconfig/displaydns sur n'importe quelle machine Windows (en particulier, votre machine DNS Server 2003) pour voir vos entrées de fichier hôte. Gardez également à l'esprit que les réponses négatives sont mises en cache dans vos clients, exécutez donc toujours ipconfig/flushdns sur les clients que vous expérimentez. Sinon, vous finirez par vous abuser contre divers objets durs en vous demandant pourquoi vos clients ne peuvent pas résoudre un nom que vous venez de saisir dans un fichier zone/hosts. =)
Avez-vous essayé cela et échoué?
Le souhait que les utilisateurs internes obtiennent des adresses IP internes pour les ressources tandis que les utilisateurs externes obtiennent des adresses IP externes pour ces mêmes ressources est courant. Il est appelé DNS split brain. Vous avez un serveur DNS qui fait face à Internet et un autre serveur DNS interne pour les utilisateurs locaux. Les utilisateurs internes utilisent DHCP sur votre réseau et votre serveur DHCP vous annonce le serveur DNS interne. Lorsque vos utilisateurs sont absents du bureau, leur serveur DHCP les affectera à un serveur DNS qui ne connaîtra que la zone externe.
Vous semblez vouloir partager le DNS du cerveau sans vraiment héberger la zone en interne. Vous suggérez que l'hébergement de la zone en interne est problématique, car vous ne voulez pas que les utilisateurs obtiennent l'IP interne lorsqu'ils travaillent à domicile, mais cela n'a pas de sens, car lorsqu'ils sont à la maison, ils obtiennent leur IP d'un autre serveur DHCP cela ne va pas annoncer votre serveur DNS interne. Il va annoncer le serveur DNS de leur FAI qui ne connaîtra que votre zone externe et ne leur fournira donc que des adresses IP externes.
Enfin, je ne pense pas que vous réussirez à demander à un serveur DNS de servir les enregistrements du fichier hosts sur le serveur DNS. Un serveur DNS sert des enregistrements à partir de ses fichiers de zone. Le fichier d'hôtes local sur ce serveur DNS propage les entrées dans le cache de résolution du client local qui ne s'applique qu'aux recherches sur cette machine. Ces entrées ne sont pas servies par le serveur DNS qui est un mécanisme différent.
Lisez sur DNS du cerveau divisé - c'est la manière normale de gérer cette situation.
Wes: Je ne sais pas qui vous a sonné, mais je voudrais clarifier l'utilisation du fichier hosts: le fichier hosts est utilisé par le composant résolveur client DNS, pas le composant serveur DNS. Une entrée dans le fichier hosts sur un serveur DNS sera utilisée par le serveur DNS lorsqu'il agit en tant que client DNS. Par exemple, une entrée dans le fichier d'hôtes de mon serveur DNS W2K8 comme ceci:
1.1.1.1 test.test.com
est chargé dans le cache client DNS du serveur DNS (et non dans le cache serveur). Si je teste test.test.com depuis mon serveur DNS, il renvoie 1.1.1.1 comme prévu. Si je lance ensuite nslookup sur le serveur DNS et lui demande test.test.com, il renvoie la bonne adresse IP publique enregistrée pour test.test.com car le composant client DNS sur le serveur DNS demande maintenant au composant serveur DNS de résoudre (comme n'importe quel autre client DNS). C'est une idée déroutante d'envelopper votre tête, mais le serveur DNS est également un client DNS et lorsque le composant client DNS est mis en action, il agit comme tout autre client DNS en regardant son propre cache client DNS, y compris toutes les entrées pré -chargé à partir du fichier hosts. Ce n'est que lorsque le composant client DNS utilise le composant serveur DNS (en interrogeant le (s) serveur (s) DNS configuré (s) dans ses propriétés TCP\IP, qui doivent être dirigées vers lui-même) que le cache du serveur DNS sera rempli avec les informations correctes.
Tout client DNS interrogeant le serveur DNS obtiendra toujours la "vraie" réponse et non l'entrée des hôtes car le cache client DNS du serveur DNS est utilisé par le serveur lui-même (en tant que client DNS) et non par le composant serveur DNS.
Peu importe le fichier hôte, ajoutez simplement une nouvelle zone dans le DNS mail.domain.com et ajoutez un hôte dans la zone. laissez le nom vide (il utilisera automatiquement le nom de la zone) et entrez l'adresse IP du serveur de messagerie local ;-)
Pour autant que je sache, il n'y a aucun moyen de faire utiliser Windows DNS le fichier hosts pour gérer la résolution de nom; mais ce n'est pas nécessaire.
Vous pouvez créer en toute sécurité une zone sur votre serveur DNS interne avec le même nom qu'une zone Internet publique; ce qui se passera, c'est que votre serveur traitera les demandes de noms dans cette zone en utilisant ses propres données, au lieu de transmettre ces demandes aux serveurs de noms faisant autorité pour cette zone; ceci est parfois appelé "observation", car il rend la "vraie" zone publique inaccessible au client interne, répondant à la place avec des "fausses" données.
Ce que vous devez faire attention, c'est que vous devez remplir cette zone interne avec tous les noms dont vous aurez besoin, même en utilisant des adresses IP publiques si nécessaire; sinon, les clients internes ne pourront pas résoudre ces noms.
Disons que votre zone publique ressemble à ceci:
www.nlscan.com 202.101.116.8
mail.nlscan.com 202.101.116.9
Vous voulez que les clients internes résolvent mail.nlscan.com comme 172.16.0.10; c'est ok, donc vous créez une zone "nlscan.com" sur votre serveur DNS interne et y mettez "mail.nlscan.com -> 172.16.0.10".
Mais maintenant, vos clients internes ne peuvent pas résoudre "www.nlscan.com", car le serveur pense qu'il fait autorité pour cette zone, il ne répondra donc pas à la requête (car il ne connaît pas cet hôte ), mais il ne le transmettra également à personne.
Pour résoudre ce problème, vous devez également placer "www.nlscan.com" dans votre zone interne; il peut pointer vers sa véritable adresse IP publique si vous souhaitez que vos clients y accèdent de cette façon, ou vous pouvez utiliser la même redirection que vous utilisez pour "mail.nlscan.com", si "www" est également transmis par votre pare-feu à un serveur interne.
Le même principe s'applique à tout nom de la zone.
Cette configuration pas aura un impact sur les clients externes ou sur l'un de vos utilisateurs qui est temporairement en dehors de votre réseau, car cette zone "fantôme" interne ne sera jamais visible depuis Internet.