Translate

mardi 30 juin 2009

OCS (R2) et le DNS... (partie 1: la théorie)

Introduction

Comme vous le savez tous, OCS 2007 et OCS 2007 R2 capitalisent sur un système DNS bien provisionné afin de permettre aux clients de pouvoir se connecter automatiquement, en fonction de l'adresse SIP de l'utilisateur.

C'est particulièrement pratique pour plusieurs raisons:
  • Effort d'administration réduit
  • Perception de l'utilisateur, qui apprécie de ne rien avoir à faire (ou presque :))
  • Maniabilité de l'infrastructure

Certes, il est possible de configurer les clients par stratégie de groupe (GPO) afin de reproduire quelque chose de similaire, mais lorsque des changements doivent s'appliquer, cela se complique car les stratégies ne s'appliquent pas immédiatement (utilisateurs connectés en attente de rafraîchissement, utilisateurs mobiles), voire pas du tout (clients hors du domaine, ou externes).

Alors, quels sont les enregistrements DNS qu'un client OC va rechercher lors de son démarrage ?

Il s'agit de ceux-ci:

  • _sipinternaltls._tcp.domaine.com
  • _sipinternal._tcp.domaine.com
  • _sip._tls.domaine.com
  • _sip._tcp.domaine.com
  • sip.domaine.com

Les quatre premiers enregistrements doivent être de type "SRV" (Service Locator), sauf si vous avez changé les ports part défaut, les versions "TLS" doivent pointer vers le port 5061 et les autres vers le port 5060. Le dernier est un enregistrement de type "A" (hôte IPv4).

Je rappelle qu'OCS 2007 et OCS 2007 R2 sont configurés par défaut pour utiliser le port 5061 (SIP sur TLS), il n'est donc pas nécessaire de créer les enregistrements "_sipinternal._tcp" et "_sip._tcp" si vous n'avez pas configuré OCS pour écouter sur ce port. Je reviendrai plus tard sur l'accès distant au travers d'un serveur Edge.

Le problème

Le DNS c'est bien, mais voilà... c'est parfois un casse-tête car tout le monde n'a pas le moyen d'utiliser ce que l'on appelle communément un "split DNS".

En effet, imaginez que votre domaine SIP soit "uc-lab.com": la configuration idéale qu'il corresponde au domaine SMTP utilisé par la messagerie, mais aussi à tout ce qui est visible de l'extérieur... Par exemple www.uc-lab.com.

Dans ce cas, que se passe-t-il ? Afin que la découverte auomatique fonctionne, vous configurez au moins ceci:

  • Sur vos serveurs DNS interne, vous créez une zone DNS nommée "uc-lab.com"
  • Un enregistrement A nommé "sip.uc-lab.com" (notez qu'il est possible d'utiliser autre chose que "sip.domaine.com", l'avantage de cet enregistrement est cependant d'autoriser la configuration automatique si le client ne sait pas faire de requête SRV ou simplement si vous n'avez pas de serveur DNS capable de gérer les SRV -- Ok ok, de nos jours c'est très marginal =°))
  • Un enregistrement SRV "_sipinternaltls._tcp.uc-lab.com" pointant vers "sip.uc-lab.com"

Un fois tout ce petit monde en place, vous confirmez que vous arrivez à vous connecter à OCS, mais se pose alors un autre problème... Lorsque vous voulez accéder au site www.uc-lab.com depuis votre réseau interne, vous vous faites insulter par votre navigateur Web préféré... Aïe... normal puisque votre DNS interne gère désormais la zone "uc-lab.com", si vous utilisiez un redirecteur DNS ou les DNS racines les requêtes vers ceux-ci cessent et donc c'est à votre ou vos serveur(s) interne(s) de répondre. Vu qu'aucun enregistrement nommé "www" n'existe, normal que la recherche de www.uc-lab.com échoue.

Il vous reste alors deux options qui semble "triviales":

  1. Créer un enregistrement A pour www.uc-lab.com - Ok, pourquoi pas, mais cela oblige à une double gestion, ce qui n'est pas toujours une synécure. Imaginez la catastrophe si vous avez des centaines d'enregistrements à gérer sur vos DNS externes !!!
  2. Ne pas utiliser de split DNS, ce qui revient donc à créer ces enregistrements sur une zone DNS externe (sur un DNS public) et de la mettre à disposition en interne (par réplication ou redirection) - Ce n'est pas toujours faisable, et cela pose un autre problème: cela oblige à publier une adresse IP interne sur une zone DNS publique... Ce n'est pas élégant, et pire, un client externe essayera de s'y connecter puisqu'il pourra la résoudre, puis passera à l'enregistrement suivant qui, si tout va bien, sera celui d'un serveur Edge et donc lui permettra de se connecter. Cependant, cela ralentit le processus de connexion.

Ces solutions sont donc à éviter, autant que faire-ce-peut, car voici _LA_ solution.

La (meilleure?) solution

Il suffit de rappeller comment fonctionne le DNS. Basiquement le caractère "." est le séparateur de labels dans le nom complet qualifié de l'enregistrement recherché. Par exemple, dans "sip.uc-lab.com" "sip" est le nom d'hôte (aussi appellé nom relatif), "uc-lab" et "com" sont des labels arbitraires, même si "com" est aussi une zone racine sur Internet (on appelle aussi ce label "extension").

