Résoudre les problèmes liés à l’ID d’événement DNS 4013 (le serveur DNS n’a pas pu charger les zones DNS intégrées à AD)

2025-01-15

Cet article résout l’ID d’événement 4013 connecté dans le journal des événements DNS des contrôleurs de domaine qui hébergent le rôle serveur DNS après le démarrage de Windows.

Numéro de base de connaissances d’origine : 2001093

Symptômes

Sur un ordinateur Windows hébergeant des contrôleurs de domaine Active Directory, les rôles de serveur DNS arrêtent de répondre pendant 15 à 25 minutes. Ce problème se produit après l’affichage du message De préparation des connexions réseau et avant l’affichage de l’invite d’ouverture de session Windows (Ctrl+Alt+Del).

L’ID d’événement DNS 4013 suivant est journalisé dans le journal des événements DNS des contrôleurs de domaine qui hébergent le rôle serveur DNS après le démarrage de Windows :

Event Type: Warning  
Event Source: DNS  
Event Category: None  
Event ID: 4013  
Date: Date  
Time: Time  
User: N/A  
Computer: ComputerName  
Description:  
The DNS server was unable to open the Active Directory. This DNS server is configured to use directory service information and can not operate without access to the directory. The DNS server will wait for the directory to start. If the DNS server is started but the appropriate event has not been logged, then the DNS server is still waiting for the directory to start.

For more information, see Help and Support Center at https://go.microsoft.com/fwlink/events.asp.  
Data:  
0000: <%status code%>

Dans cette entrée de journal, les valeurs de <%Code d’état %> peuvent ne pas être journalisées. Ils incluent, mais ne sont pas limités aux valeurs suivantes :

Hex	Byte	Décimal	Symbolique	Chaîne d’erreur
000025f5	f5 25 00 00	9717	DNS_ERROR_DS_UNAVAILABLE	Le service d’annuaire n’est pas disponible
0000232d	2d 23 00 00	9005	DNS_ERROR_RCODE_REFUSED	Opération DNS refusée.
0000232a	2a 23 00 00	9002	DNS_ERROR_RCODE_SERVER_FAILURE	Échec du serveur DNS.

Exemples de scénarios client

Plusieurs contrôleurs de domaine dans un site Active Directory qui sont redémarrés simultanément.
- Un domaine de contrôleur de domaine à deux domaines est déployé dans le même centre de données.
- Le rôle serveur DNS est installé sur les deux contrôleurs de domaine et héberge des copies intégrées à AD du _msdcs.<domaine> racine de forêt et zones de domaine Active Directory.
- DC1 est configuré pour utiliser DC2 pour le DNS préféré et lui-même pour un autre DNS.
- DC2 est configuré pour utiliser DC1 pour le DNS préféré et lui-même pour d’autres DNS.
- Tous les contrôleurs de domaine disposent d’alimentations électriques ininterruptibles (UPS) et de sauvegardes de générateur électrique.
- Le centre de données subit des pannes de courant fréquentes de 2 à 10 heures. Les appareils UPS conservent le fonctionnement des contrôleurs de domaine jusqu’à ce que les générateurs fournissent de l’alimentation, mais ils ne peuvent pas exécuter le système HVAC. La protection de température intégrée aux ordinateurs de classe de serveur arrête les contrôleurs de domaine lorsque les températures internes atteignent les limites du fabricant.
- Lorsque l’alimentation est finalement restaurée, les contrôleurs de domaine se bloquent pendant 20 minutes. Ce problème se produit après l’affichage des connexions réseau et avant l’affichage de l’invite d’ouverture de session.
- L’ID d’événement DNS 4013 est journalisé dans le journal des événements DNS.
Ouverture du console de gestion DNS (DNSMGMT). MSC) échoue et génère le message d’erreur suivant :

Impossible de contacter le nom> d’ordinateur du serveur<. Erreur : le serveur n’est pas disponible. Voulez-vous l’ajouter de toute façon ?

Ouverture du composant logiciel enfichable Utilisateurs et ordinateurs Active Directory (DSA). MSC) génère le message d’erreur suivant :

