Exporter (0) Imprimer
Développer tout

Rôle de serveur DNS

Mis à jour: janvier 2008

S'applique à: Windows Server 2008

DNS (Domain Name System) est un système d’appellation d’ordinateurs et de services réseau organisé selon une hiérarchie de domaines. Les réseaux TCP/IP tels qu’Internet utilisent DNS pour localiser des ordinateurs et des services par le biais de noms conviviaux.

Pour faciliter l’utilisation des ressources réseau, des systèmes de noms tels que DNS permettent d’établir une correspondance entre le nom convivial d’un ordinateur ou d’un service et d’autres informations associées à ce nom, comme une adresse IP. Un nom convivial est plus simple à retenir que les adresses numériques qui sont utilisées par les ordinateurs pour communiquer sur un réseau. La plupart des utilisateurs préfèrent recourir à un nom convivial (par exemple, ventes.fabrikam.com) pour trouver un serveur de messagerie ou un serveur Web sur un réseau, plutôt qu’à une adresse IP telle que 157.60.0.1. Lorsqu’un utilisateur entre un nom DNS convivial dans une application, les services DNS résolvent le nom en son adresse numérique.

Quel est le rôle d’un serveur DNS ?

Un serveur DNS assure la résolution de noms des réseaux TCP/IP. En d’autres termes, il permet aux utilisateurs d’ordinateurs clients d’adopter des noms à la place des adresses IP numériques pour identifier les hôtes distants. Un ordinateur client envoie le nom d’un hôte distant à un serveur DNS, lequel répond avec l’adresse IP correspondante. L’ordinateur client peut alors envoyer des messages directement à l’adresse IP de l’hôte distant. Si le serveur DNS ne dispose pas d’une entrée dans sa base de données pour l’hôte distant, il peut répondre au client avec l’adresse d’un serveur DNS qui a plus de chances de posséder des informations sur cet hôte distant, ou il peut interroger l’autre serveur DNS. Ce processus peut intervenir de manière récursive jusqu’à ce que l’ordinateur client reçoive l’adresse IP, ou jusqu’à ce qu’il soit établi que le nom interrogé n’appartient pas à un hôte dans l’espace de noms DNS spécifique.

Le serveur DNS dans le système d’exploitation Windows Server® 2008 se conforme aux normes RFC (Requests for Comments) qui définissent et normalisent le protocole DNS. Étant donné que le service Serveur DNS est conforme aux RFC et qu’il est capable d’utiliser les formats d’enregistrements de ressources et des fichiers de données DNS standard, il peut fonctionner avec la plupart des autres implémentations de serveur DNS, comme celles qui utilisent les logiciels BIND (Berkeley Internet Name Domain).

