Solución de problemas del identificador de evento DNS 4013 (el servidor DNS no pudo cargar zonas DNS integradas en AD)

Artículo
12/26/2023

En este artículo se resuelve el identificador de evento 4013 registrado en el registro de eventos DNS de los controladores de dominio que hospedan el rol de servidor DNS después de que se inicie Windows.

Se aplica a: Windows Server 2012 R2
Número de KB original: 2001093

Síntomas

En un equipo basado en Windows que hospeda controladores de dominio de Active Directory, los roles de servidor DNS dejan de responder durante 15 a 25 minutos. Este problema se produce después de que se muestre el mensaje Preparar conexiones de red y antes de que se muestre el símbolo del sistema de inicio de sesión de Windows (Ctrl+Alt+Supr).

El siguiente identificador de evento DNS 4013 se registra en el registro de eventos DNS de los controladores de dominio que hospedan el rol de servidor DNS después de que se inicie 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%>

En esta entrada de registro, es posible que no se registren los valores de <%Status code%> . O bien, incluyen pero no se limitan a los siguientes valores:

Hexa	Byte	Decimal	Simbólico	Cadena de error
000025f5	f5 25 00 00	9717	DNS_ERROR_DS_UNAVAILABLE	El servicio de directorio no está disponible
00000232d	2d 23 00 00	9005	DNS_ERROR_RCODE_REFUSED	Se rechazó la operación DNS.
00000232a	2a 23 00 00	9002	DNS_ERROR_RCODE_SERVER_FAILURE	Error del servidor DNS.

Escenarios de cliente de ejemplo

Varios controladores de dominio en un sitio de Active Directory que se reinician simultáneamente.
- Se implementa un dominio de controlador de dos dominios en el mismo centro de datos.
- El rol de servidor DNS se instala en ambos controladores de dominio y hospeda copias integradas de AD del _msdcs.<dominio raíz del> bosque y zonas de dominio de Active Directory.
- DC1 está configurado para usar DC2 para dns preferido y sí mismo para DNS alternativo.
- DC2 está configurado para usar DC1 para dns preferido y sí mismo para DNS alternativo.
- Todos los controladores de dominio tienen fuentes de alimentación ininterrumpidas (UPS) y copias de seguridad del generador eléctrico.
- El centro de datos experimenta frecuentes interrupciones de energía de 2 a 10 horas. Los dispositivos UPS mantienen los controladores de dominio en funcionamiento hasta que los generadores suministran energía, pero no pueden ejecutar el sistema HVAC. La protección de temperatura integrada en equipos de clase de servidor apaga los controladores de dominio cuando las temperaturas internas alcanzan los límites del fabricante.
- Cuando finalmente se restaura la energía, los controladores de dominio se bloquean durante 20 minutos. Este problema se produce después de mostrar La preparación de las conexiones de red y antes de que se muestre el símbolo del sistema de inicio de sesión.
- El identificador de evento DNS 4013 se registra en el registro de eventos DNS.
Apertura de la consola de administración de DNS (DNSMGMT. MSC) produce un error y genera el siguiente mensaje de error:

No se pudo establecer contacto con el nombre del> equipo del servidor<. El error fue: El servidor no está disponible. ¿Desea agregarlo de todos modos?

Abrir el complemento de Usuarios y equipos de Active Directory (DSA). MSC) genera el siguiente mensaje de error:

No se pudo encontrar información de nomenclatura
Controladores de dominio únicos en un sitio de Active Directory
- Un controlador de dominio se implementa en un sitio.
- El rol servidor DNS está instalado y hospeda copias integradas de AD del _msdcs.<dominio raíz del> bosque y zonas de dominio de Active Directory.
- El controlador de dominio apunta a sí mismo para el DNS preferido.
- El controlador de dominio no tiene ningún servidor DNS alternativo especificado o apunta a un controlador de dominio a través de un vínculo de red de área extensa (WAN).
- El controlador de dominio se reinicia debido a una interrupción de energía.
- Durante el reinicio, es posible que el vínculo WAN no esté operativo.
- Cuando se inicia el controlador de dominio, se puede bloquear durante 20 minutos. Este problema se produce después de mostrar La preparación de las conexiones de red y antes de que se muestre el símbolo del sistema de inicio de sesión.
- El identificador de evento DNS 4013 se registra en el registro de eventos DNS.
- Apertura de la consola de administración de DNS (DNSMGMT. MSC) produce un error y genera el siguiente mensaje de error:
  
  No se pudo establecer contacto con el nombre del> equipo del servidor<. El error fue: El servidor no está disponible. ¿Desea agregarlo de todos modos?
