Article
01/21/2015

Détermination des enregistrements DNS requis

Dernière rubrique modifiée : 2012-10-16

Utilisez l’organigramme suivant pour déterminer les enregistrements DNS requis.

Détermination de l’organigramme des enregistrements DNS requis

Organigramme DNS pour l’accès des utilisateurs externes

Important :
Le nom que vous spécifiez doit être identique au nom de l’ordinateur configuré sur le serveur. Par défaut, le nom d’un ordinateur qui n’est pas joint à un domaine est un nom court, pas un nom de domaine complet. L’Générateur de topologies utilise des noms de domaine complets, pas des noms courts. Vous devez donc configurer un suffixe DNS sur le nom de l’ordinateur à déployer en tant que serveur Edge non joint à un domaine. Utilisez uniquement des caractères standard (A–Z, a–z, 0–9 et tirets) lorsque vous assignez des noms de domaine complets à vos serveurs Lync, serveurs Edge et pools. N’utilisez pas de caractères Unicode ni traits de soulignement. Les caractères non standard dans les noms de domaine complets ne sont généralement pas pris en charge par les DNS externes et les autorités publiques de certification (lorsque le nom de domaine complet doit être assigné à l’élément SN (Subject Name) du certificat). Pour plus d’informations sur l’ajout d’un suffixe DNS à un nom d’ordinateur, voir Configurer les enregistrements DNS pour la prise en charge Edge.

Le nom que vous spécifiez doit être identique au nom de l’ordinateur configuré sur le serveur. Par défaut, le nom d’un ordinateur qui n’est pas joint à un domaine est un nom court, pas un nom de domaine complet. L’Générateur de topologies utilise des noms de domaine complets, pas des noms courts. Vous devez donc configurer un suffixe DNS sur le nom de l’ordinateur à déployer en tant que serveur Edge non joint à un domaine. Utilisez uniquement des caractères standard (A–Z, a–z, 0–9 et tirets) lorsque vous assignez des noms de domaine complets à vos serveurs Lync, serveurs Edge et pools. N’utilisez pas de caractères Unicode ni traits de soulignement. Les caractères non standard dans les noms de domaine complets ne sont généralement pas pris en charge par les DNS externes et les autorités publiques de certification (lorsque le nom de domaine complet doit être assigné à l’élément SN (Subject Name) du certificat). Pour plus d’informations sur l’ajout d’un suffixe DNS à un nom d’ordinateur, voir Configurer les enregistrements DNS pour la prise en charge Edge.

Configuration DNS « split-brain » avec Lync Server 2010

De même que la traduction d’adresses réseau (NAT), le terme DNS split-brain est défini de plusieurs façons différentes. Dans ce document, le terme DNS split-brain signifie que la zone DNS d’un espace de noms donné est la même dans le DNS interne que dans le DNS externe. Toutefois, de nombreux enregistrements DNS (SRV et A) contenus dans le DNS interne ne seront pas contenus dans le DNS externe, et inversement. Et dans les cas où le même enregistrement DNS existe à la fois dans le DNS interne et externe (par exemple, www.contoso.com), l’adresse IP renvoyée sera différente en fonction de l’endroit où est effectuée la requête DNS.

Si vous configurez DNS split-brain, les zones interne et externe suivantes contiennent un résumé des types d’enregistrements DNS requis dans chaque zone. Pour plus d’informations, voir Architecture de référence.

DNS interne :

contient une zone DNS appelée contoso.com pour laquelle il fait autorité
La zone interne contoso.com contient :
- Des enregistrements DNS A et SRV pour la configuration automatique du client Microsoft Lync Server 2010 (facultatif)
- Des enregistrements DNS A ou CNAME pour la découverte automatique des services web Lync Server
- Des enregistrements DNS A et SRV pour tous les serveurs internes exécutant Lync Server 2010 dans le réseau d’entreprise
- Des enregistrements DNS A et SRV pour l’interface interne Edge de chaque serveur Edge Lync Server 2010 dans le réseau de périmètre
- Des enregistrements DNS A et SRV pour l’interface interne du proxy inverse de chaque serveur proxy inverse dans le réseau de périmètre
- Tous les serveurs Edge Lync Server 2010 dans le réseau périmètre pointent vers les serveurs DNS internes pour résoudre les requêtes vers contoso.com
- Tous les serveurs et clients exécutant Lync Server 2010 sur le réseau d’entreprise pointent vers les serveurs DNS internes pour résoudre les requêtes à destination de contoso.com

DNS externe :