Qui plus est, le serveur DNS dans Windows Server 2008 présente les avantages suivants dans le contexte d’un réseau Windows® :

  • Prise en charge des services de domaine Active Directory® (AD DS)

    Le système DNS est requis pour la prise en charge des services de domaine Active Directory. Si vous installez le rôle de services de domaine Active Directory sur un serveur, vous pouvez installer et configurer automatiquement un serveur DNS s’il est impossible de localiser un serveur DNS qui répond aux conditions requises des services de domaine Active Directory.

    Les zones DNS peuvent être stockées dans les partitions d’annuaire d’applications ou de domaines des services de domaine Active Directory. Une partition est un conteneur de données dans les services de domaine Active Directory qui distingue les données pour différentes fonctions de réplication. Vous pouvez spécifier dans quelle partition Active Directory la zone doit être stockée, et par conséquent le groupe de contrôleurs de domaine sur lesquels les données de cette zone seront répliquées.

    En règle générale, l’utilisation du service Serveur DNS de Windows Server 2008 est vivement recommandée pour assurer la meilleure intégration et prise en charge possible des services de domaine Active Directory, ainsi que la disponibilité de fonctionnalités de serveur DNS optimisées. Vous pouvez cependant utiliser un autre type de serveur DNS pour prendre en charge le déploiement des services de domaine Active Directory.

  • Zones de stub

    L’exécution du service DNS dans Windows Server 2008 prend en charge un type de zone nommé zone de stub. Une zone de stub est une copie d’une zone qui contient uniquement les enregistrements de ressources nécessaires à l’identification des serveurs DNS de référence de cette zone. Une zone de stub conserve un serveur DNS hébergeant une zone parente comprenant les serveurs DNS de référence de sa zone enfant. Cela contribue à maintenir l’efficacité de la résolution de noms DNS.

  • Intégration à d’autres services réseau Microsoft

    Le service Serveur DNS assure l’intégration à d’autres services et il contient des fonctionnalités qui vont au-delà de celles spécifiées dans les RFC relatives au système DNS. Ces fonctionnalités incluent l’intégration à d’autres services, tels que les services de domaine Active Directory, WINS (Windows Internet Name Service) et DHCP (Dynamic Host Configuration Protocol).

  • Facilité d’administration accrue

    Le composant logiciel enfichable DNS de la console MMC (Microsoft Management Console) offre une interface utilisateur graphique pour la gestion du service Serveur DNS. Qui plus est, plusieurs Assistants de configuration sont proposés pour l’exécution des tâches d’administration de serveur courantes. En complément de la console DNS, d’autres outils sont fournis pour faciliter la gestion et la prise en charge des serveurs et des clients DNS de votre réseau.

  • Prise en charge du protocole de mise à jour dynamique conforme aux RFC

    Les clients peuvent utiliser le service Serveur DNS pour mettre à jour de manière dynamique des enregistrements de ressources sur la base du protocole de mise à jour dynamique (RFC 2136). L’administration DNS est ainsi améliorée en réduisant la durée nécessaire à la gestion manuelle de ces enregistrements. Les ordinateurs exécutant le service Client DNS peuvent inscrire leurs noms DNS et adresses IP de manière dynamique. De plus, le service Serveur DNS et les clients DNS peuvent être configurés pour effectuer des mises à jour dynamiques sécurisées, une fonctionnalité qui autorise uniquement les utilisateurs authentifiés bénéficiant des autorisations appropriées à mettre à jour des enregistrements de ressources sur le serveur. Les mises à jour dynamiques sécurisées sont disponibles uniquement pour les zones qui sont intégrées aux services de domaine Active Directory.

  • Prise en charge du transfert de zone incrémentiel entre les serveurs

    Les transferts de zone répliquent les informations relatives à une partie de l’espace de noms DNS entre des serveurs DNS. Les transferts de zone incrémentiels répliquent uniquement les parties modifiées d’une zone, ce qui permet de préserver la bande passante réseau.

  • Redirecteurs conditionnels

    Le service Serveur DNS étend une configuration standard de redirecteurs à l’aide de redirecteurs conditionnels. Un redirecteur conditionnel est un serveur DNS sur un réseau qui transfère des requêtes DNS en fonction du nom de domaine DNS mentionné dans la requête. Par exemple, il est possible de configurer un serveur DNS de sorte qu’il transfère toutes les requêtes reçues pour les noms se terminant par ventes.fabrikam.com à l’adresse IP d’un serveur DNS spécifique ou aux adresses IP de plusieurs serveurs DNS.

Qui ce rôle serveur peut-il intéresser ?

Pour qu’ils fonctionnent correctement, tous les réseaux TCP/IP, à l’exception des plus simples, doivent accéder à un ou à plusieurs serveurs DNS. Sans la résolution de noms et les autres services assurés par les serveurs DNS, l’accès client aux ordinateurs hôtes distants serait extrêmement difficile. Par exemple, en l’absence d’accès à un serveur DNS, la navigation sur le Web serait pratiquement impossible : la majorité des liens hypertextes publiés sur le Web utilisent le nom DNS des hôtes Web et non leur adresse IP. Le même principe s’applique aux réseaux intranet car les utilisateurs connaissent rarement l’adresse IP des ordinateurs de leur réseau local.

Il peut être intéressant de déployer le service Serveur DNS dans Windows Server 2008 si votre réseau contient l’un des éléments suivants :

  • Ordinateurs liés à un domaine

  • Ordinateurs clients DHCP Windows

  • Ordinateurs connectés à Internet

  • Succursales ou domaines situés sur un réseau étendu

Existe-t-il des considérations particulières ?

