Share via

Clarification on DNS Resolution Behavior

Rachel 0 Reputation points
2026-05-08T08:58:56.5166667+00:00

I would like to enquire about the behaviour of Microsoft Active Directory-integrated DNS, specifically on Windows Server 2019.

We are looking to better understand how primary and secondary DNS servers operate in an AD environment, and how failover is handled from a client perspective.

In particular, we would like clarification on the following:

  • When a primary DNS server becomes unresponsive or hangs, how does a domain-joined Windows client handle failover to a secondary DNS server?
  • Does the client automatically detect the failure and switch to the secondary DNS, or are there specific timeout mechanisms and retry behaviours involved?
  • Are there any differences in this behaviour between Windows Server 2019 and newer versions such as Windows Server 2025?

Additionally, we recently encountered a situation where the AD DNS server itself remained up and reachable at the OS/network level, but the DNS service appeared to have hung. In this scenario:

  • DNS queries sent to the server did not receive responses.
  • From the client perspective, it was unclear whether this condition is treated as a timeout (triggering failover) or as a valid “no record” response.
  • We would like to understand how Windows clients differentiate between a non-responsive DNS service versus a legitimate negative response, and how this impacts failover to secondary DNS servers.

We would also like to enquire (specifically for Windows Server 2019 environments) whether Microsoft provides any capability to implement round-robin or load distribution logic on the client side when multiple DNS servers (e.g., DNS 1 and DNS 2) are configured.

  • Does the client always prioritize the first DNS server unless failure is detected, or is there a way to distribute queries across both DNS servers under normal operation?

Understanding this behaviour is important for us in designing a resilient DNS architecture and ensuring application availability during partial failures.

Appreciate your guidance and any relevant documentation you can share.

Windows for business | Windows Server | Directory services | Active Directory
0 comments