contient une zone DNS appelée contoso.com pour laquelle il fait autorité
La zone externe contoso.com contient :
- Des enregistrements DNS A et SRV pour la configuration automatique du client Lync Server 2010 (facultatif)
- Des enregistrements DNS A ou CNAME pour la découverte automatique des services web Lync Server
- Des enregistrements DNS A et SRV pour l’interface externe Edge de chaque serveur Edge Lync Server 2010 ou adresse IP virtuelle (VIP) du programme d’équilibrage de la charge dans le réseau de périmètre
- Des enregistrements DNS A et SRV pour l’interface externe du proxy inverse de chaque serveur proxy inverse dans le réseau de périmètre

Comment les clients Microsoft Lync 2010 localisent les services

Au cours de la recherche DNS, les enregistrements SRV sont interrogés en parallèle et retournés au client dans l’ordre suivant (s’ils sont configurés et disponibles) :

_sipinternaltls._tcp.<domaine> : pour les connexions TLS internes
_sipinternal._tcp. <domaine> : pour les connexions TCP internes (uniquement si l’utilisation de TCP est autorisée)
_sip._tls. <domaine> : pour les connexions TLS externes
_sip._tcp. <domaine> : pour les connexions TCP externes (uniquement si l’utilisation de TCP est autorisée)

où <domaine> est le domaine SIP utilisé par vos clients internes. Les deux dernières requêtes sont destinées aux clients qui se connectent depuis l’extérieur de votre réseau interne. Lors de la création d’enregistrements SRV, n’oubliez pas qu’ils doivent pointer vers un enregistrement DNS (A) dans le même domaine que celui sur lequel l’enregistrement DNS SRV est créé. Par exemple, si l’enregistrement SRV se trouve dans contoso.com, l’enregistrement A sur lequel il pointe ne peut pas se trouver dans fabrikam.com, il doit également se trouver dans contoso.com.

À votre première connexion, le client Lync essaie de se connecter à un pool frontal en utilisant chacun des trois enregistrements SRV dans l’ordre, que vous vous connectiez depuis l’intérieur ou l’extérieur de votre réseau. Une fois que le client Lync a établi la connexion, il ajoute l’entrée DNS dans le cache et continue à l’utiliser jusqu’à ce qu’elle ne fonctionne plus. Si le client Lync ne peut pas utiliser la valeur mise dans le cache, il interroge à nouveau DNS pour les enregistrements SRV et remplit à nouveau le cache. Par exemple, ce processus est respecté si vous vous êtes connecté au réseau interne pendant la journée, que vous avez ensuite emmené votre ordinateur portable à la maison et vous êtes connecté en externe.

Une fois l’enregistrement SRV retourné, une requête est exécutée pour l’enregistrement DNS A (par nom de domaine complet) sur le serveur ou le pool frontal associé à l’enregistrement SRV. Si aucun enregistrement n’est détecté au cours de la requête SRV DNS, le client Lync effectue une recherche explicite de sipinternal.<domaine>. Si la recherche explicite ne donne aucun résultat, le client Lync effectue une recherche de sip.<domaine>.

Configuration automatique sans DNS split-brain

Si vous utilisez le DNS split-brain, un utilisateur Lync Server 2010 qui se connecte en interne peut tirer parti de la configuration automatique si la zone DNS interne contient un enregistrement SRV _sipinternaltls._tcp pour chaque domaine SIP utilisé. Toutefois, si vous n’utilisez pas DNS split-brain, la configuration interne automatique des clients Lync ne fonctionnera pas tant qu’une des solutions décrites plus loin dans cette section n’aura pas été mise en œuvre. Ceci est dû au fait que Lync Server 2010 a besoin que l’URI SIP de l’utilisateur corresponde au domaine du pool frontal destiné à la configuration automatique. C’est également le cas avec les versions précédentes de Communicator.

Si par exemple vous avez deux domaines SIP utilisés, les enregistrements DNS SRV suivants seront nécessaires :

Si un utilisateur se connecte en tant que lstest01@contoso.com, l’enregistrement SRV suivant fonctionnera pour la configuration automatique, car le domaine SIP de l’utilisateur (contoso.com) correspond au domaine du pool frontal de configuration automatique :

_sipinternaltls._tcp.contoso.com. 86400 IN SRV 0 0 5061 pool01.contoso.com
Si un utilisateur se connecte en tant que lstest01@fabrikam.com, l’enregistrement DNS SRV suivant fonctionnera pour la configuration automatique du deuxième domaine SIP.

_sipinternaltls._tcp.fabrikam.com. 86400 IN SRV 0 0 5061 pool01.fabrikam.com