Si vous voulez intégrer le service Serveur DNS aux services de domaine Active Directory, vous pouvez installer le service DNS en même temps que les services de domaine Active Directory, ou vous pouvez installer le service DNS après l’installation des services de domaine Active Directory puis intégrer ce service DNS au cours d’une autre procédure. Vous pouvez installer des serveurs DNS sauvegardés dans des fichiers (c’est-à-dire des serveurs DNS qui ne sont pas intégrés aux services de domaine Active Directory) sur n’importe quel ordinateur du réseau. Bien entendu, vous devez prendre en compte la topologie de votre réseau et la répartition du trafic lorsque vous déterminez l’emplacement auquel déployer vos serveurs DNS.

Quelles sont les nouvelles fonctionnalités offertes par ce rôle serveur ?

Le service Serveur DNS dans Windows Server 2008 inclut de nouvelles fonctionnalités ainsi que des fonctionnalités optimisées par rapport au service Serveur DNS qui était disponible sur les systèmes d’exploitation Microsoft® Windows NT® Server, Windows 2000 Server et Windows Server® 2003. Les sections suivantes décrivent ces fonctionnalités.

Chargement en arrière-plan des zones

Les grandes entreprises dotées de zones extrêmement volumineuses qui stockent leurs données DNS dans les services de domaine Active Directory constatent qu’il faut parfois une heure ou plus pour redémarrer un serveur DNS, en raison de la durée d’extraction des données DNS du service d’annuaire. En conséquence, le serveur DNS n’est pas disponible pour traiter les demandes clients pendant toute la durée de chargement des zones intégrées aux services de domaine Active Directory.

Un serveur DNS exécutant Windows Server 2008 charge désormais les données de zone des services de domaine Active Directory en arrière-plan pendant son redémarrage, afin qu’il puisse répondre aux demandes de données d’autres zones. Lorsque le serveur DNS démarre, il effectue les opérations suivantes :

  • Il énumère toutes les zones devant être chargées.

  • Il charge les indications de racine à partir des fichiers ou du stockage des services de domaine Active Directory.

  • Il charge toutes les zones sauvegardées dans des fichiers, c’est-à-dire les zones qui sont stockées dans des fichiers et non dans les services de domaine Active Directory.

  • Il commence à répondre aux requêtes et aux appels de procédures distantes (RPC).

  • Il génère un ou plusieurs threads pour charger les zones stockées dans les services de domaine Active Directory.

Étant donné que la tâche de chargement des zones est opérée par des threads distincts, le serveur DNS est en mesure de répondre aux requêtes pendant le chargement des zones. Si un client DNS demande des données pour un hôte dans une zone qui a déjà été chargée, le serveur DNS répond avec les données (ou, le cas échéant, avec une réponse négative) comme prévu. Si la demande concerne un noeud qui n’a pas encore été chargé en mémoire, le serveur DNS lit les données du noeud à partir des services de domaine Active Directory et met à jour la liste d’enregistrements du noeud en conséquence.

Pourquoi cette fonctionnalité est-elle importante ?

Le serveur DNS peut utiliser le chargement de zone en arrière-plan pour commencer à répondre aux requêtes presque instantanément lorsqu’il redémarre, au lieu d’attendre que ses zones aient été intégralement chargées. Le serveur DNS peut répondre aux requêtes des noeuds qu’il a chargés ou qui peuvent être extraits à partir des services de domaine Active Directory. Cette fonctionnalité présente également un autre avantage lorsque les données de zone sont stockées dans les services de domaine Active Directory et non dans un fichier : l’accès aux services de domaine Active Directory est asynchrone et immédiat lorsqu’une requête est reçue, alors que l’accès aux données de zone basées sur des fichiers s’effectue uniquement par le biais d’une lecture séquentielle du fichier.

Prise en charge des adresses IPv6

Le protocole IP version 6 (IPv6) spécifie des adresses d’une longueur de 128 bits, tandis que les adresses IPv4 ont une longueur de 32 bits. Cette longueur plus importante offre un nombre beaucoup plus élevé d’adresses globales uniques afin de répondre à la croissance exponentielle d’Internet dans le monde.

Les serveurs DNS exécutant Windows Server 2008 gèrent désormais aussi bien les adresses IPv6 que les adresses IPv4. Par exemple, dans le composant logiciel enfichable DNS, chaque fois qu’une adresse IP est tapée ou affichée, l’adresse peut être au format d’adresse IPv4 ou IPv6. L’outil de ligne de commande dnscmd accepte également les adresses dans ces deux formats. En outre, les serveurs DN peuvent désormais envoyer des requêtes récursives aux serveurs IPv6 uniquement, et la liste des redirecteurs du serveur peut contenir à la fois des adresses IPv4 et des adresses IPv6. Les clients DHCP peuvent également inscrire des adresses IPv6 en plus (ou à la place) des adresses IPv4. En dernier lieu, les serveurs DNS prennent désormais en charge l’espace de noms de domaine ip6.arpa pour le mappage inversé.

