2.2 OCI DNS Traffic Steering, Geolocation & Health Checks

OCI Global DNS and Anycast Architecture

Designing resilient, multi-region architectures requires managing ingress traffic before it reaches a specific data center or Virtual Cloud Network (VCN). OCI public DNS runs on a global anycast network, so the same nameserver addresses are announced from many locations and each query is answered by a nearby nameserver. This keeps lookups fast and spreads query load, which is why DNS-based traffic steering is the usual entry point for multi-region designs.

Beyond basic authoritative zone hosting, OCI provides Traffic Management Steering Policies. These policies dynamically alter DNS answers (such as A, AAAA, or CNAME records) based on endpoint health, client geographic location, network origin, or pre-configured load-balancing weights.

---

Traffic Management Steering Policies

OCI Traffic Management steering policies decide which answers the DNS service returns, based on endpoint health and the origin of the query. Oracle documents five policy types:

1. Failover: Answers are served in priority order, such as a primary in Ashburn and a secondary in Phoenix. Health Checks monitors evaluate the answers. If the primary answer is unhealthy, DNS traffic is automatically steered to the secondary.
2. Load Balancer: Traffic is spread across several endpoints using equal weights, or custom weights for ratio load balancing (for example, 70/30 during a gradual cutover). Unhealthy endpoints are removed, and traffic is redistributed to the healthy ones.
3. Geolocation Steering: Traffic is directed by the location of the end user, using regions defined by continent, country, or (in North America) state or province. Each geographic case can list answers in priority order, so an unhealthy regional endpoint is skipped and the next answer, such as a neighboring region, is served.
4. ASN Steering: Queries from a specific Autonomous System Number (ASN), such as an enterprise network or a mobile operator, are steered to a chosen endpoint. A typical use is sending partner networks to dedicated resources.
5. IP Prefix Steering: Queries are steered by the IP prefix of the originating query, which is useful for giving internal and external users different answers.

---

OCI Health Checks: Monitors and Vantage Points

Steering policies use the Health Checks service to judge whether answers are healthy. Health Checks provides two tools:

• Monitors continuously test public-facing endpoints. A monitor uses either the HTTP protocols (HTTP or HTTPS requests) or the ping protocols (ICMP or TCP connection tests).
• On-demand probes run a one-time check through the REST API, limited by a credit allowance.

Key parameters and limits include:

• Interval: A monitor with a 10-second test interval is classed as Premium. Longer intervals are Basic. The only difference between the two classes is how often the test runs.
• Vantage points: Oracle maintains dozens of vantage points worldwide. Oracle recommends selecting three or more vantage points across three different providers, so a problem with one provider's network does not look like an outage of your application.
• Scope: Health Checks tests public-facing endpoints. It cannot probe a private IP inside a VCN.
• Limit: The service is limited to 1,000 endpoint tests per account.

Using several vantage points on independent providers is the main defense against false-positive failovers caused by a single transit network problem.

---

DNS TTL Considerations and Upstream Caching Mechanics

The effectiveness of automated DNS traffic steering depends on the Time-To-Live (TTL) configured on DNS records. TTL dictates the duration (in seconds) that intermediate recursive resolvers (such as corporate forwarders, public DNS resolvers like 8.8.8.8, and ISP DNS servers) cache the resolution response before issuing a new lookup to OCI Anycast nameservers.

Architectural tradeoffs of TTL values include:

• Low TTL (30–60 seconds): Essential for rapid disaster recovery failover. When the primary region fails and OCI DNS updates its steering response, client traffic shifts to the secondary region within 1 to 2 minutes.
• High TTL (300+ seconds): Minimizes DNS query volume and reduces network latency for repeat visitors, but delays failover; client browsers continue sending requests to the dead primary region until their local cache expires.
• Recursive Resolver Clamping: Some public ISPs enforce minimum TTL overrides (e.g., 300 seconds), ignoring lower authoritative TTLs. Architects must account for this behavior when establishing realistic multi-region Recovery Time Objectives (RTO).

---

Multi-Region Patterns: Active-Active vs. Active-Passive

Enterprise architects must choose between two primary multi-region deployment topologies:

1. Active-Passive (Disaster Recovery): Production traffic routes exclusively to the primary region. The secondary region maintains either a minimal "pilot light" environment or a fully pre-provisioned warm standby. Cross-region data replication maintains database and storage synchronization. A Failover steering policy redirects traffic only when catastrophic regional impairment occurs.
2. Active-Active (Global Load Sharing): User traffic is actively served by two or more regions simultaneously via Geolocation Steering or weighted Load Balancer policies. This pattern eliminates failover delay and maximizes hardware utilization, but requires bidirectional database synchronization (e.g., OCI GoldenGate) and robust conflict-resolution mechanisms to prevent split-brain inconsistencies.