À titre de comparaison, si un utilisateur se connecte en tant que lstest01@litwareinc.com, l’enregistrement DNS SRV suivant ne fonctionnera pas pour la configuration automatique, car le domaine SIP du client (litwareinc.com) ne correspond pas au domaine sur lequel se trouve le pool (fabrikam.com) :

_sipinternaltls._tcp.litwareinc.com. 86400 IN SRV 0 0 5061 pool01.fabrikam.com

Si la configuration automatique est requise pour les clients Lync, sélectionnez l’une des options suivantes :

Objets de stratégie de groupe Utilisez les objets de stratégie de groupe (GPO) pour remplir le serveur avec les valeurs correctes.

Remarque :
Cette option n’active pas la configuration automatique, mais automatise le processus de configuration manuelle. Par conséquent, en suivant cette approche, les enregistrements SRV associés à la configuration automatique ne sont pas nécessaires.

Zone interne correspondante Créez une zone dans le DNS interne qui corresponde à la zone DNS externe (par exemple, contoso.com) et créez les enregistrements DNS A correspondant au pool Lync Server 2010 utilisé pour la configuration automatique. Par exemple, si un utilisateur est hébergé sur pool01.contoso.net mais se connecte sur Lync en tant que lstest01@contoso.com, créez une zone DNS interne appelée contoso.com dans laquelle vous créez un enregistrement DNS A pour pool01.contoso.com.
Repérer la zone interne Si la création d’une zone complète dans le DNS interne n’est pas une solution, vous pouvez créer des zones repère (c’est-à-dire dédiées) qui correspondent aux enregistrements SRV requis pour la configuration automatique, et renseigner ces zones à l’aide de dnscmd.exe. Dnscmd.exe est obligatoire car l’interface utilisateur DNS ne prend pas en charge la création de zones repère. Par exemple, si le domaine SIP est contoso.com et que vous avez un pool frontal appelé pool01 contenant deux serveurs frontaux, vous avez besoin des zones repère en enregistrements A suivants dans votre DNS interne :
```
dnscmd . /zoneadd _sipinternaltls._tcp.contoso.com. /dsprimary
dnscmd . /recordadd _sipinternaltls._tcp.contoso.com. @ SRV 0 0 5061 pool01.contoso.com.
dnscmd . /zoneadd pool01.contoso.com. /dsprimary
dnscmd . /recordadd pool01.contoso.com. @ A 192.168.10.90
dnscmd . /recordadd pool01.contoso.com. @ A 192.168.10.91
```
Si votre environnement contient un deuxième domaine SIP (par exemple, fabrikam.com), vous avez besoin des zones repère et des enregistrements A suivants dans votre DNS interne :
```
dnscmd . /zoneadd _sipinternaltls._tcp.fabrikam.com. /dsprimary
dnscmd . /recordadd _sipinternaltls._tcp.fabrikam.com. @ SRV 0 0 5061 pool01.fabrikam.com.
dnscmd . /zoneadd pool01.fabrikam.com. /dsprimary
dnscmd . /recordadd pool01.fabrikam.com. @ A 192.168.10.90
dnscmd . /recordadd pool01.fabrikam.com. @ A 192.168.10.91
```

Remarque :
Le nom de domaine complet du pool frontal apparaît deux fois, mais avec deux adresses IP différentes. Cela est dû à l’utilisation de l’équilibrage de la charge DNS, mais si l’équilibrage de la charge matérielle était utilisé, il n’y aurait qu’une seule entrée de pool frontal. De même, les valeurs du nom de domaine complet du pool frontal entre l’exemple contoso.com et l’exemple fabrikam.com changent, mais les adresses IP sont conservées. La raison est que les utilisateurs qui se connectent à partir de l’un de ces domaines IP utilisent le même pool frontal pour la configuration automatique.

Le nom de domaine complet du pool frontal apparaît deux fois, mais avec deux adresses IP différentes. Cela est dû à l’utilisation de l’équilibrage de la charge DNS, mais si l’équilibrage de la charge matérielle était utilisé, il n’y aurait qu’une seule entrée de pool frontal. De même, les valeurs du nom de domaine complet du pool frontal entre l’exemple contoso.com et l’exemple fabrikam.com changent, mais les adresses IP sont conservées. La raison est que les utilisateurs qui se connectent à partir de l’un de ces domaines IP utilisent le même pool frontal pour la configuration automatique.

Pour plus d’informations, voir l’article de blog DMTF intitulé « Configuration automatique de Communicator et DNS split-brain » à l’adresse https://go.microsoft.com/fwlink/?linkid=200707&clcid=0x40C.

