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)

  • Article

Cet article résout l’ID d’événement 4013 enregistré 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.

S’applique à : Windows Server 2012 R2
Numéro de la base de connaissances d’origine : 2001093

Symptômes

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

  • L’ID d’événement DNS 4013 suivant est enregistré 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 enregistrées. Ou bien, ils incluent, mais ne sont pas limités aux valeurs suivantes :

    Hex Octet 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 clients

  • Plusieurs contrôleurs de domaine dans un site Active Directory qui sont redémarrés simultanément.

    • Un domaine à deux contrôleurs de domaine 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 un AUTRE DNS.
    • Tous les contrôleurs de domaine disposent d’un ondule (OND) et d’un générateur électrique de secours.
    • Le centre de données subit de fréquentes pannes de courant de 2 à 10 heures. Les appareils UPS maintiennent les contrôleurs de domaine en fonctionnement 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 la température intégrée aux ordinateurs de classe 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 de La préparation des connexions réseau et avant l’affichage de l’invite d’ouverture de session.
    • L’ID d’événement DNS 4013 est enregistré 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> de l’ordinateur du serveur<. L’erreur était : Le serveur n’est pas disponible. Voulez-vous l’ajouter quand même ?

    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 de nommage

  • 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 une liaison de 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 de La préparation des connexions réseau et avant l’affichage de l’invite d’ouverture de session.

    • L’ID d’événement DNS 4013 est enregistré 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> de l’ordinateur du serveur<. L’erreur était : Le serveur n’est pas disponible. Voulez-vous l’ajouter quand même ?

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

    Les informations de nommage n’ont pas pu être trouvé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 en entrée toutes les partitions d’annuaires conservées localement au 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é à partir de la réplication entrante des partitions de répertoire. 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 pendant la préparation des connexions réseau dépend du nombre de partitions d’annuaires conservées 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
  • domaine
  • partition d’application DNS à l’échelle de la forêt
  • partition d’application DNS à l’échelle du domaine

Et ces contrôleurs de domaine peuvent subir 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é. Cela est dû au fait que la réplication entrante des partitions Active Directory ne s’était pas produite.

Plusieurs conditions peuvent exacerber les problèmes suivants :

  • démarrage lent de Windows
  • la 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 la connaissance 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 la connaissance d’autres contrôleurs de domaine dans la forêt pour pointer des serveurs DNS qui n’existent pas, qui sont actuellement hors connexion, qui ne sont pas accessibles sur le réseau ou qui n’hébergent pas les zones requises et les enregistrements nécessaires à la réplication entrante d’Active Directory. Par exemple, l’enregistrement GUID CNAME du contrôleur de domaine et son enregistrement hôte A ou AAAA correspondant des contrôleurs de domaine source 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 d’autres contrôleurs de domaine sur ce qui est effectivement un réseau isolé pour les raisons suivantes :
    • 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 d’Active Directory du contrôleur de domaine local contient des références à des contrôleurs de domaine obsolètes qui n’existent plus sur le réseau.
    • La copie d’Active Directory du contrôleur de domaine local contient des références à d’autres contrôleurs de domaine actuellement désactivés.
    • Il y a 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 d’Active Directory du contrôleur de domaine local contient des références à d’autres contrôleurs de domaine qui sont en ligne et accessibles, mais qui ne peuvent pas être correctement répliqués.

Dans Windows Server 2003 et Windows 2000 Server SP3 ou version ultérieure, les contrôleurs de domaine qui hébergent les opérations master rôles doivent également répliquer correctement les modifications entrantes sur la partition d’annuaire qui maintient l’état des opérations master rôle. Une 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 initiale requises pour que les rôles FSMO deviennent opérationnels sont différentes 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 recommandent de définir la valeur Repl Perform Initial Synchronizations de Registre sur 0 pour contourner les exigences de synchronisation initiale 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 n’importe quel environnement de manière continue. L’utilisation de Repl Perform Initial Synchronizations doit être utilisée uniquement dans des 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.