Abrir el complemento de Usuarios y equipos de Active Directory (DSA). MSC) genera el siguiente mensaje de error:

No se pudo encontrar información de nomenclatura.

Causa

La copia de Active Directory en algunos controladores de dominio contiene referencias a otros controladores de dominio del bosque. Estos controladores de dominio intentan replicar de entrada todas las particiones de directorio mantenidas localmente durante el inicio de Windows, como parte de una sincronización inicial o sincronización de inicialización.

En un intento de arranque con el contenido de la zona DNS más reciente, los servidores DNS de Microsoft que hospedan copias integradas en AD de zonas DNS retrasan el inicio del servicio DNS durante varios minutos después del inicio de Windows. El retraso no se producirá si Active Directory ha completado su sincronización inicial durante el inicio de Windows. Mientras tanto, Active Directory se retrasa a partir de la replicación entrante de particiones de directorio. La replicación se retrasa hasta que puede resolver el GUID CNAME de su controlador de dominio de origen en una dirección IP en los servidores DNS usados por el controlador de dominio de destino para la resolución de nombres. La duración de la suspensión al preparar las conexiones de red depende del número de particiones de directorio que residen localmente en la copia de Active Directory de un controlador de dominio. La mayoría de los controladores de dominio tienen al menos las cinco particiones siguientes:

Esquema
configuration
domain
partición de aplicación DNS para todo el bosque
partición de aplicación DNS para todo el dominio

Y estos controladores de dominio pueden experimentar un retraso de inicio de entre 15 y 20 minutos. La existencia de particiones adicionales aumenta el retraso de inicio.

El identificador de evento DNS 4013 en el registro de eventos DNS indica que el inicio del servicio DNS se retrasó. Se debe a que no se había producido la replicación entrante de particiones de Active Directory.

Varias condiciones pueden exacerbar los siguientes problemas:

inicio lento de Windows
el registro del evento DNS 4013 en servidores DNS configurados para hospedar zonas integradas en AD, que residen implícitamente en equipos que actúan como controladores de dominio.

Estas condiciones incluyen:

Configuración de un servidor DNS que hospeda zonas DNS integradas en AD. Su copia de Active Directory contiene conocimientos de otros controladores de dominio en el bosque para apuntar a sí mismo exclusivamente para la resolución de nombres DNS.
Configuración de un servidor DNS que hospeda zonas DNS integradas en AD. Su copia de Active Directory contiene conocimientos de otros controladores de dominio del bosque para apuntar a servidores DNS que no existen, que están actualmente sin conexión, que no son accesibles en la red o que no hospedan las zonas y registros necesarios para replicar Active Directory de entrada. Entre los ejemplos se incluyen el registro GUID CNAME del controlador de dominio y su registro A o AAAA de host correspondiente de los controladores de dominio de origen potenciales.
Arranque de un controlador de dominio y un servidor DNS que hospeda zonas DNS integradas en AD. Su copia de Active Directory contiene conocimientos de otros controladores de dominio sobre lo que es realmente una red aislada porque:
- El adaptador de red o la pila de red del equipo de autor de la llamada o de destino está deshabilitado o no es funcional.
- El controlador de dominio se ha arrancado en una red aislada.
- La copia del controlador de dominio local de Active Directory contiene referencias a controladores de dominio obsoletos que ya no existen en la red.
- La copia del controlador de dominio local de Active Directory contiene referencias a otros controladores de dominio que están desactivados actualmente.
- Hay un problema en el controlador de dominio de origen, el controlador de dominio de destino o la infraestructura dns o de red. Por lo tanto, la copia del controlador de dominio local de Active Directory contiene referencias a otros controladores de dominio que están en línea y accesibles, pero desde los que no se puede replicar correctamente.