Remarque :
Le contenu des blogs et leurs URL peuvent être modifiés sans préavis.

Comment les clients d’appareils mobiles exécutant Lync 2010 localisent les services

Les clients d’appareils mobiles exécutant Lync 2010 utilisent des enregistrements DNS A ou CNAME de découverte automatique pour localiser les services de mobilité. Lors de la recherche DNS, une tentative de connexion est d’abord effectuée vers le nom de domaine complet associé à l’enregistrement DNS interne (autrement dit, lyncdiscoverinternal. <domaineSIP>). Si aucune connexion ne peut être établie à l’URL interne, une tentative de connexion est établie avec le nom de domaine complet associé à l’enregistrement DNS externe (autrement dit, lyncdiscover. <domaineSIP>). L’URL interne est toujours prioritaire. Si une connexion à l’URL interne est établie, le client utilise le réseau Wi-Fi d’entreprise. Si la connexion à l’URL interne échoue mais qu’une connexion à l’URL externe est établie, le client traverse le proxy inverse et est acheminé vers le serveur frontal ou directeur.

Lorsqu’une connexion est établie, le service de découverte automatique renvoie toutes les URL des services web correspondant au pool d’accueil de l’utilisateur, y compris les URL du service de mobilité. Toutefois, l’URL du service de mobilité interne et l’URL du service de mobilité externe sont toutes deux associées au nom de domaine complet externe des services web. Par conséquent, qu’il soit interne ou externe au réseau, un appareil mobile se connecte toujours au service de mobilité de manière externe, par le biais du proxy inverse.

Conseil :
Bien que la configuration par défaut permette au trafic des clients mobiles de traverser le site externe, vous pouvez modifier les paramètres de façon à retourner uniquement l’URL interne. Dans cette configuration, les utilisateurs peuvent utiliser les applications mobiles Lync sur leur appareil mobile uniquement lorsqu’ils se trouvent sur le réseau d’entreprise. Pour prendre en charge cette configuration, vous devez exécuter l’applet de commande Set-CsMcxConfiguration. Vous devez également configurer les adresses IP virtuelles (VIP) des services web internes sur vos programmes d’équilibrage de la charge matérielle des serveurs frontaux et directeurs pour la persistance basée sur les cookies. Pour plus de détails sur les exigences liées au programme d’équilibrage de la charge matérielle, voir la section « Conditions requises pour le programme d’équilibrage de la charge matérielle du proxy inverse » dans Équilibreurs de charge matérielle. Pour plus de détails sur l’utilisation de Set-CsMcxConfiguration afin de restreindre le trafic des clients mobiles au réseau interne, voir Installation des services de mobilité et de découverte automatique.

Bien que la configuration par défaut permette au trafic des clients mobiles de traverser le site externe, vous pouvez modifier les paramètres de façon à retourner uniquement l’URL interne. Dans cette configuration, les utilisateurs peuvent utiliser les applications mobiles Lync sur leur appareil mobile uniquement lorsqu’ils se trouvent sur le réseau d’entreprise. Pour prendre en charge cette configuration, vous devez exécuter l’applet de commande Set-CsMcxConfiguration. Vous devez également configurer les adresses IP virtuelles (VIP) des services web internes sur vos programmes d’équilibrage de la charge matérielle des serveurs frontaux et directeurs pour la persistance basée sur les cookies. Pour plus de détails sur les exigences liées au programme d’équilibrage de la charge matérielle, voir la section « Conditions requises pour le programme d’équilibrage de la charge matérielle du proxy inverse » dans Équilibreurs de charge matérielle. Pour plus de détails sur l’utilisation de Set-CsMcxConfiguration afin de restreindre le trafic des clients mobiles au réseau interne, voir Installation des services de mobilité et de découverte automatique.

Remarque :
Bien que les applications mobiles puissent également se connecter à d’autres services Lync Server 2010, tels que le service de carnet d’adresses, les demandes web des applications mobiles internes vont au nom de domaine complet web externe uniquement pour le service de mobilité. Cette configuration n’est pas nécessaire pour les autres demandes de services, telles que les demandes de carnet d’adresses.

Bien que les applications mobiles puissent également se connecter à d’autres services Lync Server 2010, tels que le service de carnet d’adresses, les demandes web des applications mobiles internes vont au nom de domaine complet web externe uniquement pour le service de mobilité. Cette configuration n’est pas nécessaire pour les autres demandes de services, telles que les demandes de carnet d’adresses.

