Détermination de l'environnement DNS

J'ai trouvé ce qui suit ici . Les questions sont: où puis-je find plus de détails sur la façon exacte d' implémenter cela sur Windows? Un guide ou comment faire quelqu'un? Ou peut-être que vous pouvez fournir vos précieuses suggestions?

Plus précisément, comment puis-je faire pour que "tous les servers QA résolvent d'abord les inputs dans qa.example.com en premier et, si cette search échouait, ils essayeraient example.com" (je suis un dev, pas un spécialist du DNS, mais notre Le support informatique a refusé d'aider à cela :()

Utilisez la détermination de l'environnement basé sur DNS pour vos servers. Faites ceci en divisant initialement votre domaine de niveau supérieur en un certain nombre de sous-domaines en fonction de leur fonction, puis en créant des noms de service DNS dans chacun des sous-domaines indiquant le server concerné pour ce service. Sur la base de la list ci-dessus, nous aurions alors:

* clientdb.prod.example.com for Production * clientdb.perf.example.com for Performance Testing * clientdb.qa.example.com for QA * clientdb.dev.example.com for Development 

Les servers résolvent alors les inputs dans leur sous-domaine pertinent par fonction. C'est-à-dire que tous les servers QA résolvent d'abord les inputs dans qa.example.com d'abord et, si cette search a échouée, elles essayeraient example.com. Cela vous permet d'avoir une seule input de configuration pour votre nom de server de database client (clientdb) qui résoudrait correctement dans tous les environnements. Cette technique a l'avantage supplémentaire d'avoir toujours des services globaux définis dans un domaine de niveau supérieur commun.

Cela semble être lié à la fourniture du service DNS "split horizon" . En lisant cela, je vois que j'aurai probablement besoin d'un server DNS distinct pour chaque environnement. Est-ce vrai ou Windows Server 2k8 DNS prend-il en charge une forme de "marquage" des loggings pour être visible en fonction de l'IP du requestur?

Sur le client Windows, dans les parameters NIC, sous TCP, Avancé, onglet DNS; il existe une option pour searchr différents domaines. Par défaut, il est configuré pour utiliser uniquement le suffixe de connection primaire (domaine); mais vous pouvez l'utiliser pour utiliser une list que vous avez définie (assurez-vous d'inclure tous les domaines que vous souhaitez searchr).

Windows Server n'a aucun moyen de baliser les loggings afin que seuls certains clients puissent effectuer une search. Vous pouvez bloquer certains clients d'accéder au server DNS set, mais pas plus fine que celle-ci.

Dans DNS, vous pouvez créer des loggings de noms canoniques pour indiquer le nom de server réel auquel vous souhaitez accéder. Il n'est pas très fréquent d'utiliser ce type de technique dans un réseau interne, mais est un peu commun sur les deployments face à Internet.

Ceci est généralement traité par l'édition de la list de search DNS. Cela varie selon la plate-forme, mais vous pouvez configurer votre DNS pour interroger une série de domaines pour les noms sans domaine. Lors de la résolution de "clientdb" sans aucun domaine, il itera dans la list jusqu'à ce qu'il trouve une résolution. Si votre list de search est la suivante:

 prod.example.com qa.example.com dev.example.com 

Votre client DNS est censé searchr l'adresse IP correcte en demandant ce qui suit:

 clientdb.prod.example.com clientdb.qa.example.com 

Etc. Bien sûr, cela ne fonctionne pas si vous fournissez un FQDN complet pour le service. Sur Windows, cependant, vous pouvez fournir des sous-domaines (ex clientdb.us). Il searchra ce talon (donc il est préférable de ne pas être résolu), mais il sera ensuite itéré via la list de search (clientdb.us.prod.example.com). C'est un hack, et vous ne devriez pas le faire, mais cela fonctionnera sur Windows. Ne sait pas sur Unixes.

Il s'agit d'un paramètre par client.