Pourquoi cette fonctionnalité est-elle importante ?

Le protocole d’adressage IPv6 constitue maintenant un facteur important de la croissance d’Internet. Grâce à la prise en charge de l’adressage IPv6 de Windows Server 2008, les serveurs DNS seront en mesure de gérer les clients DNS actuels et futurs qui sont conçus pour tirer parti des avantages des adresses IPv6.

Comment dois-je me préparer à cette modification ?

Étant donné que les serveurs DNS peuvent désormais renvoyer des enregistrements de ressources hôte (A) IPv4 et des enregistrements de ressources hôte (AAAA) IPv6 en réponse aux requêtes, assurez-vous que le logiciel client DNS sur votre réseau peut traiter les réponses de manière appropriée. Vous devrez peut-être mettre à jour ou remplacer vos anciens logiciels client DNS pour garantir la compatibilité avec cette modification.

Prise en charge des contrôleurs de domaine en lecture seule

Windows Server 2008 introduit un nouveau type de contrôleur de domaine ; le contrôleur de domaine en lecture seule (RODC, Read-Only Domain Controller). Ce type de contrôleur fournit un cliché instantané d’un contrôleur de domaine qui ne peut pas être configuré directement, ce qui le rend moins vulnérable aux attaques. Vous pouvez installer un contrôleur de domaine en lecture seule à des emplacements où il est impossible de garantir la sécurité physique du contrôleur de domaine.

Pour prendre en charge les contrôleurs de domaine en lecture seule, un serveur DNS exécutant Windows Server 2008 gère un nouveau type de zone, la zone en lecture seule principale (également décrite comme la zone de succursale). Lorsqu’un ordinateur est utilisé comme contrôleur de domaine en lecture seule, il réplique une copie complète en lecture seule de toutes les partitions d’annuaire d’applications que le serveur DNS utilise, y compris la partition du domaine, la partition ForestDNSZones et la partition DomainDNSZones. Ainsi, le serveur DNS s’exécutant sur le contrôleur de domaine en lecture seule possède une copie complète en lecture seule des zones DNS stockées sur un contrôleur de domaine central dans ces partitions d’annuaire. L’administrateur d’un contrôleur de domaine en lecture seule peut consulter le contenu d’une zone principale en lecture seule. Cependant, l’administrateur peut modifier le contenu uniquement en modifiant la zone sur le contrôleur de domaine central.

Pourquoi cette fonctionnalité est-elle importante ?

Les services de domaine Active Directory dépendent du service DNS pour procurer des services de résolution de noms aux clients réseau. Les modifications du service Serveur DNS sont requises pour la prise en charge des services de domaine Active Directory sur un contrôleur de domaine en lecture seule.

Zone GlobalNames

À l’heure actuelle, de nombreux clients Microsoft déploient le service WINS sur leurs réseaux. En tant que protocole de résolution de noms, le service WINS est souvent employé comme protocole de résolution de noms secondaire en parallèle au service DNS. WINS est un protocole plus ancien, qui utilise NetBIOS sur TCP/IP (NetBT). Il est donc en passe de devenir obsolète. Toutefois, les organisations continuent d’utiliser le protocole WINS, car elles apprécient ses enregistrements globaux et statiques avec des noms en une partie.

Pour permettre aux organisations d’évoluer vers un environnement qui repose intégralement sur le service DNS (ou pour bénéficier des avantages des noms globaux en une partie dans les réseaux entièrement DNS), le service Serveur DNS dans Windows Server 2008 prend désormais en charge une zone nommée GlobalNames qui contient les noms en une partie. Dans les scénarios types, l’étendue de réplication de cette zone est la forêt entière, ce qui garantit que la zone fournit effectivement des noms uniques en une partie dans l’ensemble de la forêt. En outre, la zone GlobalNames peut gérer la résolution de noms en une partie dans l’ensemble d’une organisation qui contient plusieurs forêts lorsque vous utilisez les enregistrements de ressources SRV (emplacement du service) pour publier l’emplacement de la zone GlobalNames.

