OCINetworkingintermediate

OCI DNS & Traffic Management

Configure OCI DNS zones, steering policies for failover and geo-routing, health checks, private DNS, and DNSSEC.

CloudToolStack Team22 min readPublished Mar 14, 2026

Prerequisites

Basic understanding of DNS concepts and record types
OCI account with DNS management permissions

Introduction to OCI DNS and Traffic Management

DNS (Domain Name System) is the foundation of every internet-facing application. It translates human-readable domain names into IP addresses, routes traffic to the correct servers, and enables advanced traffic management strategies like failover, geographic routing, and load distribution. Oracle Cloud Infrastructure provides a highly available, globally distributed DNS service with integrated traffic management capabilities.

OCI DNS offers two distinct but complementary capabilities. The core DNS service manages DNS zones, records, and resolution for your domains. The Traffic Management service adds intelligent steering policies that route traffic based on health checks, geographic location, weighted distribution, or priority-based failover. Together, they enable sophisticated global traffic routing without any additional infrastructure.

This guide covers both services in depth: creating and managing DNS zones, configuring record types, implementing steering policies for traffic management, setting up health checks for endpoint monitoring, designing multi-region failover architectures, and integrating DNS with OCI load balancers and CDN services.

OCI DNS Features

OCI DNS provides an authoritative DNS service with a 100% uptime SLA backed by a globally distributed Anycast network. Key features include support for all standard record types (A, AAAA, CNAME, MX, TXT, SRV, CAA, NS), DNSSEC for domain security, Traffic Management steering policies, HTTP and TCP health checks, private DNS for VCN-internal resolution, and resolver endpoints for hybrid DNS architectures. DNS queries are free; you pay only for the zones and health checks you create.

DNS Zones and Records

A DNS zone represents a domain or subdomain and contains all the DNS records for that domain. OCI supports both public zones (resolvable from the internet) and private zones (resolvable only within specific VCNs). Public zones require that your domain registrar delegates name server authority to OCI's name servers.

Creating a Public DNS Zone

bash

# Create a public DNS zone
oci dns zone create \
  --compartment-id <compartment-ocid> \
  --name "example.com" \
  --zone-type PRIMARY

# Get the zone details (including OCI name servers)
oci dns zone get \
  --zone-name-or-id "example.com" \
  --query 'data.{"Name": name, "State": "lifecycle-state", "Nameservers": nameservers[].hostname}' \
  --output json

# IMPORTANT: Update your domain registrar to use OCI name servers:
# ns1.p201.dns.oraclecloud.net
# ns2.p201.dns.oraclecloud.net
# ns3.p201.dns.oraclecloud.net
# ns4.p201.dns.oraclecloud.net

# Add an A record pointing to your load balancer
oci dns record domain patch \
  --zone-name-or-id "example.com" \
  --domain "example.com" \
  --items '[{
    "domain": "example.com",
    "rtype": "A",
    "rdata": "129.146.10.50",
    "ttl": 300
  }]'

# Add a CNAME for www subdomain
oci dns record domain patch \
  --zone-name-or-id "example.com" \
  --domain "www.example.com" \
  --items '[{
    "domain": "www.example.com",
    "rtype": "CNAME",
    "rdata": "example.com.",
    "ttl": 300
  }]'

# Add MX records for email
oci dns record domain patch \
  --zone-name-or-id "example.com" \
  --domain "example.com" \
  --items '[
    {
      "domain": "example.com",
      "rtype": "MX",
      "rdata": "10 mail1.example.com.",
      "ttl": 3600
    },
    {
      "domain": "example.com",
      "rtype": "MX",
      "rdata": "20 mail2.example.com.",
      "ttl": 3600
    }
  ]'

# Add TXT record for SPF (email authentication)
oci dns record domain patch \
  --zone-name-or-id "example.com" \
  --domain "example.com" \
  --items '[{
    "domain": "example.com",
    "rtype": "TXT",
    "rdata": "\"v=spf1 include:_spf.google.com ~all\"",
    "ttl": 3600
  }]'

# List all records in a zone
oci dns record zone get \
  --zone-name-or-id "example.com" \
  --query 'data.items[].{"Domain": domain, "Type": rtype, "TTL": ttl, "Data": rdata}' \
  --output table

