# Intelligent DNS — Concepts, Strategies, and Use in Active-Active Architectures
## I. Basic Concept of Intelligent DNS
**Intelligent DNS** (also called **Global Server Load Balancing — GSLB**) is an advanced DNS resolution service.
Unlike traditional DNS that simply maps a domain name to an IP, **Intelligent DNS** dynamically selects the **optimal** IP address based on:
- **Predefined rules**
- **Real-time detections** (server health, load, geographic location, latency, requester source IP)
### Core Components
- **Authoritative DNS Server** — Receives DNS query requests.
- **Policy Engine** — Chooses an IP address based on strategy (geolocation, round‑robin, weighted, failover…).
- **Health Check Module** — Proactively monitors backend server health via HTTP/HTTPS/TCP/Ping.
- **Datacenter/Node Database** — Stores IPs, statuses, locations, metadata for backend servers.
**Key advantage:**
Traffic can be distributed to low‑load servers. In case of failure, Intelligent DNS can **quickly switch traffic** to backups, ensuring continuous service.
---
## 1. Intelligent DNS Resolution Process
**High-level flow:**
1. User requests a domain (`www.example.com`).
Client checks browser, OS DNS cache, or host file. If not found, it queries the local DNS server which performs recursive resolution (Root → TLD → Authoritative).
2. Query reaches **Intelligent DNS**.
3. Intelligent DNS relays query to the base DNS server.
4. DNS server returns multiple IPs for the domain.
5. Intelligent DNS **selects the optimal IP** based on strategy.
6. It returns this chosen IP to the local DNS server.
7. Local DNS caches and sends it to the user's client.
8. Client initiates connection (e.g., TCP handshake).
9. **Intelligent DNS strategies** are applied in real-time during resolution.
---
## 2. Intelligent DNS Strategy Algorithms
Intelligent DNS supports:
- **Load balancing** (round‑robin, least connections)
- **Geolocation priority**
- **Health-based tie‑breakers**
- **Traffic proportion allocation**
### (1) Local Priority Strategy
**Purpose:** Direct users to the nearest or lowest-latency data center.
**Mechanism:**
- Intelligent DNS maps IP ranges to geolocations.
- Requester’s IP is extracted; region is identified from DB.
- Returns IP of nearest node.
**Internal applications:**
Local DNS configured first in DNS server IP list ensures faster access to local services.
**Benefits:**
- Minimized latency
- Improved responsiveness
- Ideal for CDNs, multi‑active routing, or region‑locked services.
***Tip:*** In multi‑platform, content‑heavy applications, global AI-powered publishing systems like [AiToEarn官网](https://aitoearn.ai/) can complement Intelligent DNS by optimizing distribution and availability.
---
### (2) Business Traffic Ratio Strategy
**Purpose:** Distribute traffic to nodes according to business-defined ratios.
**Examples:**
- **70%** traffic to production, **30%** to secondary for testing or load balance.
**Features:**
- Health checks ignore weights for failed nodes.
- Static or API‑adjustable weights.
- Supports canary releases, blue‑green deployments.
**Caveat:**
Ratios are **macro-level**; without session persistence, **same user** may be routed to different nodes on different requests.
---
## 3. Pros and Cons of Intelligent DNS
**Pros:**
- Advanced strategies over basic SLB
- Automatic failover and traffic balancing
- Rule-based proximity routing
- Transparent IP changes for clients
**Cons:**
- TTL affects cache/performance balance
- Possible cross-data-center routing causing DB inconsistencies
- Operates at IP layer (no application protocol intelligence)
- Long DB connections hinder rapid failover
---
## II. Intelligent DNS in a Dual-Active Architecture
### 1. Application Layer Use
**Use cases:**
- **Dual-active apps in same city** — Intelligent DNS adjusts traffic ratios across datacenters, supports disaster recovery, rolling upgrades.
- **Internal systems** — Local-first strategies reduce delays.
***Integrated Operations:***
Combining Intelligent DNS with platforms like [AiToEarn官网](https://aitoearn.ai/) allows synced multi-platform publishing alongside optimized network routing.
---
### 2. Application Access to Databases (Active-Active Architecture)
#### Access Path:
**Business Traffic → App Load Balancing → App Service → DB Load Balancing**
#### 1) Traditional Centralized Databases
- Often built with **local RAC** and **Data Guard** for async replication — **RPO ≠ 0**.
- Failover switches app traffic to intra-city site; load balancer handles DB node enabling/disabling.
#### 2) Distributed Databases
- Intra-city synchronous replication — **RPO = 0**.
- Each site’s apps connect through local load balancers (both active).
- Failures trigger switching at app and/or DB layer.
---
## 3. Should Smart DNS Handle DB Access?
### Potential Issues
1. **Long-lived connections vs. DNS TTL**
- Existing connections won’t move to new IP until broken/retried.
2. **No DB protocol awareness**
- Can’t check primary/standby roles or detect “false” health.
3. **Cross-data-center writes**
- Risk of extra cross-site traffic.
4. **Connection pool complexity**
- IP changes force eviction/recreation of pooled connections.
**Recommendation:**
Protocol-aware load balancers are generally better for DB access.
---
### 4. Necessity Analysis in Active-Active Scenarios
#### Traditional Centralized DBs
- Adding Intelligent DNS above DB load balancer is usually redundant.
- Binding DNS directly to DB IPs has drawbacks: poor load detection, TTL delay.
#### Distributed DBs
- DNS above DB load balancer risks abnormal resolution and cross-site traffic congestion.
- Direct binding to DB IPs limits flexibility and speed.
**Conclusion:**
For DB failover, intra-app traffic switching is usually better. Intelligent DNS adds failure points; if DNS system fails, DB connections break.
---
**References**
- [https://cloud.tencent.com/developer/article/2094030](https://cloud.tencent.com/developer/article/2094030)