Contrairement au service WINS, la zone GlobalNames a pour but d’assurer la résolution de noms en une partie d’un ensemble limité de noms d’hôte (en général, les sites Web et serveurs d’entreprise qui sont gérés de manière centralisée). La zone GlobalNames n’est pas destinée à être utilisée pour la résolution de noms pair à pair, telle que la résolution de noms des stations de travail, et les mises à jour dynamiques dans la zone GlobalNames ne sont pas prises en charge. En fait, la zone GlobalNames sert le plus souvent à contenir les enregistrements de ressources CNAME pour mapper un nom en une partie à un nom de domaine complet. Dans les réseaux qui utilisent actuellement le service WINS, la zone GlobalNames contient généralement les enregistrements de ressources des noms gérés de manière centralisée qui sont déjà configurés de manière statique dans WINS.

Lorsque la zone GlobalNames est déployée, la résolution de noms en une partie opérée par les clients fonctionne comme suit :

  1. Le suffixe DNS principal du client est ajouté au nom en une partie, et la requête est envoyée au serveur DNS.

  2. Si ce nom de domaine complet n’est pas résolu, le client demande la résolution en utilisant ses listes de recherche de suffixe DNS (comme celles spécifiées par la stratégie de groupe) le cas échéant.

  3. Si aucun de ces noms n’est résolu, le client demande la résolution en utilisant le nom en une partie.

  4. Si le nom en une partie apparaît dans la zone GlobalNames, le serveur DNS hébergeant la zone résout le nom. Dans le cas contraire, la requête bascule vers le service WINS.

Il n’est pas nécessaire d’apporter des modifications au logiciel client pour permettre la résolution utilisant le nom en une partie avec cette fonctionnalité.

La zone GlobalNames assure la résolution de noms en une partie uniquement lorsque tous les serveurs DNS faisant autorité exécutent Windows Server 2008. Cependant, les autres serveurs DNS (c’est-à-dire les serveurs ne faisant pas autorité pour une zone) peuvent exécuter d’autres systèmes d’exploitation. Bien entendu, la zone GlobalNames doit être la seule zone portant ce nom dans la forêt.

Pour garantir une évolutivité et des performances optimales, il est recommandé d’intégrer la zone GlobalNames aux services de domaine Active Directory et de configurer chaque serveur DNS faisant autorité avec une copie locale de la zone GlobalNames. L’intégration de la zone GlobalNames aux services de domaine Active Directory est indispensable pour assurer la prise en charge du déploiement de la zone GlobalNames sur plusieurs forêts.

Liste rouge de requêtes globale

La plupart des réseaux TCP/IP prennent en charge la fonctionnalité de mise à jour dynamique de DNS car la mise à jour dynamique est pratique aussi bien pour les administrateurs réseau que pour les utilisateurs. La mise à jour dynamique permet aux ordinateurs clients DNS d’inscrire et mettre à jour de manière dynamique leurs enregistrements de ressources auprès d’un serveur DNS chaque fois qu’un client modifie son adresse réseau ou son nom d’hôte. Cela permet de réduire les tâches d’administration manuelle des enregistrements de zone, en particulier pour les clients qui changent fréquemment d’emplacement et qui utilisent le protocole DHCP pour obtenir une adresse IP. Ceci a toutefois un coût, car un client autorisé peut inscrire tout nom d’hôte inutilisé, même un nom d’hôte qui peut avoir une signification particulière pour certaines applications. Cela peut permettre à un utilisateur malveillant de « détourner » un nom spécial et de diriger certains types de trafics réseau vers son propre ordinateur.

Deux protocoles couramment déployés sont particulièrement vulnérables à ce genre de détournement : le protocole WPAD (Web Proxy Auto-Discovery Protocol) et le protocole ISATAP (Intra-site Automatic Tunnel Addressing Protocol). Même si un réseau ne déploie pas ces protocoles, les clients configurés pour les utiliser sont vulnérables au détournement permis par la mise à jour dynamique. Pour empêcher ce genre de détournement, le rôle de serveur DNS dans Windows Server 2008 inclut une liste rouge de requêtes globale qui peut aider à empêcher un utilisateur malveillant de détourner des noms DNS ayant une signification particulière.