Impossible de localiser les informations d’affectation de noms
Contrôleurs de domaine uniques dans un site Active Directory
- Un contrôleur de domaine est déployé dans un site.
- Le rôle serveur DNS est installé et héberge des copies intégrées à AD du _msdcs.<domaine> racine de forêt et zones de domaine Active Directory.
- Le contrôleur de domaine pointe vers lui-même pour le DNS préféré.
- Le contrôleur de domaine n’a aucun autre serveur DNS spécifié ou pointe vers un contrôleur de domaine sur un lien réseau étendu (WAN).
- Le contrôleur de domaine est redémarré en raison d’une panne de courant.
- Pendant le redémarrage, la liaison WAN peut ne pas être opérationnelle.
- Lorsque le contrôleur de domaine est démarré, il peut se bloquer pendant 20 minutes. Ce problème se produit après l’affichage des connexions réseau et avant l’affichage de l’invite d’ouverture de session.
- L’ID d’événement DNS 4013 est journalisé dans le journal des événements DNS.
- Ouverture du console de gestion DNS (DNSMGMT). MSC) échoue et génère le message d’erreur suivant :
  
  Impossible de contacter le nom> d’ordinateur du serveur<. Erreur : le serveur n’est pas disponible. Voulez-vous l’ajouter de toute façon ?
Ouverture du composant logiciel enfichable Utilisateurs et ordinateurs Active Directory (DSA). MSC) génère le message d’erreur suivant :

Les informations d’affectation de noms n’ont pas pu être localisées.

Cause

La copie d’Active Directory dans certains contrôleurs de domaine contient des références à d’autres contrôleurs de domaine dans la forêt. Ces contrôleurs de domaine tentent de répliquer toutes les partitions d’annuaire en local pendant le démarrage de Windows, dans le cadre d’une synchronisation initiale ou d’une synchronisation init.

Dans une tentative de démarrage avec le contenu de zone DNS le plus récent, les serveurs DNS Microsoft qui hébergent des copies intégrées à AD des zones DNS retardent le démarrage du service DNS pendant plusieurs minutes après le démarrage de Windows. Le délai ne se produit pas si Active Directory a terminé sa synchronisation initiale au démarrage de Windows. Pendant ce temps, Active Directory est retardé de la réplication entrante des partitions d’annuaire. La réplication est retardée jusqu’à ce qu’elle puisse résoudre le GUID CNAME de son contrôleur de domaine source en adresse IP sur les serveurs DNS utilisés par le contrôleur de domaine de destination pour la résolution de noms. La durée du blocage lors de la préparation des connexions réseau dépend du nombre de partitions d’annuaire détenues localement résidant dans la copie d’Active Directory d’un contrôleur de domaine. La plupart des contrôleurs de domaine ont au moins les cinq partitions suivantes :

schéma
configuration
domain
partition d’application DNS à l’échelle de la forêt
Partition d’application DNS à l’échelle du domaine

Ces contrôleurs de domaine peuvent également rencontrer un délai de démarrage de 15 à 20 minutes. L’existence de partitions supplémentaires augmente le délai de démarrage.

L’ID d’événement DNS 4013 dans le journal des événements DNS indique que le démarrage du service DNS a été retardé. C’est parce que la réplication entrante des partitions Active Directory n’avait pas eu lieu.

Plusieurs conditions peuvent aggraver les problèmes suivants :

démarrage lent de Windows
journalisation de l’événement DNS 4013 sur les serveurs DNS configurés pour héberger des zones intégrées à AD, qui résident implicitement sur des ordinateurs agissant en tant que contrôleurs de domaine.

Ces conditions sont les suivantes :