3 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Harry Phan 21,095 Reputation points Independent Advisor
    2026-05-08T09:28:07.7166667+00:00

    Hi Rachel,

    In an AD‑integrated DNS environment, all domain controllers hosting the DNS role act as writable primaries, so the distinction between “primary” and “secondary” is not the same as in traditional standalone DNS. From the client perspective, Windows queries the first configured DNS server and only fails over if that server does not respond within the resolver timeout. If the DNS service on the server is hung but the host is reachable, the client experiences query timeouts rather than a negative response; a negative response (NXDOMAIN) is treated as authoritative and does not trigger failover. The default resolver timeout is about one second per attempt, with multiple retries before switching to the next server in the list, so failover is not instantaneous. This behavior is consistent across Windows Server 2019 and newer releases such as Server 2025, as the DNS client stack has not changed in this respect.

    Windows clients do not distribute queries across multiple DNS servers under normal operation; they always prefer the first server unless it fails to respond. Round‑robin or load distribution is not a client‑side capability, but you can achieve resilience by ensuring multiple AD DNS servers are registered in DHCP and by monitoring service health to avoid hung DNS processes. For your scenario, the key is to distinguish between a hung DNS service and a true NXDOMAIN, since only the former will eventually trigger failover. For deeper design guidance, Microsoft’s documentation on DNS client resolver behavior and AD‑integrated DNS provides authoritative details.

    If the above response helps answer your question, please hit "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

    Harry.

    Was this answer helpful?

    1 person found this answer helpful.
    0 comments

  2. AI answer

    2026-05-08T08:59:44.92+00:00

    Windows DNS client behavior in an Active Directory environment is driven by the DNS client (Dnscache) logic, not by AD‑integrated DNS specifically. The key points from the provided documentation are:

    1. Failover behavior from primary to secondary DNS
    • Windows DNS clients are typically configured with multiple DNS servers to provide fault tolerance.
    • The client does not send each query to all configured DNS servers. Instead:
      • On startup, the DNS client uses the server listed as the Preferred DNS server.
      • If this server fails to respond to a DNS query for any reason, the client switches to the server listed as the Alternate DNS server.
      • After switching, the client continues to use the alternate DNS server until one of the following occurs:
        • The alternate server fails to respond to a DNS query, or
        • The ServerPriorityTimeLimit value is reached (15 minutes by default).
    • Only a failure to respond causes the DNS client to switch servers. An authoritative but incorrect response does not cause a switch.

    This behavior applies to domain controllers and other Windows clients; the same DNS client logic is used.

    1. How a hung DNS service is treated
    • From the client perspective, failover is triggered only when the DNS server fails to respond to a query.
    • If the DNS service on a server has hung such that it does not send any response, the client will treat this as a failure to respond and will eventually switch to the alternate DNS server, subject to the DNS client’s timeout and retry behavior.
    • If the server responds with a negative answer (for example, “name does not exist” or “no records of that type”), this is treated as a valid response and is cached as a negative response. The client does not fail over to another DNS server in this case.
    • The documentation explicitly notes that receiving an authoritative but incorrect response does not cause the DNS client to try another server. This also applies conceptually to legitimate negative responses: they are not treated as failures.
    1. Distinguishing non‑responsive vs. negative responses
    • A non‑responsive DNS server is one that does not reply at all to a query. This triggers the failover logic described above.
    • A negative response is an explicit DNS reply indicating either:
      1. The authoritative server could not find the queried name in the namespace, or
      2. The name exists but no records of the requested type exist.
    • The resolver processes both positive and negative responses and caches them for future use. Negative responses are therefore treated as valid answers, not as failures.
    1. Timeouts and retries
    • DNS servers performing recursive queries use default timings:
      • Recursion retries interval: 3 seconds (time between retries during a recursive lookup).
      • Recursion timeout interval: 8 seconds (total time before failing a recursive lookup that has been retried).
    • These timings apply to the server’s recursion behavior. On the client side, the key behavior is that only a non‑response (timeout) causes a switch to the alternate DNS server.
    1. Client‑side load distribution / round‑robin
    • Windows guidance emphasizes configuring clients with more than one DNS server IP to add fault tolerance, not to provide client‑side load balancing.
    • The documented behavior is that the client prefers the first (Preferred) DNS server and only switches to the alternate when the preferred server fails to respond, and then only reverts based on ServerPriorityTimeLimit or further failures.
    • There is no documented client‑side round‑robin or equal load distribution across multiple DNS servers. The design is “primary‑then‑fallback,” not “balanced use of all configured servers.”
    1. AD‑integrated DNS and domain controllers
    • In AD environments, DNS is essential for domain controller location and authentication. Domain controllers also use DNS to locate each other.
    • Best practices for domain controllers with DNS installed include:
      • Do not point domain controllers’ DNS client settings directly to ISP DNS servers. Instead, configure ISP DNS as forwarders on the internal DNS servers or rely on root hints.
      • Domain controllers must register their records with their own DNS server so that other domain controllers and clients can find Active Directory‑related information.
    • A domain controller can be configured with itself and another DNS server as Preferred and Alternate DNS servers. This helps ensure that a response is received, but does not guarantee accuracy, because DNS record update failures on either server can cause inconsistent name resolution.
    1. Version differences (Windows Server 2019 vs. newer)
    • The provided documentation describes generic Windows DNS client and server behavior and does not specify differences between Windows Server 2019 and Windows Server 2025 in this area.
    • Based on the context, the described behavior (preferred server, alternate server, failover on non‑response only, ServerPriorityTimeLimit) is the relevant and supported model.
    1. Summary for resilient DNS design
    • Configure each Windows client (including domain controllers) with more than one DNS server IP to provide fault tolerance.
    • Expect clients to:
      • Use the Preferred DNS server by default.
      • Switch to the Alternate DNS server only when the preferred server fails to respond.
      • Continue using the alternate until it fails or ServerPriorityTimeLimit is reached.
    • A hung DNS service that does not respond will be treated as a failure and will eventually cause failover; a negative response will not.
    • Client‑side round‑robin or load distribution across multiple DNS servers is not documented; the behavior is priority‑based rather than load‑balanced.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

    1 person found this answer helpful.
  3. Somil Jain 660 Reputation points
    2026-05-08T19:17:04.5533333+00:00

    hi Rachel,
    In Windows AD environments, clients do not normally load-balance DNS queries across configured DNS servers. The client typically prefers the first DNS server in the adapter list and only switches to the next server after timeout/failure conditions are detected.

    If the primary DNS server:

    • returns a valid DNS response (including NXDOMAIN / “record not found”), the client treats that as a successful response and does NOT fail over.

    If the DNS server:

    does not respond at all,

    times out,

    or becomes unreachable, the client will retry and eventually query the secondary DNS server.

    So in your “DNS service hung but OS still reachable” scenario:

    if the DNS service accepted packets but never responded, the client should eventually treat it as a timeout and move to the secondary server.

    however, failover is not always immediate because Windows DNS clients maintain server preference, retry timers, and cached server responsiveness data.

    This behavior is generally similar across Windows Server 2019, 2022, and 2025 because the logic primarily resides in the Windows DNS Client service on endpoints rather than the DNS server version itself.

    Also important:

    Windows clients do not perform true round-robin query distribution across DNS servers by default.

    The secondary DNS server is primarily for failover, not active load balancing.

    For resilient AD DNS design, Microsoft generally recommends:

    multiple AD-integrated DNS servers,

    low-latency connectivity,

    proper AD replication health,

    and monitoring DNS service responsiveness — not just server/network reachability.

    A DNS service hang can be particularly problematic because ICMP/ping may still succeed while DNS queries silently time out.In Windows AD environments, clients do not normally load-balance DNS queries across configured DNS servers. The client typically prefers the first DNS server in the adapter list and only switches to the next server after timeout/failure conditions are detected.

    If the primary DNS server:

    returns a valid DNS response (including NXDOMAIN / “record not found”),
    the client treats that as a successful response and does NOT fail over.

    If the DNS server:

    does not respond at all,

    times out,

    or becomes unreachable,
    the client will retry and eventually query the secondary DNS server.

    So in your “DNS service hung but OS still reachable” scenario:

    if the DNS service accepted packets but never responded, the client should eventually treat it as a timeout and move to the secondary server.

    however, failover is not always immediate because Windows DNS clients maintain server preference, retry timers, and cached server responsiveness data.

    This behavior is generally similar across Windows Server 2019, 2022, and 2025 because the logic primarily resides in the Windows DNS Client service on endpoints rather than the DNS server version itself.

    Also important:

    Windows clients do not perform true round-robin query distribution across DNS servers by default.

    The secondary DNS server is primarily for failover, not active load balancing.

    For resilient AD DNS design, Microsoft generally recommends:

    multiple AD-integrated DNS servers,

    low-latency connectivity,

    proper AD replication health,

    and monitoring DNS service responsiveness — not just server/network reachability.

    A DNS service hang can be particularly problematic because ICMP/ping may still succeed while DNS queries silently time out.
    If my answer is useful for you, please hit Accept the answer to support me.

    Thank you so much,

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.