Aussi, peut importe la façon dont ces enregistrements sont stockés par le serveur DNS, ce qui importe, c'est qu'ils puissent être résolus.

Petit exemple, imaginez un nom complet qualifié "serveur.dom1.aa.domaine.com", disons qu'il est de type "A". Quelles sont alors les façons possibles de déclarer cet enregistrements auprès d'un DNS. Il en existe en fait au moins cinq:

  1. Créer une zone "com" puis un enregistrement relatif "serveur.dom1.aa.domaine"
  2. Créer une zone "domaine.com" puis un enregistrement relatif "serveur.dom1.aa"
  3. Créer une zone "aa.domaine.com" puis un enregistrement relatif "serveur.dom1"
  4. Créer une zone "dom1.aa.domaine.com" puis un enregistrement relatif "serveur"
  5. Créer une zone "serveur.dom1.aa.domaine.com" puis en enregistrement relatif "" (nom vide)

L'option #1 est à éviter (à moins de vouloir bloquer *.com :)), les options #2/3/4 sont des classiques, et l'option #5 semble "juste bizarre". C'est pourtant cette façon de déclarer les enregistrements DNS qui va changer la donne et résoudre tous les problèmes... ! :)

Typiquement sur un DNS de type "bind" (ex: sur Unix), cela revient à jouer avec le mot-clef "$ORIGIN" (qui est exposé dans un DNS Windows si vous n'utilisez pas Active Directory pour stocker les informations DNS, mais plutôt un fichier "nomdezone.dns").

Aussi, en reprenant mon exemple avec le domaine "uc-lab.com", il suffit de créer les zones et enregistrements suivants:

  • Zone: "_tcp.uc-lab.com" ==> Enregistrement SRV relatif nommé "_sipinternaltls" pointant vers "sip.uc-lab.com"
  • Zone: "sip.uc-lab.com" ==> Enregistrement A relatif non nommé (chaine vide)

Et voilà, un client DNS n'y verra que du feu et cela permettra de conserver des redirecteurs ou l'utilisation de serveurs DNS racines pour résoudre

Autres applications

Pour OCS, n'oubliez pas si votre déploiement comporte des clients de type Communicator Phone Edition (CPE), ou si vous utilisez Communicator Web Access (CWA), vous devrez créer des enregistrements supplémentaires (les zones sont en gras):

Pour CPE:

  • ucupdates.domaine.com (A)
  • ucupdates-r2.domaine.com (A)
  • _ntp._udp.domaine.com (SRV relatif "_ntp" vers un sevrveur NTP interne)

Pour CWA (optionnel/pas toujours applicable, mais personnellement j'aime avoir le même nom de serveur CWA en interne et en externe):

  • cwa.domaine.com (A)
  • as.cwa.domaine.com (CNAME relatif "as" vers l'enregistrement A racine dans cwa.domaine.com)
  • download.cwa.domaine.com (CNAME relatif "download" vers l'enregistrement A racine dans cwa.domaine.com)

En bonus, si vous avez Exchange 2007 + Outlook 2007 et que vous souhaitez utiliser Outlook Anywhere en interne (ex: clients hors de la forêt AD, mais se connectant depuis les réseaux internes):

  • autodiscover.domaine.com (A représentant l'IP de votre serveur CAS principal ou du load-balancer si vous avez plusieurs CAS)
  • et/ou _autodiscover._tcp.domaine.com (SRV pointant vers le port 443 et le nom d'hôte de votre CAS ou du load-balancer)

Et en externe... ?

Le même principe peut s'appliquer, même si cela ne devrait pas être nécessaire puisque tout peut être géré au sein de la même zone. La différence majeure se situe au niveau des enregistrements SRV, en effet, on préfèrera déclarer les enregistrements suivants:

  • sip.domaine.com (A représentant l'IP du rôle Access Edge du serveur Edge (ou du load-balancer dans le cas d'un pool de serveurs Edge))
  • _sip._tls.domaine.com (SRV pointant vers "sip.domaine.com" sur le port 443 (port par défaut pour l'accès distant des clients OCS au travers du Edge)
  • Et si la fédération est utilisée: _sipfederationtls._tcp.domaine.com (SRV vers "sip.domaine.com" sur le port 5061 si le même serveur Edge est utilisé pour la fédération)

Conclusion

Malgré la longueur ce cet article, le principe est somme toute assez simple, nous verrons dans le prochain article comment mettre tout ceci en oeuvre sur un DNS Windows, avec la console d'administration DNS et l'utilitaire dnscmd.exe...

4 commentaires:

  1. Excellent !! justement je me demandais comment je pouvais faire un dns propre parceque la gestion de split dns me paraissais bien lourde... merci encore ;)

    RépondreSupprimer
  2. En fait je viens de m'appercevoir que c'est impossible sous windows 2008, dans l'enregistrement de type SRV il lui faut absolument un protocol dans la zone il faut l'appeler p.[domaine] et mettre dans le protocol _tc et ca fonctionne ;)

    RépondreSupprimer
  3. J'attend ta partie 2 "pratique" avec impatience...j'attend que ça d'ailleurs ;)

    RépondreSupprimer