En Windows Server 2003 y Windows 2000 Server SP3 o posterior, los controladores de dominio que hospedan roles maestros de operaciones también deben replicar correctamente los cambios entrantes en la partición de directorio que mantiene el estado del rol maestro de operaciones. La replicación correcta debe producirse antes de que se puedan realizar operaciones dependientes de FSMO. Estas sincronizaciones iniciales se agregaron para asegurarse de que los controladores de dominio estaban de acuerdo sobre la propiedad del rol FSMO y el estado del rol. Los requisitos de sincronización inicial necesarios para que los roles de FSMO se vuelvan operativos son diferentes de la sincronización inicial que se describe en este artículo, donde Active Directory debe replicarse de entrada para iniciar el servicio servidor DNS inmediatamente.

Solución

Algunos contenidos externos y de Microsoft han recomendado establecer el valor Repl Perform Initial Synchronizations del Registro en 0 para omitir los requisitos de sincronización iniciales en Active Directory. La subclave específica del Registro y los valores de esa configuración son los siguientes:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
Nombre del valor: Repl Realizar sincronizaciones iniciales
Tipo de valor: REG_DWORD
Información del valor: 0

Este cambio de configuración no se recomienda para su uso en entornos de producción ni en ningún entorno de forma continuada. El uso de Repl Perform Initial Synchronizations debe usarse solo en situaciones críticas para resolver problemas temporales y específicos. La configuración predeterminada debe restaurarse una vez resueltos estos problemas.

Otras opciones factibles incluyen:

Quitar referencias a controladores de dominio obsoletos.
Hacer que los controladores de dominio sin conexión o que no funcionen sean operativos.
Los controladores de dominio que hospedan zonas DNS integradas en AD no deben apuntar a un único controlador de dominio y, especialmente, a sí mismos como DNS preferido para la resolución de nombres.

El registro de nombres DNS y la resolución de nombres para los controladores de dominio es una operación relativamente ligera que los servidores y clientes DNS almacenan en caché.

La configuración de controladores de dominio para que apunten a la dirección IP de un único servidor DNS, incluida la dirección de bucle invertido 127.0.0.1, representa un único punto de error. Esta configuración es tolerable en un bosque con un solo controlador de dominio, pero no en bosques con varios controladores de dominio.

Los controladores de dominio del sitio central deben apuntar a servidores DNS en el mismo sitio que ellos para el servidor DNS preferido y alternativo y, por último, a sí mismo como otro servidor DNS alternativo.

Los controladores de dominio de sitio de sucursal deben configurar la dirección IP del servidor DNS preferida para que apunte a un servidor DNS de sitio central, la dirección IP del servidor DNS alternativo para que apunte a un servidor DNS en el sitio o a uno del sitio disponible más cercano y, por último, a sí mismo mediante la dirección de bucle invertido 127.0.0.1 o la dirección IP estática actual.

Al apuntar a servidores DNS del sitio central, se reduce el número de saltos necesarios para obtener registros SRV y HOST del controlador de dominio críticos totalmente registrados. Los controladores de dominio dentro del sitio central tienden a obtener la mayor atención administrativa, normalmente tienen la colección más grande de controladores de dominio en el mismo sitio. Dado que están en el mismo sitio, se producen cambios de replicación entre sí:
- cada 15 segundos en Windows Server 2003 o posterior
- cada cinco minutos en Windows 2000 Server
Este comportamiento hace que estos registros DNS se conozcan bien.

Es posible que SRV del controlador de dominio dinámico y los registros de registros de A y AAAA del host no lo conviertan en un elemento no automático si el controlador de dominio de registro de un sitio de rama no puede replicarse de salida.

Los equipos y servidores miembros deben seguir apuntando a servidores DNS óptimos para el sitio como DNS preferido. Y pueden apuntar a servidores DNS fuera del sitio para una tolerancia a errores adicional.

Su objetivo final es evitar que todo provoque una denegación de servicio mientras equilibra los costos, los riesgos y el uso de la red, como:
- errores de replicación y latencia de replicación
- errores de hardware, errores de software
- prácticas operativas
- interrupciones de energía a corto y largo plazo
- incendios, robos, inundaciones y terremotos
- eventos terroristas
Asegúrese de que los controladores de dominio de destino puedan resolver controladores de dominio de origen mediante DNS (por ejemplo, evite la reserva).