Configuration d’un serveur DNS hébergeant des zones DNS intégrées à AD. Sa copie d’Active Directory contient des connaissances d’autres contrôleurs de domaine dans la forêt pour pointer vers elle-même exclusivement pour la résolution de noms DNS.
Configuration d’un serveur DNS hébergeant des zones DNS intégrées à AD. Sa copie d’Active Directory contient des connaissances d’autres contrôleurs de domaine dans la forêt pour pointer les serveurs DNS qui n’existent pas, sont actuellement hors connexion, ne sont pas accessibles sur le réseau ou qui n’hébergent pas les zones et enregistrements requis pour répliquer Active Directory entrant. Les exemples incluent l’enregistrement GUID CNAME du contrôleur de domaine et son enregistrement A ou AAAA hôte correspondant des contrôleurs de domaine sources potentiels.
Démarrage d’un contrôleur de domaine et d’un serveur DNS hébergeant des zones DNS intégrées à AD. Sa copie d’Active Directory contient des connaissances sur d’autres contrôleurs de domaine sur ce qui est effectivement un réseau isolé, car :
- La carte réseau ou la pile réseau sur l’appelant ou l’ordinateur cible est désactivée ou non fonctionnelle.
- Le contrôleur de domaine a été démarré sur un réseau isolé.
- La copie du contrôleur de domaine local d’Active Directory contient des références aux contrôleurs de domaine obsolètes qui n’existent plus sur le réseau.
- La copie du contrôleur de domaine local d’Active Directory contient des références à d’autres contrôleurs de domaine actuellement désactivés.
- Il existe un problème sur le contrôleur de domaine source, le contrôleur de domaine de destination ou l’infrastructure DNS ou réseau. Par conséquent, la copie du contrôleur de domaine local d’Active Directory contient des références à d’autres contrôleurs de domaine qui sont en ligne et accessibles, mais qui ne peuvent pas être répliquées avec succès.

Dans Windows Server 2003 et Windows 2000 Server SP3 ou version ultérieure, les contrôleurs de domaine qui hébergent les rôles maître des opérations doivent également répliquer correctement les modifications entrantes sur la partition d’annuaire qui conserve l’état du rôle maître des opérations. La réplication réussie doit se produire avant que les opérations dépendantes de FSMO puissent être effectuées. Ces synchronisations initiales ont été ajoutées pour garantir que les contrôleurs de domaine étaient en accord avec la propriété du rôle FSMO et l’état du rôle. Les exigences de synchronisation initiales requises pour que les rôles FSMO deviennent opérationnels diffère de la synchronisation initiale décrite dans cet article, où Active Directory doit effectuer une réplication entrante pour démarrer immédiatement le service serveur DNS.

Résolution

Certains contenus Microsoft et externes ont recommandé de définir la valeur Repl Perform Initial Synchronizations de Registre sur 0 pour contourner les exigences de synchronisation initiales dans Active Directory. La sous-clé de Registre spécifique et les valeurs de ce paramètre sont les suivantes :

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
Nom de la valeur : Repl Effectuer des synchronisations initiales
Type de valeur : REG_DWORD
Données de la valeur : 0

Cette modification de configuration n’est pas recommandée pour une utilisation dans des environnements de production ou dans un environnement en cours. L’utilisation de Repl Perform Initial Synchronizations doit être utilisée uniquement dans les situations critiques pour résoudre des problèmes temporaires et spécifiques. Le paramètre par défaut doit être restauré une fois ces problèmes résolus.

Voici d’autres options possibles :

Supprimez les références aux contrôleurs de domaine obsolètes.
Rendre les contrôleurs de domaine hors connexion ou non fonctionnels opérationnels.
Les contrôleurs de domaine hébergeant des zones DNS intégrées à AD ne doivent pas pointer vers un seul contrôleur de domaine et en particulier à eux-mêmes comme DNS préféré pour la résolution de noms.

L’inscription et la résolution de noms DNS pour les contrôleurs de domaine sont une opération relativement légère qui est hautement mise en cache par les clients et serveurs DNS.

La configuration des contrôleurs de domaine pour qu’ils pointent vers l’adresse IP d’un serveur DNS unique, y compris l’adresse de bouclage 127.0.0.1, représente un point de défaillance unique. Ce paramètre est tolérable dans une forêt avec un seul contrôleur de domaine, mais pas dans les forêts avec plusieurs contrôleurs de domaine.