Lync 2010 pour appareils mobiles prend également en charge la découverte manuelle des services. Dans ce cas, chaque utilisateur doit configurer les paramètres de l’appareil mobile avec les URI complètes interne et externe du service de découverte automatique, y compris le protocole et le chemin d’accès, comme suit :

https://<nom_domaine_complet_pool_ext>/Autodiscover/autodiscoverservice.svc/Racine pour l’accès externe
https://<nom_domaine_complet_pool_int>/AutoDiscover/AutoDiscover.svc/Racine pour l’accès interne

L’utilisation de la découverte automatique, plutôt que manuelle, est vivement recommandée. Toutefois, le recours aux paramètres manuels est utile pour la résolution des problèmes de connectivité d’appareil mobile. Pour plus de détails sur les enregistrements DNS utilisés pour le service de découverte automatique, voir Conditions préalables techniques pour la mobilité. Pour plus de détails sur la planification de la mobilité, voir Planification de la mobilité.

Équilibrage de charge DNS

L’équilibrage de la charge DNS est généralement implémenté au niveau de l’application. L’application (par exemple un client Lync 2010) essaie de se connecter à un serveur d’un pool en se connectant à l’une des adresses IP résultant de la requête DNS A pour le nom de domaine complet du pool.

Si par exemple il existe trois serveurs frontaux dans un pool appelé pool01.contoso.com, voilà ce qui se produit :

Les clients Lync 2010 interrogent DNS pour pool01.contoso.com, récupèrent trois adresses IP et les mettent dans le cache comme suit (pas nécessairement dans cet ordre) :

pool01.contoso.com      192.168.10.90

pool01.contoso.com      192.168.10.91

pool01.contoso.com      192.168.10.92
Ensuite, le client tente d’établir une connexion TCP sur l’une des adresses IP. En cas d’échec, le client essaie l’adresse IP suivante dans le cache.
Si la connexion TCP aboutit, le client négocie le protocole TLS pour se connecter au serveur frontal.
Si l’opération se termine sans que la connexion aboutisse, l’utilisateur est informé qu’aucun serveur Lync Server 2010 n’est disponible pour le moment.

Remarque :
L’équilibrage de la charge DNS est différent du tourniquet (round robin) DNS (DNS RR) qui fait généralement référence à l’équilibrage de charge en s’appuyant sur DNS pour fournir un ordre d’adresses IP différent correspondant aux serveurs d’un pool. DNS RR active en général uniquement la distribution de la charge, mais n’active pas le basculement. Par exemple, si la connexion à l’adresse IP renvoyée par la requête DNS A échoue, la connexion échoue. Par conséquent, le tourniquet DNS (round robin) seul est moins fiable que l’équilibrage de la charge DNS. Vous pouvez utiliser le tourniquet DNS (round robin) conjointement avec l’équilibrage de la charge DNS.

L’équilibrage de la charge DNS est différent du tourniquet (round robin) DNS (DNS RR) qui fait généralement référence à l’équilibrage de charge en s’appuyant sur DNS pour fournir un ordre d’adresses IP différent correspondant aux serveurs d’un pool. DNS RR active en général uniquement la distribution de la charge, mais n’active pas le basculement. Par exemple, si la connexion à l’adresse IP renvoyée par la requête DNS A échoue, la connexion échoue. Par conséquent, le tourniquet DNS (round robin) seul est moins fiable que l’équilibrage de la charge DNS. Vous pouvez utiliser le tourniquet DNS (round robin) conjointement avec l’équilibrage de la charge DNS.

L’équilibrage de la charge DNS est utilisé dans les cas suivants :

Équilibrage de la charge du trafic SIP et HTTP de serveur à serveur
Équilibrage de la charge des applications des services d’applications de communications unifiées (UCAS) telles que le Standard automatique de conférence, Response Group et le parcage d’appel.
Empêcher les nouvelles connexions aux applications UCAS (également appelé « drainage »)
Équilibrage de la charge de l’ensemble du trafic client-serveur entre les clients et les serveurs Edge

L’équilibrage de la charge DNS ne peut pas être utilisé dans les cas suivants :

Trafic web client à serveur

Équilibrage de la charge DNS et trafic fédéré :

Si plusieurs enregistrements DNS sont retournés pour une requête SRV DNS, le service Edge d’accès choisit toujours l’enregistrement SRV DNS dont la priorité numérique est la plus faible et le poids numérique le plus élevé. Si plusieurs enregistrements SRV DNS de même priorité et de même poids sont renvoyés, le service Edge d’accès choisit l’enregistrement SRV qui est revenu en premier du serveur DNS.

Partager via