Private DNS Zones

Private DNS zones resolve names only within specified VCNs. They are essential for internal service discovery, database hostnames, and microservice communication without exposing internal names to the internet. Private zones override public DNS resolution, so you can use them to create split-horizon DNS where internal users resolve a domain to a private IP while external users resolve the same domain to a public IP.

bash

# Create a private DNS zone
oci dns zone create \
  --compartment-id <compartment-ocid> \
  --name "internal.example.com" \
  --zone-type PRIMARY \
  --scope PRIVATE \
  --view-id <private-view-ocid>

# Create a private DNS view (if not using default)
oci dns view create \
  --compartment-id <compartment-ocid> \
  --display-name "internal-view" \
  --scope PRIVATE

# Associate the view with a VCN resolver
oci dns resolver get \
  --resolver-id <resolver-ocid> \
  --scope PRIVATE

# Add records to the private zone
oci dns record domain patch \
  --zone-name-or-id "internal.example.com" \
  --domain "db-primary.internal.example.com" \
  --scope PRIVATE \
  --view-id <private-view-ocid> \
  --items '[{
    "domain": "db-primary.internal.example.com",
    "rtype": "A",
    "rdata": "10.0.2.50",
    "ttl": 60
  }]'

# Add SRV records for service discovery
oci dns record domain patch \
  --zone-name-or-id "internal.example.com" \
  --domain "_api._tcp.internal.example.com" \
  --scope PRIVATE \
  --view-id <private-view-ocid> \
  --items '[
    {
      "domain": "_api._tcp.internal.example.com",
      "rtype": "SRV",
      "rdata": "10 60 8080 api-1.internal.example.com.",
      "ttl": 60
    },
    {
      "domain": "_api._tcp.internal.example.com",
      "rtype": "SRV",
      "rdata": "10 40 8080 api-2.internal.example.com.",
      "ttl": 60
    }
  ]'

DNS for Hybrid Cloud

For hybrid architectures where on-premises resources need to resolve OCI private DNS names (and vice versa), configure DNS resolver endpoints. Create a listening endpoint in OCI that accepts queries from on-premises DNS servers, and a forwarding endpoint that sends queries for on-premises domains to your on-premises DNS servers. This enables seamless name resolution across your VPN or FastConnect connection without modifying application code.

Health Checks

OCI Health Checks monitor the availability and performance of your endpoints from multiple global vantage points. Health checks are the foundation of traffic management steering policies because they determine which endpoints are healthy enough to receive traffic. OCI supports HTTP, HTTPS, and TCP health checks with configurable intervals, timeouts, and thresholds.

bash

# Create an HTTP health check
oci health-checks http-monitor create \
  --compartment-id <compartment-ocid> \
  --display-name "api-us-ashburn" \
  --targets '["api.us-ashburn-1.example.com"]' \
  --protocol HTTPS \
  --port 443 \
  --path "/health" \
  --method GET \
  --interval-in-seconds 30 \
  --timeout-in-seconds 10 \
  --is-enabled true \
  --vantage-point-names '["aws-iad", "goo-chs", "azr-sjc"]'

# Create a health check for a secondary region
oci health-checks http-monitor create \
  --compartment-id <compartment-ocid> \
  --display-name "api-us-phoenix" \
  --targets '["api.us-phoenix-1.example.com"]' \
  --protocol HTTPS \
  --port 443 \
  --path "/health" \
  --method GET \
  --interval-in-seconds 30 \
  --timeout-in-seconds 10 \
  --is-enabled true

# Create a TCP health check for a non-HTTP service
oci health-checks ping-monitor create \
  --compartment-id <compartment-ocid> \
  --display-name "db-health" \
  --targets '["db.example.com"]' \
  --protocol TCP \
  --port 1521 \
  --interval-in-seconds 30 \
  --timeout-in-seconds 10 \
  --is-enabled true

# View health check results
oci health-checks http-monitor list \
  --compartment-id <compartment-ocid> \
  --query 'data[].{"Name": "display-name", "Protocol": protocol, "Interval": "interval-in-seconds", "Enabled": "is-enabled"}' \
  --output table