Les contrôleurs de domaine hub-site doivent pointer vers des serveurs DNS dans le même site que eux pour un serveur DNS préféré et un autre serveur DNS, puis enfin vers lui-même en tant que autre serveur DNS secondaire.

Les contrôleurs de domaine de site de branche doivent configurer l’adresse IP du serveur DNS par défaut pour qu’il pointe vers un serveur DNS hub-site, l’autre adresse IP du serveur DNS de site pointant vers un serveur DNS sur site ou un serveur DNS le plus proche, et enfin à lui-même à l’aide de l’adresse de bouclage 127.0.0.1 ou de l’adresse IP statique actuelle.

Le fait de pointer vers des serveurs DNS hub-site réduit le nombre de tronçons requis pour obtenir les enregistrements SRV et HOST du contrôleur de domaine critiques entièrement inscrits. Les contrôleurs de domaine au sein du site hub ont tendance à attirer l’attention la plus administrative, généralement ont la plus grande collection de contrôleurs de domaine dans le même site. Étant donné qu’ils se trouvent sur le même site, répliquez les modifications entre elles :
- toutes les 15 secondes dans Windows Server 2003 ou version ultérieure
- toutes les cinq minutes dans Windows 2000 Server
Ce comportement rend ces enregistrements DNS bien connus.

Les inscriptions d’enregistrements A et AAAA du contrôleur de domaine dynamique peuvent ne pas être désactivées si le contrôleur de domaine d’inscription dans un site de branche ne peut pas être répliqué.

Les ordinateurs membres et les serveurs doivent continuer à pointer vers des serveurs DNS optimaux de site comme DNS préféré. Et ils peuvent pointer vers des serveurs DNS hors site pour une tolérance de panne supplémentaire.

Votre objectif ultime est d’empêcher tout ce qui peut entraîner un déni de service tout en équilibrant les coûts, les risques et l’utilisation du réseau, tels que :
- latence de réplication et échecs de réplication
- défaillances matérielles, défaillances logicielles
- pratiques opérationnelles
- pannes de courant à court et à long terme
- incendie, vol, inondation et tremblements de terre
- événements terroristes
Assurez-vous que les contrôleurs de domaine de destination peuvent résoudre les contrôleurs de domaine sources à l’aide de DNS (par exemple, éviter la secours).

Vous devez vous assurer que les contrôleurs de domaine peuvent résoudre correctement les enregistrements CNAME guidés pour héberger les enregistrements des contrôleurs de domaine sources actuels et potentiels. Cela peut éviter une latence élevée introduite par la logique de secours de résolution de noms.

Les contrôleurs de domaine doivent pointer vers des serveurs DNS qui :
- Sont disponibles au démarrage de Windows.
- Héberger, transférer ou déléguer l'_msdcs.<domaine> racine de forêt et zones de suffixe DNS primaires pour les contrôleurs de domaine sources actuels et potentiels.
- Peut résoudre les enregistrements GUID CNAME actuels (par exemple dded5a29-fc25-4fd8-aa98-7f472fc6f09b._msdcs.contoso.com) et les enregistrements hôtes des contrôleurs de domaine sources actuels et potentiels.
Les enregistrements CNAME manquants, dupliqués ou obsolètes contribuent tous à ce problème. La récupération n’est pas activée sur les serveurs DNS Microsoft par défaut, ce qui augmente la probabilité d’enregistrements hôtes obsolètes. En même temps, la casse DNS peut être configurée trop agressivement, ce qui entraîne le vidage prématuré des enregistrements valides à partir de zones DNS.
Optimisez les contrôleurs de domaine pour le secours de résolution de noms.