Debe asegurarse de que los controladores de dominio puedan resolver correctamente los registros CNAME guiados para hospedar registros de controladores de dominio de origen actuales y potenciales. Si lo hace, puede evitar una latencia alta introducida por la lógica de reserva de resolución de nombres.

Los controladores de dominio deben apuntar a servidores DNS que:
- Están disponibles en el inicio de Windows.
- Hospedar, reenviar o delegar el _msdcs.<dominio raíz> del bosque y zonas de sufijo DNS principal para controladores de dominio de origen actuales y potenciales.
- Puede resolver los registros GUID de CNAME actuales (por ejemplo, dded5a29-fc25-4fd8-aa98-7f472fc6f09b._msdcs.contoso.com) y los registros de host de los controladores de dominio de origen actuales y potenciales.
Los registros CNAME y host que faltan, duplicados o obsoletos contribuyen a este problema. Scavenging no está habilitado en los servidores DNS de Microsoft de forma predeterminada, lo que aumenta la probabilidad de registros de host obsoletos. Al mismo tiempo, la eliminación de DNS se puede configurar de forma demasiado agresiva, lo que hace que los registros válidos se purguen prematuramente de las zonas DNS.
Optimice los controladores de dominio para la reserva de resolución de nombres.

La incapacidad de configurar DNS correctamente para que los controladores de dominio pudieran resolver los registros GUID de CNAME del controlador de dominio para hospedar registros en DNS era común. Para garantizar la replicación de un extremo a otro de las particiones de Active Directory, windows Server 2003 SP1 y controladores de dominio posteriores se modificaron para realizar la reserva de resolución de nombres:
- desde el GUID de CNAME del controlador de dominio hasta el nombre de host completo.
- desde el nombre de host completo al nombre de equipo netBIOS.
Los identificadores de eventos de replicación ntds 2087 y 2088 en los registros de eventos del servicio de directorio indican lo siguiente:
- un controlador de dominio de destino no pudo resolver el registro GUID CNAME del controlador de dominio en un registro host.
- se está produciendo una reserva de resolución de nombres.
Los archivos WINS, HOST y LMHOST se pueden configurar. Por lo tanto, los controladores de dominio de destino pueden resolver los nombres de los controladores de dominio de origen actuales y potenciales. De las tres soluciones, el uso de WINS es más escalable, ya que WINS admite actualizaciones dinámicas.

Las direcciones IP y los nombres de los equipos inevitablemente se vuelven obsoletos. Este problema hace que las entradas estáticas en los archivos HOST y LMHOST no sean válidas con el tiempo. Cuando se produce este problema, es posible que las consultas de un controlador de dominio se resuelvan incorrectamente en otro controlador de dominio. Y no se observa ninguna consulta de nombre en un seguimiento de red.
Cambie el valor de inicio del servicio de servidor DNS a manual si el arranque se produce en una configuración incorrecta conocida.

Si inicia un controlador de dominio en una configuración incorrecta conocida que se describe en este artículo, siga estos pasos:
1. Establezca el valor de inicio del servicio servidor DNS en manual.
2. Reinicie y espere a que el controlador de dominio se anuncie.
3. Reinicie el servicio servidor DNS.
Si el valor de inicio del servicio para el servicio servidor DNS está establecido en manual, Active Directory no espera a que se inicie el servicio servidor DNS.

Consideraciones adicionales

Evite puntos únicos de error.

Algunos ejemplos de puntos de error únicos son:
- Configuración de un controlador de dominio para que apunte a una dirección IP de servidor DNS único
- Colocación de todos los servidores DNS en máquinas virtuales invitadas en el mismo equipo host físico
- Colocación de todos los servidores DNS en el mismo sitio físico
- Limitación de la conectividad de red, de modo que los controladores de dominio de destino solo tengan una ruta de acceso de red única para acceder a un KDC o servidor DNS
Instale suficientes servidores DNS para el rendimiento de redundancia local, regional y empresarial, pero no tantos que la administración se convierte en una carga. DNS suele ser una operación ligera que los clientes DNS y los servidores DNS almacenan en caché.