# Get detailed results for a specific health check
oci health-checks http-probe-result list \
  --probe-configuration-id <health-check-ocid> \
  --query 'data[].{"Vantage Point": "vantage-point-name", "Status": "status-code", "Latency (ms)": "connect-end", "Time": "start-time"}' \
  --output table

Traffic Management Steering Policies

Steering policies are the core of OCI Traffic Management. A steering policy defines a set of rules that determine which DNS answer to return based on criteria like health check status, geographic location, weighted distribution, or priority. OCI provides several policy templates for common routing patterns.

Steering Policy Templates

Template	Use Case	How It Works
FAILOVER	Active-passive DR	Returns primary answer; switches to secondary on failure
LOAD_BALANCE	Distribute traffic	Returns answers based on weighted round-robin
ROUTE_BY_GEO	Geographic routing	Returns closest endpoint based on client location
ROUTE_BY_ASN	ISP-based routing	Returns endpoint based on client ASN
ROUTE_BY_IP	IP prefix routing	Returns endpoint based on client IP prefix

Failover Steering Policy

bash

# Create a failover steering policy
oci dns steering-policy create \
  --compartment-id <compartment-ocid> \
  --display-name "api-failover" \
  --template FAILOVER \
  --ttl 30 \
  --health-check-monitor-id <health-check-ocid> \
  --answers '[
    {
      "name": "primary-ashburn",
      "rtype": "A",
      "rdata": "129.146.10.50",
      "pool": "primary",
      "isDisabled": false
    },
    {
      "name": "secondary-phoenix",
      "rtype": "A",
      "rdata": "129.213.20.100",
      "pool": "secondary",
      "isDisabled": false
    }
  ]' \
  --rules '[
    {
      "ruleType": "FILTER",
      "defaultAnswerData": [
        {"answerCondition": "answer.isDisabled != true", "shouldKeep": true}
      ]
    },
    {
      "ruleType": "HEALTH",
      "cases": [
        {"caseCondition": "answer.pool == \u0027primary\u0027"}
      ]
    },
    {
      "ruleType": "PRIORITY",
      "defaultAnswerData": [
        {"answerCondition": "answer.pool == \u0027primary\u0027", "value": 1},
        {"answerCondition": "answer.pool == \u0027secondary\u0027", "value": 2}
      ]
    }
  ]'

# Attach the steering policy to a domain
oci dns steering-policy-attachment create \
  --steering-policy-id <policy-ocid> \
  --zone-id <zone-ocid> \
  --domain-name "api.example.com"

# Verify the attachment
oci dns steering-policy-attachment list \
  --compartment-id <compartment-ocid> \
  --query 'data[].{"Domain": "domain-name", "Policy": "display-name", "Zone": "zone-id", "State": "lifecycle-state"}' \
  --output table

Geographic Routing Policy

bash

# Create a geo-based routing policy
oci dns steering-policy create \
  --compartment-id <compartment-ocid> \
  --display-name "app-geo-routing" \
  --template ROUTE_BY_GEO \
  --ttl 60 \
  --health-check-monitor-id <health-check-ocid> \
  --answers '[
    {
      "name": "us-east",
      "rtype": "A",
      "rdata": "129.146.10.50",
      "pool": "americas",
      "isDisabled": false
    },
    {
      "name": "eu-frankfurt",
      "rtype": "A",
      "rdata": "132.145.30.75",
      "pool": "europe",
      "isDisabled": false
    },
    {
      "name": "ap-tokyo",
      "rtype": "A",
      "rdata": "140.238.40.100",
      "pool": "asia-pacific",
      "isDisabled": false
    }
  ]' \
  --rules '[
    {
      "ruleType": "FILTER",
      "defaultAnswerData": [
        {"answerCondition": "answer.isDisabled != true", "shouldKeep": true}
      ]
    },
    {
      "ruleType": "HEALTH"
    },
    {
      "ruleType": "LIMIT",
      "defaultCount": 1,
      "cases": [
        {
          "caseCondition": "query.client.address in (geoKey \u0027North America\u0027)",
          "count": 1
        },
        {
          "caseCondition": "query.client.address in (geoKey \u0027Europe\u0027)",
          "count": 1
        },
        {
          "caseCondition": "query.client.address in (geoKey \u0027Asia\u0027)",
          "count": 1
        }
      ]
    }
  ]'