L’impossibilité de configurer dns correctement afin que les contrôleurs de domaine puissent résoudre les enregistrements GUID CNAME du contrôleur de domaine pour héberger des enregistrements dans DNS était courant. Pour garantir la réplication de bout en bout des partitions Active Directory, les contrôleurs de domaine Windows Server 2003 SP1 et ultérieur ont été modifiés pour effectuer la secours de résolution de noms :
- du GUID CNAME du contrôleur de domaine au nom d’hôte complet.
- de nom d’hôte complet au nom d’ordinateur NetBIOS.
Les ID d’événement de réplication NTDS 2087 et 2088 dans les journaux d’événements du service d’annuaire indiquent que :
- un contrôleur de domaine de destination n’a pas pu résoudre l’enregistrement GUID CNAME du contrôleur de domaine en un enregistrement hôte.
- la secours de résolution de noms se produit.
Les fichiers WINS, HOST et LMHOST peuvent tous être configurés. Ainsi, les contrôleurs de domaine de destination peuvent résoudre les noms des contrôleurs de domaine sources actuels et potentiels. Parmi les trois solutions, l’utilisation de WINS est plus évolutive, car WINS prend en charge les mises à jour dynamiques.

Les adresses IP et les noms des ordinateurs deviennent inévitablement obsolètes. Ce problème provoque l’invalidation des entrées statiques dans les fichiers HOST et LMHOST au fil du temps. Lorsque ce problème se produit, les requêtes d’un contrôleur de domaine peuvent être résolues de manière incorrecte vers un autre contrôleur de domaine. Et aucune requête de nom n’est observée dans une trace réseau.
Modifiez la valeur de démarrage du service serveur DNS de manière manuelle si vous démarrez dans une configuration incorrecte connue.

Si vous démarrez un contrôleur de domaine dans une configuration incorrecte connue décrite dans cet article, procédez comme suit :
1. Définissez la valeur de démarrage du service SERVEUR DNS sur manuelle.
2. Redémarrez, attendez que le contrôleur de domaine publie.
3. Redémarrez le service serveur DNS.
Si la valeur de démarrage du service serveur DNS est définie sur manuelle, Active Directory n’attend pas que le service serveur DNS démarre.

Considérations supplémentaires

Évitez les points de défaillance uniques.

Voici quelques exemples de points d’échec uniques :
- Configuration d’un contrôleur de domaine pour qu’il pointe vers une adresse IP de serveur DNS unique
- Placer tous les serveurs DNS sur des machines virtuelles invitées sur le même ordinateur hôte physique
- Placer tous les serveurs DNS sur le même site physique
- Limitation de la connectivité réseau de sorte que les contrôleurs de domaine de destination n’ont qu’un seul chemin réseau pour accéder à un serveur KDC ou DNS
Installez suffisamment de serveurs DNS pour les performances de redondance locales, régionales et d’entreprise, mais pas tant que la gestion devient un fardeau. DNS est généralement une opération légère hautement mise en cache par les clients DNS et les serveurs DNS.

Chaque serveur DNS Microsoft exécuté sur du matériel moderne peut satisfaire 10 000 à 20 000 clients par serveur. L’installation du rôle DNS sur chaque contrôleur de domaine peut entraîner un nombre excessif de serveurs DNS dans votre entreprise. Et cela augmentera les coûts.
Décaler les redémarrages de serveurs DNS dans votre entreprise lorsque cela est possible.
- L’installation de certains correctifs logiciels, service packs et applications peut nécessiter un redémarrage.
- Certains clients redémarrent les contrôleurs de domaine selon une planification (tous les sept jours, tous les 30 jours).
- Planifiez les redémarrages et l’installation de logiciels nécessitant un redémarrage, de manière intelligente. Cela permet d’empêcher le seul serveur DNS ou le partenaire de réplication source potentiel vers lequel un contrôleur de domaine de destination pointe vers la résolution de noms, d’être redémarré en même temps.
Si windows Update ou le logiciel de gestion installe des logiciels qui nécessitent un redémarrage, mettez en place les installations sur les contrôleurs de domaine ciblés afin que la moitié des serveurs DNS disponibles que les contrôleurs de domaine pointent pour le redémarrage de la résolution de noms en même temps.
Installez des appareils UPS dans des emplacements stratégiques pour garantir la disponibilité DNS pendant les pannes de courant à court terme.
Augmentez vos serveurs DNS sauvegardés par UPS avec des générateurs sur site.