Dans sa configuration par défaut, le service Serveur DNS dans Windows Server 2008 maintient une liste de noms qu’il ignore lorsqu’il reçoit une requête de résolution de nom dans toute zone dans laquelle le serveur fait autorité. Pour cela, le service Serveur DNS compare d’abord les requêtes à la liste. Ensuite, si la partie gauche du nom correspond exactement à une entrée de la liste, le service Serveur DNS répond à la requête comme s’il n’existait aucun enregistrement de ressource, même s’il existe un enregistrement hôte (A) ou hôte (AAAA) dans la zone pour le nom. De cette manière, s’il existe un enregistrement hôte (A) ou hôte (AAAA) dans la zone car un hôte a utilisé la mise à jour dynamique pour s’inscrire avec un nom bloqué, le service Serveur DNS ne résout pas le nom. Le contenu initial de la liste rouge varie selon que les protocoles WPAD et ISATAP sont déjà déployés ou non lorsque vous ajoutez le rôle Serveur DNS à un déploiement Windows Server 2008 existant ou mettez à jour une version antérieure de Windows Server exécutant le service Serveur DNS. De plus, l’outil en ligne de commande dnscmd vous permet d’ajouter ou de supprimer des entrées de la liste ou de désactiver totalement l’application de la liste rouge. Tous les serveurs DNS faisant autorité pour une zone doivent exécuter Windows Server 2008 et doivent être configurés avec la même liste rouge afin de garantir des résultats cohérents lorsque les clients demandent la résolution de noms figurant dans la liste rouge.

Modifications du client DNS

Bien qu’il ne s’agisse pas d’une conséquence directe des modifications du service DNS pour le rôle de serveur DNS, les systèmes d’exploitation Windows Vista® et Windows Server 2008 introduisent des fonctionnalités supplémentaires dans le logiciel client DNS, comme l’indiquent les sections suivantes.

LLMNR

Les clients DNS peuvent utiliser la résolution LLMNR (Link-Local Multicast Name Resolution), également appelée multidiffusion DNS ou mDNS, pour résoudre les noms sur un segment de réseau local lorsqu’un serveur DNS est indisponible. Par exemple, si un routeur tombe en panne, en déconnectant un sous-réseau de tous les serveurs DNS du réseau, les clients du sous-réseau qui prend en charge la résolution LLMNR peuvent poursuivre la résolution de noms de pair à pair jusqu’à ce que la connexion réseau soit rétablie.

Le protocole LLMNR assure non seulement la résolution de noms en cas de défaillance d’un réseau, mais il peut également être utile pour établir des réseaux pair à pair ad hoc (par exemple, dans la salle d’attente d’un aéroport).

Modifications concernant la manière dont les clients localisent les contrôleurs de domaine

Dans certains cas très rares, la manière dont les clients DNS localisent les contrôleurs de domaine peut avoir une incidence sur les performances du réseau :

  • Le composant localisateur de contrôleurs de domaine d’un ordinateur client DNS exécutant Windows Vista ou Windows Server 2008 recherche régulièrement un contrôleur de domaine dans le domaine auquel il appartient. Cette fonctionnalité permet d’éviter les problèmes de performances susceptibles de survenir lorsqu’un client localise son contrôleur durant une période de panne réseau, le client étant ainsi associé à un contrôleur de domaine distant situé sur une liaison à faible débit. Auparavant, cette association persistait tant que le client n’était pas forcé de rechercher un nouveau contrôleur de domaine ; par exemple, lorsque l’ordinateur client était déconnecté du réseau pendant un certain temps. Grâce au renouvellement régulier de son association à un contrôleur de domaine, un client court désormais moins de risques d’être associé à un contrôleur de domaine inapproprié.

  • Un ordinateur client exécutant Windows Vista ou Windows Server 2008 peut être configuré (par programme, avec un paramètre de Registre ou avec la stratégie de groupe) pour identifier le contrôleur de domaine le plus proche au lieu de procéder à des recherches aléatoires. Cette fonctionnalité peut améliorer les performances des réseaux comportant des domaines qui reposent sur des liaisons lentes. Cependant, dans la mesure où l’identification du contrôleur de domaine le plus proche peut entraîner une dégradation des performances du réseau, cette fonctionnalité n’est pas activée par défaut.

Cela vous a-t-il été utile ?
(1500 caractères restants)
Merci pour vos suggestions.

Ajouts de la communauté

AJOUTER
Afficher:
© 2014 Microsoft