Cada servidor DNS de Microsoft que se ejecuta en hardware moderno puede satisfacer entre 10 000 y 20 000 clientes por servidor. La instalación del rol DNS en cada controlador de dominio puede dar lugar a un número excesivo de servidores DNS en la empresa. Y si lo hace, aumentará el costo.
Escalone los reinicios de los servidores DNS de la empresa cuando sea posible.
- La instalación de algunas revisiones, Service Pack y aplicaciones puede requerir un reinicio.
- Algunos clientes reinician los controladores de dominio de forma programada (cada siete días, cada 30 días).
- Programar reinicios y la instalación de software que requiere un reinicio de forma inteligente. De este modo, se evita que el único servidor DNS o posible asociado de replicación de origen al que apunta un controlador de dominio de destino para la resolución de nombres se reinicie al mismo tiempo.
Si Windows Update o software de administración instala software que requiere reinicio, escalone las instalaciones en los controladores de dominio de destino para que la mitad de los servidores DNS disponibles a los que los controladores de dominio apunten para reiniciar la resolución de nombres al mismo tiempo.
Instale dispositivos UPS en lugares estratégicos para garantizar la disponibilidad de DNS durante interrupciones de energía a corto plazo.
Aumente los servidores DNS respaldados por UPS con generadores locales.

Para hacer frente a interrupciones prolongadas, algunos clientes han implementado generadores eléctricos en el sitio para mantener los servidores de claves en línea. Algunos clientes han descubierto que los generadores pueden alimentar servidores en el centro de datos, pero no el HVAC local. La falta de aire acondicionado puede hacer que los servidores locales se apaguen cuando las temperaturas internas del equipo alcancen un umbral determinado.

Más información

Pruebas del 10 de mayo de 2010 por parte del equipo de desarrollo de Active Directory:

DNS espera a NTDS y no se puede iniciar hasta que se haya completado la replicación inicial del directorio. Esto se debe a que es posible que los datos DNS actualizados no se repliquen aún en el controlador de dominio. Por otro lado, NTDS necesita DNS para resolver la dirección IP del controlador de dominio de origen para la replicación. Supongamos que DC1 apunta a DC2 como su servidor DNS y DC2 apunta a DC1 como su servidor DNS. Cuando DC1 y DC2 se reinician simultáneamente, habrá un inicio lento debido a esta dependencia mutua. La causa principal de este inicio lento es DNSQueryTimeouts.

Si el servicio servidor DNS se ejecuta bien cuando se inicia NTDS, NTDS solo toma dos consultas DNS para resolver la dirección IP del controlador de dominio de origen:

uno para IPv4
el otro para IPv6

Y estas consultas DNS devuelven casi instantáneamente.

Si el servicio servidor DNS no está disponible cuando se inicia NTDS, NTDS tendrá que enviar 10 consultas DNS para resolver la dirección IP:

cuatro para el nombre basado en GUID
cuatro para el nombre completo
dos para el nombre de una sola etiqueta

DnsQueryTimeouts controla la latencia de cada consulta DNS. De forma predeterminada, DNSQueryTimeouts se establece en 1 1 1 2 4 4. Significa que el cliente DNS esperará 12 (1 + 1 + 2 + 4 + 4) segundos para la respuesta del servidor DNS. Cada origen de contexto de nomenclatura tarda 120 segundos en resolver la dirección IP. Supongamos que hay cinco contextos de nomenclatura (Configuración, Esquema, dominio, ForestDnsZones, DomainDnsZones) y un único origen de replicación. En este escenario, NTDS tardará 850 (170 X 5) segundos, o más de 14 minutos, en finalizar la replicación inicial.

Se realizaron varias pruebas para validar el comportamiento anterior.

Reinicie el controlador de dominio cuando el servidor DNS sea un tercer controlador de dominio que esté en línea. Para cada contexto de nomenclatura de cada origen, tenemos dos consultas DNS y finalizaron casi instantáneamente:

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

Reinicie DC1 y DC2 simultáneamente. DC1 usa DC2 para DNS DC2 mediante DC1 para DNS. Para cada contexto de nomenclatura cada origen, tenemos 10 consultas DNS y cada consulta tarda aproximadamente 12 segundos:

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

Para estudiar aún más la relación entre DNSQueryTimeouts y el inicio lento, DNSQueryTimeouts se estableció en 1 1 1 2 4 4 para hacer que el cliente DNS espere 31 (1 + 1 + 2 + 4 + 4) segundos. En esta prueba, se dedicaron 31 segundos a esperar:

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