Pour gérer les pannes étendues, certains clients ont déployé des générateurs électriques sur site pour maintenir les serveurs clés en ligne. Certains clients ont constaté que les générateurs peuvent alimenter des serveurs dans le centre de données, mais pas le système HVAC sur site. L’absence de climatisation peut entraîner l’arrêt des serveurs locaux lorsque les températures internes de l’ordinateur atteignent un certain seuil.

Plus d’informations

Test du 10 mai 2010 par l’équipe de développement Active Directory :

DNS attend NTDS et ne peut pas démarrer tant que la réplication initiale du répertoire n’a pas été terminée. Cela est dû au fait que les données DNS à jour peuvent ne pas encore être répliquées sur le contrôleur de domaine. En revanche, NTDS a besoin de DNS pour résoudre l’adresse IP du contrôleur de domaine source pour la réplication. Supposons que DC1 pointe vers DC2 comme serveur DNS, et DC2 pointe vers DC1 comme serveur DNS. Lorsque DC1 et DC2 redémarrent simultanément, il y aura un démarrage lent en raison de cette dépendance mutuelle. La cause racine de ce démarrage lent est DNSQueryTimeouts.

Si le service serveur DNS s’exécute correctement quand NTDS démarre, NTDS ne prend que deux requêtes DNS pour résoudre l’adresse IP du contrôleur de domaine source :

un pour IPv4
l’autre pour IPv6

Et ces requêtes DNS retournent presque instantanément.

Si le service serveur DNS n’est pas disponible au démarrage de NTDS, NTDS doit envoyer 10 requêtes DNS pour résoudre l’adresse IP :

quatre pour le nom basé sur GUID
quatre pour le nom complet
deux pour le nom d’une seule étiquette

La latence pour chaque requête DNS est contrôlée par DNSQueryTimeouts. Par défaut, DNSQueryTimeouts est défini sur 1 1 2 4 4. Cela signifie que le client DNS attend 12 (1 + 1 + 2 + 4 + 4) secondes pour la réponse du serveur DNS. Chaque source de contexte de nommage prend 120 secondes pour résoudre l’adresse IP. Supposons qu’il existe cinq contextes de nommage (Configuration, Schéma, domaine, ForestDnsZones, DomainDnsZones) et une seule source de réplication. Dans ce scénario, il faudra 850 (170 X 5) secondes, ou supérieur à 14 minutes, pour que NTDS termine la réplication initiale.

Plusieurs tests ont été effectués pour valider le comportement ci-dessus.

Redémarrez le contrôleur de domaine lorsque le serveur DNS est un troisième contrôleur de domaine en ligne. Pour chaque contexte de nommage chaque source, nous avons deux requêtes DNS et elles se sont terminées presque instantanément :

in I_DRSGetNCChanges, NC = CN=Configuration,DC=contoso,DC=com
in getContextBindingHelper, pszAddress = dded5a29-fc25-4fd8-aa98-7f472fc6f09b._msdcs.contoso.com  
in resolveDnsAddressWithFallback  
GUID based DNS name  
in GetIpVxAddrByDnsNameW  
in GetIpAddrByDnsNameHelper  
start GetAddrInfoW: 22:31:40.534  
end   GetAddrInfoW: 22:31:40.534  
in GetIpAddrByDnsNameHelper  
start GetAddrInfoW: 22:31:40.534  
end   GetAddrInfoW: 22:31:40.534

Redémarrez DC1 et DC2 simultanément. DC1 utilise DC2 pour DNS DC2 utilise DC1 pour DNS. Pour chaque contexte de nommage chaque source, nous avons 10 requêtes DNS et chaque requête prend environ 12 secondes :