DNS TTL and Failover Speed

The DNS TTL (Time to Live) directly affects how fast clients switch to a healthy endpoint during failover. A TTL of 300 seconds (5 minutes) means clients may continue sending traffic to a failed endpoint for up to 5 minutes after failover. For critical applications, use a low TTL (30-60 seconds) on steering policy attachments. Be aware that some DNS resolvers ignore low TTLs, so actual failover time may be longer. Browsers and operating systems also cache DNS results, adding to the effective TTL.

DNSSEC Configuration

DNSSEC (Domain Name System Security Extensions) protects against DNS spoofing and cache poisoning by digitally signing DNS records. When DNSSEC is enabled, DNS resolvers can verify that the records they receive are authentic and have not been tampered with in transit. OCI DNS supports DNSSEC for public zones with automatic key management.

bash

# Enable DNSSEC on a zone
oci dns zone update \
  --zone-name-or-id "example.com" \
  --dnssec-state ENABLED

# Get the DS record to configure at your registrar
oci dns zone get \
  --zone-name-or-id "example.com" \
  --query 'data."dnssec-config"."ksk-dnssec-key-versions"[].{"Key Tag": "key-tag", "Algorithm": algorithm, "Digest Type": "digest-type", "Digest": digest}' \
  --output table

# Verify DNSSEC is working (from any machine with dig)
# dig +dnssec example.com A
# Look for the "ad" (authenticated data) flag in the response

DNS Integration Patterns

DNS is often the glue that connects different parts of your infrastructure. Here are common integration patterns for OCI DNS with other services and multi-cloud architectures.

Common DNS Patterns

Pattern	Use Case	OCI Implementation
Blue-Green via DNS	Zero-downtime deployments	Update A record to point to new environment
Canary via Weighted	Gradual rollout	Weighted steering policy (90/10 split)
Multi-CDN	CDN resilience	Health-checked failover between CDN endpoints
Hybrid Resolution	On-prem + cloud	Forwarding rules + resolver endpoints
Service Discovery	Internal microservices	Private DNS zones with SRV records

When integrating DNS with OCI Load Balancers, point your DNS records to the load balancer's public IP address rather than individual compute instance IPs. This allows the load balancer to handle instance health checking and traffic distribution while DNS handles global routing. For multi-region architectures, combine steering policies with per-region load balancers: the steering policy routes users to the nearest region, and the load balancer within that region distributes traffic across instances.

Always set appropriate TTLs based on your requirements. Use short TTLs (30-60 seconds) for records that change during failover events. Use longer TTLs (3600 seconds or more) for stable records like MX records to reduce DNS query volume and improve resolution speed. Monitor your DNS query volume and resolution latency using OCI Monitoring to detect anomalies and validate that your steering policies are working correctly.

OCI Disaster Recovery OCI VCN Networking Deep Dive OCI Security Best Practices

Key Takeaways

1OCI DNS provides a 100% uptime SLA backed by a globally distributed Anycast network.
2Steering policies enable failover, weighted load balancing, and geographic routing.
3Private DNS zones enable internal service discovery within VCNs.
4Health checks monitor endpoint availability from global vantage points for traffic management.

Frequently Asked Questions

How does OCI Traffic Management differ from a load balancer?

Traffic Management operates at the DNS level, returning different IP addresses based on health, geography, or weight. It routes users to different endpoints (potentially in different regions) before they connect. Load balancers operate at the network level, distributing connections across backends at a single endpoint. Use both together: Traffic Management for global routing, load balancers for local distribution.

Does OCI DNS support DNSSEC?

Yes, OCI DNS supports DNSSEC for public zones with automatic key management. When enabled, DNS records are digitally signed so resolvers can verify authenticity. You need to configure the DS record at your domain registrar to complete the chain of trust.

Written by CloudToolStack Team

Cloud engineers and architects with hands-on experience across AWS, Azure, and GCP. We write guides based on real-world production patterns, not just documentation rewrites.

Disclaimer: This guide is for educational purposes. Cloud services change frequently; always refer to official documentation for the latest information. AWS, Azure, and GCP are trademarks of their respective owners.