D’autres options possibles sont les suivantes :

  • Supprimez les références aux contrôleurs de domaine obsolètes.

  • Rendre les contrôleurs de domaine hors connexion ou non opérationnels 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 vers 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 de site hub doivent pointer vers des serveurs DNS dans le même site qu’eux pour les serveurs DNS préférés et alternatifs, puis enfin vers eux-mêmes en tant que serveur DNS de remplacement.

    Les contrôleurs de domaine de site de branche doivent configurer l’adresse IP du serveur DNS préféré pour qu’elle pointe vers un serveur DNS de site hub, l’autre adresse IP du serveur DNS pour qu’elle pointe vers un serveur DNS sur site ou sur le site disponible le plus proche, et enfin vers elle-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 de site hub 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 à recevoir l’attention administrative la plus importante, et ont généralement 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, les modifications de réplication entre elles se produisent :

    • 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 SRV et AAAA des contrôleurs de domaine dynamiques peuvent ne pas être désactivées si le contrôleur de domaine inscrit dans un site de branche ne peut pas être répliqué sortant.

    Les ordinateurs membres et les serveurs doivent continuer à pointer vers des serveurs DNS optimaux du site en tant que DNS préférés. 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 provoque un déni de service tout en équilibrant les coûts, les risques et l’utilisation du réseau, par exemple :

    • 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, inondations 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 source à l’aide du DNS (par exemple, évitez les 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 source actuels et potentiels. Cela permet d’é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 le _msdcs.<domaine> racine de forêt et zones de suffixe DNS primaires pour les contrôleurs de domaine source 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 source actuels et potentiels.

    Les enregistrements CNAME et hôte 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 d’hôtes obsolètes. En même temps, le nettoyage DNS peut être configuré de manière trop agressive, ce qui entraîne le vidage prématuré des enregistrements valides des zones DNS.

  • Optimisez les contrôleurs de domaine pour la résolution de noms de secours.

    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 courante. Pour garantir la réplication de bout en bout des partitions Active Directory, les contrôleurs de domaine Windows Server 2003 SP1 et versions ultérieures ont été modifiés pour effectuer une résolution de noms de secours :

    • du GUID CNAME du contrôleur de domaine au nom d’hôte complet.
    • du nom d’hôte complet au nom de l’ordinateur NetBIOS.

    Les ID d’événement de réplication NTDS 2087 et 2088 dans les journaux des é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 enregistrement hôte.
    • la résolution de noms de secours est en cours.

    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 source 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 entraîne 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 pour un contrôleur de domaine peuvent être incorrectement résolues en un autre contrôleur de domaine. Et aucune requête de nom n’est observée dans une trace réseau.

  • Remplacez la valeur de démarrage du service serveur DNS par 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 manuel.
    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 manuel, 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 de défaillance uniques :

    • Configuration d’un contrôleur de domaine pour pointer vers une adresse IP de serveur DNS unique
    • Placement de tous les serveurs DNS sur des machines virtuelles invitées sur le même ordinateur hôte physique
    • Placer tous les serveurs DNS dans 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 KDC ou à un serveur DNS

    Installez suffisamment de serveurs DNS pour les performances de redondance locales, régionales et à l’échelle de l’entreprise, mais pas tant que la gestion devient une charge. DNS est généralement une opération légère qui est hautement mise en cache par les clients DNS et les serveurs DNS.

    Chaque serveur DNS Microsoft s’exécutant 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.

  • Échelonnez les redémarrages des 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 sur une base planifiée (tous les sept jours, tous les 30 jours).
    • Planifiez les redémarrages et l’installation de logiciels qui nécessitent un redémarrage, de manière intelligente. Cela permet d’empêcher le redémarrage en même temps du seul serveur DNS ou du partenaire de réplication source potentiel vers lequel pointe un contrôleur de domaine de destination pour la résolution de noms.

    Si Windows Update ou un logiciel de gestion installe un logiciel qui nécessite un redémarrage, échelonnez les installations sur les contrôleurs de domaine ciblés de sorte que la moitié des serveurs DNS disponibles vers tableaux pointant vers les contrôleurs de domaine pour le redémarrage de la résolution de noms en même temps.

  • Installez des appareils UPS à des endroits 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 faire face aux 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 la température de l’ordinateur interne atteint 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’est pas 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 QUE DC2 pointe vers DC1 comme serveur DNS. Lorsque DC1 et DC2 redémarrent simultanément, le démarrage est 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 au démarrage de NTDS, NTDS n’accepte 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 à étiquette unique

La latence de 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 attendra 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 d’affectation de noms (Configuration, Schéma, domaine, ForestDnsZones, DomainDnsZones) et une seule source de réplication. Dans ce scénario, il faut 850 (170 X 5) secondes, ou plus de 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 de chaque source, nous avons deux requêtes DNS qui 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 de 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, les DNSQueryTimeouts ont été définis sur 1 1 2 4 4 pour que le client DNS attende 31 (1 + 1 + 2 + 4 + 4) secondes. Dans ce test, 31 secondes ont été passées à attendre :

    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