in I_DRSGetNCChanges, NC = CN=Configuration,DC=contoso,DC=com  
in getContextBindingHelper, pszAddress = dded5a29-fc25-4fd8-aa98-7f472fc6f09b._msdcs.contoso.microsoft.com  
in resolveDnsAddressWithFallback  
GUID based DNS name  
in GetIpVxAddrByDnsNameW  
in GetIpAddrByDnsNameHelper  
start GetAddrInfoW: 22:37:43.066  
end   GetAddrInfoW: 22:37:55.113  
in GetIpAddrByDnsNameHelper  
start GetAddrInfoW: 22:37:55.113  
end   GetAddrInfoW: 22:38:07.131  
in GetIpAddrByDnsNameHelper  
start GetAddrInfoW: 22:38:07.131  
end   GetAddrInfoW: 22:38:19.161  
in GetIpAddrByDnsNameHelper  
start GetAddrInfoW: 22:38:19.176  
 end   GetAddrInfoW: 22:38:31.185  
FQDN  
in GetIpVxAddrByDnsNameW  
in GetIpAddrByDnsNameHelper  
start GetAddrInfoW: 22:38:31.200  
end   GetAddrInfoW: 22:38:43.182  
in GetIpAddrByDnsNameHelper  
start GetAddrInfoW: 22:38:43.182  
end   GetAddrInfoW: 22:38:55.191  
in GetIpAddrByDnsNameHelper  
start GetAddrInfoW: 22:38:55.191  
end   GetAddrInfoW: 22:39:07.216  
in GetIpAddrByDnsNameHelper  
start GetAddrInfoW: 22:39:07.216  
end   GetAddrInfoW: 22:39:19.286  
NetBios  
in GetIpVxAddrByDnsNameW  
in GetIpAddrByDnsNameHelper  
start GetAddrInfoW: 22:39:19.286  
end   GetAddrInfoW: 22:39:31.308d  
in GetIpAddrByDnsNameHelper  
start GetAddrInfoW: 22:39:31.308  
end   GetAddrInfoW: 22:39:43.324

Pour approfondir l’étude de la relation entre DNSQueryTimeouts et le démarrage lent, DNSQueryTimeouts a été défini sur 1 1 2 4 4 pour faire attendre 31 (1 + 1 + 1 + 2 + 4 + 4) secondes. Dans ce test, 31 secondes ont été passées en attente :

in I_DRSGetNCChanges, NC = CN=Configuration,DC=contoso,DC=com  
in getContextBindingHelper, pszAddress = dded5a29-fc25-4fd8-aa98-7f472fc6f09b._msdcs.contoso.com  
in resolveDnsAddressWithFallback  
GUID based DNS name  
in GetIpVxAddrByDnsNameW  
in GetIpAddrByDnsNameHelper  
start GetAddrInfoW: 18:06:48.143  
end   GetAddrInfoW: 18:07:19.158  
in GetIpAddrByDnsNameHelper  
start GetAddrInfoW: 18:07:19.158  
end   GetAddrInfoW: 18:07:50.162  
in GetIpAddrByDnsNameHelper  
start GetAddrInfoW: 18:07:50.162  
end   GetAddrInfoW: 18:08:21.161  
in GetIpAddrByDnsNameHelper  
start GetAddrInfoW: 18:08:21.161  
end   GetAddrInfoW: 18:08:52.158  
FQDN  
in GetIpVxAddrByDnsNameW  
in GetIpAddrByDnsNameHelper  
start GetAddrInfoW: 18:08:52.221  
end   GetAddrInfoW: 18:09:23.231  
in GetIpAddrByDnsNameHelper  
start GetAddrInfoW: 18:09:23.231  
end   GetAddrInfoW: 18:09:54.243  
in GetIpAddrByDnsNameHelper  
start GetAddrInfoW: 18:09:54.243  
end   GetAddrInfoW: 18:10:25.239  
 in GetIpAddrByDnsNameHelper  
start GetAddrInfoW: 18:10:25.239  
end   GetAddrInfoW: 18:10:56.243  
NetBios  
in GetIpVxAddrByDnsNameW  
in GetIpAddrByDnsNameHelper  
start GetAddrInfoW: 18:10:56.243  
end   GetAddrInfoW: 18:11:27.244  
in GetIpAddrByDnsNameHelper  
start GetAddrInfoW: 18:11:27.244  
end   GetAddrInfoW: 18:11:58.265