Can Intelligent DNS Safely Power Dual‑Active Database Access? Pros, Cons, and Best Practices

What Is Intelligent DNS

Intelligent DNS (also called Global Load‑Balancing‑GS LB) is an advanced DNS resolution service that selects the optimal IP address for a client based on pre‑configured policies and real‑time health data such as server status, load, geographic location, latency, and source IP.

Authoritative DNS server : receives user DNS queries.

Policy engine : evaluates policies (geo, round‑robin, weighted, fail‑over, etc.) to decide which IP to return.

Health‑check module : continuously probes backend endpoints (HTTP/HTTPS/TCP/Ping) to assess availability.

Data‑center/node information store : stores IP, status, location and other metadata for each backend node.

By dynamically selecting the best IP, Intelligent DNS can shift traffic away from failed servers and balance load across healthy nodes.

Intelligent DNS Resolution Process

The resolution flow typically follows these steps:

The client requests a domain (e.g., www.example.com) and first checks local caches (browser, OS DNS cache, hosts file).

If the cache misses, the client sends a recursive query to its local DNS resolver, which traverses root → TLD → authoritative servers and obtains the domain’s record set.

The client then queries the Intelligent DNS service for the same domain.

Intelligent DNS acts as a proxy, forwarding the query to the authoritative DNS server.

The authoritative server returns the configured IP addresses (usually two or more).

The Intelligent DNS policy engine selects the most suitable IP according to the active strategy.

The chosen IP is returned to the local resolver, which caches the result according to the TTL.

The local resolver finally returns the optimal IP to the client.

The client establishes a TCP (or UDP) connection to the selected IP address.

Intelligent DNS Strategy Algorithms

Intelligent DNS supports several distribution strategies, including round‑robin, least‑connections, geographic priority, health‑based priority, and traffic‑ratio weighting. Two commonly used strategies are described below.

Local‑First Strategy

This strategy routes a request to the data‑center that is geographically closest or has the lowest network latency. The service maintains an internal IP‑to‑location database; when a DNS query arrives, the client’s IP is mapped to a region and the IP of the nearest node is returned. For internal services, configuring the resolver order to prioritize the local DNS server ensures intra‑site traffic resolves to local endpoints, reducing latency.

Traffic‑Ratio (Business‑Flow) Strategy

Administrators define a traffic split (e.g., 70 % to a production site, 30 % to a same‑city site) to achieve load balancing, A/B testing, or staged rollouts. Intelligent DNS dynamically adjusts weights based on health checks; failed nodes are excluded and traffic is redistributed among healthy nodes. Weights can be static or modified via API for fine‑grained control, which is useful for gray‑release or blue‑green deployment scenarios.

Advantages and Disadvantages

Advantages

Provides global load‑balancing and automatic fail‑over.

Routes users to the nearest node, improving response time.

Transparent to clients – only a single domain name is required.

Disadvantages

TTL‑based caching can delay fail‑over; short TTLs increase DNS query load, long TTLs prolong outage windows.

For distributed databases, dynamic routing may cause cross‑center traffic, leading to bandwidth bottlenecks and potential data‑consistency issues.

Intelligent DNS operates at the IP layer and cannot interpret database‑specific health signals (e.g., primary/standby role, SQL error codes).

Long‑lived database connections rely on DNS cache; when a backend fails, existing connections are not automatically redirected, requiring application‑level retry logic.

Using Intelligent DNS in Dual‑Active (Active‑Active) Architecture

Application Layer

Intelligent DNS is well‑suited for routing user traffic to application instances based on geography, load, and health. In a production‑same‑city dual‑active setup, traffic can be split according to configured ratios, supporting version validation, rolling upgrades, and disaster‑recovery cut‑over.

Database Access

In a dual‑active deployment the typical data flow is:

client → DNS → load balancer → application → database load balancer → database

When the primary site fails, traffic is switched at the upper layers while the database layer maintains its own HA mechanisms.

Traditional centralized databases (e.g., Oracle RAC with Data Guard) already rely on a primary‑standby model and load balancers that perform health checks; adding Intelligent DNS provides little extra value.

Distributed databases (sharded or multi‑master) replicate data across sites with RPO = 0. Intelligent DNS can route client traffic to any site, but this may increase cross‑site traffic and stress inter‑site links, especially for batch‑heavy workloads.

Key concerns when placing database access behind Intelligent DNS:

TTL vs. persistent connections : Long‑lived DB connections may remain bound to a failed IP until the DNS cache expires, requiring explicit retry logic.

Lack of protocol awareness : DNS health checks cannot determine whether a DB instance is primary, overloaded, or returning error codes.

Cross‑center traffic increase : Routing DB queries to a remote site can saturate inter‑site links.

Connection‑pool management : Pools may retain connections to an IP that becomes invalid after a DNS‑driven fail‑over; pools must evict stale connections and create new ones.

Necessity Analysis

For centralized databases, adding Intelligent DNS on top of existing load balancers adds little resilience because the load balancer already performs health checks and fail‑over.

For distributed databases, Intelligent DNS can introduce new failure modes (e.g., cross‑site latency, cache staleness) without providing the fine‑grained health checks that database‑aware load balancers offer.

Conclusion : Intelligent DNS excels at handling single‑site load‑balancer failures, but in a dual‑active design the preferred approach is to perform traffic switching at the application layer, where business logic can make informed decisions. Introducing Intelligent DNS adds another potential point of failure and complicates database connection management.

Reference: https://cloud.tencent.com/developer/article/2094030