Oracle Cloud DNS and Traffic Management Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Networking, Edge, and Connectivity

1. Introduction

Oracle Cloud Infrastructure (OCI) DNS and Traffic Management is the set of capabilities used to publish authoritative DNS records for your domains and intelligently direct users to the best endpoint (or a healthy endpoint) using policy-based DNS responses.

In simple terms: DNS makes your application reachable by name (like www.example.com), and Traffic Management helps decide which IP address (or endpoint) DNS should return to each client—based on health, geography, weights, or other rules.

Technically, OCI DNS provides public and private managed DNS zones, record management APIs, and DNSSEC (where applicable). OCI Traffic Management is implemented through Traffic Management steering policies and steering policy attachments that dynamically answer DNS queries according to defined rules—often integrating with OCI Health Checks for failover and high availability.

This service solves problems like: – Replacing manual DNS changes during outages with automatic DNS-based failover – Sending users to the closest or best-performing endpoint – Implementing blue/green or canary rollouts via weighted DNS – Centralizing DNS governance in Oracle Cloud with IAM-controlled changes and auditability

Naming note (scope clarification): In OCI, DNS is the primary service name in the console and documentation, and Traffic Management is a closely related capability delivered through Traffic Management steering policies. Oracle documentation often presents them together. This tutorial uses “DNS and Traffic Management” as the umbrella term, exactly as provided.

2. What is DNS and Traffic Management?

Official purpose

DNS and Traffic Management in Oracle Cloud provides: – Authoritative DNS hosting (public DNS zones) to publish records on the internet – Private DNS (private zones/views associated with VCNs) for internal name resolution – Traffic steering (Traffic Management steering policies) to control DNS answers dynamically for routing and resilience

Core capabilities

Create and manage DNS zones (public and private, depending on your needs)
Create and update DNS records (A/AAAA/CNAME/TXT/MX and other supported types—verify supported record types in official docs for your use case)
Apply Traffic Management steering policies (failover, load distribution, geo steering, and more)
Integrate with Health Checks to avoid returning unhealthy endpoints
Sign zones with DNSSEC (where supported) to protect DNS integrity

Major components (OCI terminology)

Common OCI objects you will see: – Zone: A DNS zone you manage (public or private) – Record / RRSet: Resource records for names in the zone – Steering policy: A Traffic Management policy defining how DNS answers are selected – Steering policy attachment: Binds a steering policy to a specific DNS name (like www.example.com) and a zone – Health check (separate OCI service): Actively probes endpoints and supplies health signals to steering policies – Views / Private DNS constructs: Used for split-horizon and internal DNS patterns (verify current Private DNS constructs and naming in docs, as OCI has evolved this area over time)

Service type

Managed cloud networking service (authoritative DNS + policy-driven DNS answering)
Control plane accessed via OCI Console, OCI CLI, SDKs, and REST APIs

Scope: regional/global and tenancy boundaries

DNS is generally treated as a global service in OCI from an authoritative DNS standpoint, even though you select regions in the Console experience for administration.
DNS resources are tenancy-scoped and organized with compartments for access control and governance.
Traffic Management steering policies are managed within OCI and attached to names in zones.

Always confirm current scope details (global vs region-specific behavior) in the official docs for DNS, Traffic Management, and Health Checks, especially for compliance-driven architectures.

How it fits into the Oracle Cloud ecosystem

DNS and Traffic Management sits at the front door of OCI deployments within Networking, Edge, and Connectivity: – Points users to OCI Load Balancers, Compute instances, API Gateways, or external endpoints – Works alongside OCI WAF (application protection), OCI CDN (content caching, if used), and Load Balancing (L4/L7 routing) – Uses OCI IAM for fine-grained change control, and Audit for API-call tracking – Integrates strongly with OCI Health Checks for resilient routing decisions

3. Why use DNS and Traffic Management?

Business reasons

Reduce downtime impact: automatic DNS failover can keep customer-facing services reachable during incidents.
Improve global experience: steer users to regionally appropriate endpoints, improving latency and satisfaction.
Simplify operations: centralize DNS ownership and change process within OCI.
Support migrations: gradually move traffic from on-prem or another cloud into OCI using weighted steering.

Technical reasons

Authoritative DNS hosting with API-driven management
Policy-based DNS responses (Traffic Management steering policies)
Health-aware routing (avoid dead IPs)
DNSSEC support to reduce DNS spoofing risks (where applicable)

Operational reasons

Compartment-based governance: separate dev/test/prod and enforce least privilege
Automation: manage zones/records/policies via Terraform (commonly used), CLI, or SDKs (verify latest provider support and resource names)
Auditability: track who changed DNS and when via OCI Audit

Security/compliance reasons

IAM enforcement: only approved groups can modify zones/records/policies
DNSSEC: strengthen integrity of DNS answers (subject to your registrar and DNSSEC chain of trust)
Change control: implement tagging, approvals, and automation pipelines

Scalability/performance reasons

DNS is inherently a scale component—OCI runs authoritative DNS infrastructure so you don’t have to build and maintain it.
Traffic Management policies let you scale across multiple endpoints/regions without forcing all traffic through a single load balancer.

When teams should choose it

Choose OCI DNS and Traffic Management when you need: – Managed DNS for public zones used by applications – DNS-based global routing and/or failover – A clean way to run multi-region or hybrid routing strategies – OCI-governed DNS changes integrated with your IAM model

When teams should not choose it

Consider alternatives when: – You need application-layer routing decisions (headers, paths, cookies). DNS can’t see those; use OCI Load Balancing or an ingress/API gateway layer. – You require instant traffic shifting with no caching effects. DNS is cached; even low TTLs are not perfect. – You need DoH/DoT endpoint services from your authoritative provider (verify OCI capabilities; do not assume). – You want a “single pane of glass” DNS provider across many clouds and registrars with advanced vendor-specific features (some organizations use Cloudflare/NS1, etc.).

4. Where is DNS and Traffic Management used?

Industries

SaaS and internet applications (public endpoints)
Financial services (careful change control, DNSSEC, high availability)
E-commerce (multi-region resilience)
Media and gaming (traffic steering, rollout control)
Enterprise internal platforms (private DNS for internal services)

Team types

Platform engineering and SRE teams managing shared DNS platforms
Network engineers managing authoritative zones and delegations
DevOps engineers automating record changes and cutovers
Security teams enforcing DNSSEC and least privilege
Application teams needing controlled rollouts (canary/blue-green)

Workloads

Public web applications and APIs
Multi-region active-active or active-passive designs
Hybrid (on-prem + OCI) with staged migrations
Kubernetes ingress endpoints (DNS to LB frontends)
Disaster recovery designs using DNS failover to a standby region

Architectures

Single region + DR region (DNS failover)
Global multi-region with geolocation steering
Weighted rollouts during migration or version releases
Split-horizon internal DNS (private zones) for service discovery patterns

Real-world deployment contexts

Production: delegated zones at registrar, DNSSEC enabled (when required), change approvals, health checks, and tested failover runbooks
Dev/test: non-delegated zones queried directly by authoritative nameserver (useful for learning), short TTLs, and isolated compartments

5. Top Use Cases and Scenarios

Below are realistic ways teams use Oracle Cloud DNS and Traffic Management.

1) Automatic regional failover for a public API

Problem: Region A outage makes api.company.com unreachable.
Why it fits: Steering policy + health checks can stop returning Region A endpoint and return Region B instead.
Example: Primary endpoint is an OCI Load Balancer in us-ashburn-1, secondary in us-phoenix-1.

2) Active-active multi-region DNS load distribution

Problem: One region can’t handle peak load alone.
Why it fits: Weighted answers distribute traffic across endpoints.
Example: Return both regions with weights 60/40 and adjust during events.

3) Blue/green deployment cutover

Problem: Need low-risk release with easy rollback.
Why it fits: Weighted steering gradually increases traffic to “green.”
Example: Start 95% old LB, 5% new LB; ramp to 50/50; then 100% green.

4) Canary testing with internal users

Problem: Want a small subset of clients to hit a new endpoint.
Why it fits: DNS policies can target by geography/ASN (capability depends on supported rules—verify).
Example: Route EU traffic to new endpoint first.

5) Hybrid migration from on-prem to OCI

Problem: Move workloads without a “big bang” DNS cutover.
Why it fits: Use weighted or priority rules between on-prem VIP and OCI LB.
Example: 80% on-prem, 20% OCI; gradually invert.

6) Multi-cloud continuity design

Problem: OCI is primary, but must fail over to another provider.
Why it fits: Steering answers can include non-OCI endpoints as well.
Example: Primary OCI LB, secondary AWS ALB IP/hostname (depending on DNS record type suitability).

7) Maintain availability during maintenance windows

Problem: Planned maintenance requires draining a site.
Why it fits: Adjust weights or priority to steer away temporarily.
Example: Move all traffic to Region B for 2 hours.

8) Improve latency by steering users geographically

Problem: Global users experience high latency to a single region.
Why it fits: Geolocation steering returns region-local answers.
Example: APAC users -> Singapore, EMEA -> Frankfurt, AMER -> Ashburn.

9) Health-aware endpoint selection for IoT ingest

Problem: Devices post to a DNS name; endpoints occasionally degrade.
Why it fits: Health checks prevent returning unhealthy collectors.
Example: Return only healthy ingest nodes for ingest.example.com.

10) SaaS tenant isolation by DNS subdomain patterns

Problem: Different tenants must resolve to different frontends.
Why it fits: Separate DNS names and attachments per tenant, managed by compartments/tags.
Example: tenant-a.app.com -> endpoint group A, tenant-b.app.com -> endpoint group B.

6. Core Features

This section focuses on commonly used, current capabilities of OCI DNS and Traffic Management. Always confirm exact record types, policy rules, and limits in official documentation.

6.1 Managed DNS zones (public)

What it does: Hosts authoritative DNS zones and answers internet queries for delegated domains.
Why it matters: You don’t manage DNS servers, patching, scaling, or availability.
Practical benefit: Faster domain changes via API/console; consistent governance via OCI IAM.
Caveats: You must delegate your domain at the registrar for real-world usage; DNS propagation and caching apply.

6.2 Private DNS capabilities (private zones / split-horizon patterns)

What it does: Provides internal-only DNS naming within OCI networking contexts (commonly VCN-associated).
Why it matters: Clean service discovery and internal routing without exposing names publicly.
Practical benefit: Avoid hardcoding IPs; standardize internal naming conventions.
Caveats: Private DNS behavior depends on OCI networking constructs (views/resolvers). Verify current Private DNS features and constraints in docs before designing.

6.3 Record management (RRsets, TTL control, common record types)

What it does: Create/update/delete DNS records and sets (e.g., A, AAAA, CNAME, TXT, MX, SRV, NS).
Why it matters: DNS is the canonical directory for many systems (web, email, service discovery).
Practical benefit: Use short TTLs for migration windows, longer TTLs for stable records.
Caveats: Apex CNAME is generally not allowed in DNS standards; providers often offer ALIAS/ANAME-style features—verify OCI support and semantics for your needs.

6.4 Traffic Management steering policies

What it does: Defines how OCI chooses DNS answers based on a rule set (weights, priority, filters, geo, ASN, health, limits—verify supported rule types in current docs).
Why it matters: Enables resilient and controlled routing without changing application code.
Practical benefit: Implement failover, active-active, regional steering, and rollout strategies.
Caveats: DNS is still DNS—client caching, recursive resolver behavior, and TTLs affect responsiveness.

6.5 Steering policy attachments

What it does: Attaches a steering policy to a specific domain name in a zone (for example, apply policy to www.example.com).
Why it matters: You can reuse the same policy pattern across names, or apply different policies to different subdomains.
Practical benefit: Clean separation between policy logic and DNS naming.
Caveats: Attachments are part of the DNS answer path for that name; plan lifecycle and ownership carefully.

6.6 Integration with OCI Health Checks

What it does: Performs active probing (HTTP/HTTPS/TCP—verify options) from OCI vantage points and reports health.
Why it matters: Traffic steering without health can send users to dead endpoints.
Practical benefit: Automated failover and safer load distribution.
Caveats: Health checks are an external signal and can be affected by firewall rules, WAF policies, rate limits, and transient internet routing.

6.7 DNSSEC (Domain Name System Security Extensions)

What it does: Cryptographically signs DNS responses to help resolvers validate authenticity.
Why it matters: Reduces risk of DNS spoofing/cache poisoning for validating resolvers.
Practical benefit: Stronger trust in your domain answers.
Caveats: DNSSEC requires careful key and delegation handling with your registrar; misconfiguration can cause resolution failures.

6.8 Automation (Console, API, CLI, SDKs, Terraform)

What it does: Manage DNS zones/records/policies programmatically.
Why it matters: DNS changes are infrastructure changes; they benefit from version control and CI/CD.
Practical benefit: Repeatable environments, safer migrations, standardized naming.
Caveats: Ensure your automation handles eventual consistency and safe rollbacks.

6.9 IAM governance via compartments and policies

What it does: Controls who can create/modify zones, records, and steering policies.
Why it matters: DNS changes can cause outages or security incidents.
Practical benefit: Least privilege, separation of duties, and auditable operations.
Caveats: Mis-scoped IAM policies can block incident response or allow overly broad access.

7. Architecture and How It Works

High-level architecture

At a high level: 1. A client queries a recursive resolver (ISP, enterprise, or public resolver). 2. The resolver follows delegation to your OCI authoritative DNS nameservers. 3. OCI DNS returns records: – Standard static records, or – Dynamic answers computed from a steering policy (Traffic Management) 4. Client connects to the returned endpoint (IP/LB hostname target).

Request/data/control flow

Control plane: You create zones, records, and steering policies through OCI Console/API/CLI/SDK/Terraform.
Data plane: DNS queries from resolvers to OCI authoritative nameservers; health-check probes from OCI Health Checks to your endpoints.

Key integrations (common patterns)

OCI Load Balancing: DNS points to public LB. Traffic Management can distribute/fail over between LBs.
OCI Compute: DNS points directly to instance public IPs (simple labs; less common in production).
OCI Health Checks: Provides endpoint health to steering policies.
OCI IAM + Audit: Access control + change tracking.
OCI WAF / CDN (where used): DNS points to WAF/CDN front door; steering can operate at that level across regions.

Dependencies to plan for

A working endpoint (LB or instance) that accepts traffic from health checkers
Network security rules (security lists/NSGs) allowing health checks and user traffic
A domain strategy (public delegation at registrar for production)
A monitoring strategy for the endpoints (DNS won’t tell you app performance, only where clients go)

Security/authentication model

Management uses OCI IAM:
Users/groups with policies to manage DNS and Traffic Management objects
API calls are signed with OCI credentials (Console/CLI/SDK)
Query plane is public DNS protocol; security is improved with DNSSEC where applicable.

Networking model (practical view)

DNS authoritative endpoints are managed by OCI.
Your endpoints (LBs/instances) sit in your VCN or outside OCI.
Health checks originate from OCI-managed vantage points; endpoints must allow that inbound traffic (verify recommended allowlists in Health Checks docs).

Monitoring/logging/governance considerations

Use OCI Audit to track DNS changes.
Monitor endpoint availability with OCI Health Checks and/or OCI Monitoring on the workloads.
Use tags and compartment structure for cost allocation and governance.
Consider external monitoring from another provider to validate real-world DNS resolution and application reachability.

Simple architecture diagram (Mermaid)

flowchart LR
  U[User Device] --> R[Recursive Resolver]
  R -->|DNS query| OCI_DNS[OCI Authoritative DNS]
  OCI_DNS -->|Steering policy answer| R
  R --> U
  U -->|HTTP/HTTPS| EP1[Endpoint A\n(OCI LB / Compute)]
  U -->|HTTP/HTTPS| EP2[Endpoint B\n(OCI LB / DR Region)]
  HC[OCI Health Checks] -->|Probes| EP1
  HC -->|Probes| EP2

Production-style architecture diagram (Mermaid)

flowchart TB
  subgraph Internet
    Users[Users]
    Resolvers[Recursive DNS Resolvers]
  end

  subgraph OCI_Global["OCI DNS and Traffic Management (Global)"]
    AuthDNS[Authoritative DNS Zones]
    Steering[Traffic Management\nSteering Policies + Attachments]
  end

  subgraph RegionA["OCI Region A"]
    WAF_A[WAF / Edge Policy\n(optional)]
    LB_A[Public Load Balancer]
    App_A[App Tier]
    DB_A[(Database)]
  end

  subgraph RegionB["OCI Region B (DR or Active-Active)"]
    WAF_B[WAF / Edge Policy\n(optional)]
    LB_B[Public Load Balancer]
    App_B[App Tier]
    DB_B[(Database / Replica)]
  end

  Health[OCI Health Checks]:::svc

  Users --> Resolvers
  Resolvers -->|DNS| AuthDNS
  AuthDNS --> Steering
  Steering -->|Answer A or B| Resolvers
  Users -->|HTTP/HTTPS| WAF_A
  Users -->|HTTP/HTTPS| WAF_B
  WAF_A --> LB_A --> App_A --> DB_A
  WAF_B --> LB_B --> App_B --> DB_B

  Health -->|Probe| LB_A
  Health -->|Probe| LB_B

  classDef svc fill:#f6f6f6,stroke:#888,stroke-width:1px;

8. Prerequisites

Tenancy/account requirements

An Oracle Cloud (OCI) tenancy with permission to create networking and DNS resources.
A compartment strategy:
One compartment for the lab (recommended), separate from production.

Permissions / IAM policies

You need permission to manage: – DNS zones and records – Traffic Management steering policies and attachments – Health Checks (for health-based steering) – Compute/Networking (for lab endpoints)

Example IAM policies (adjust group and compartment names):

Allow group DNS-Lab-Admins to manage dns in compartment DNS-Lab
Allow group DNS-Lab-Admins to manage health-checks in compartment DNS-Lab
Allow group DNS-Lab-Admins to manage virtual-network-family in compartment DNS-Lab
Allow group DNS-Lab-Admins to manage instance-family in compartment DNS-Lab

Exact policy verbs and resource families can vary by OCI service design. Verify required IAM policy statements in the official OCI docs if you see authorization errors.

Billing requirements

DNS may not have a direct line-item charge in many cases, but related resources do:
Compute instances, Load Balancers, outbound data transfer, and possibly Health Checks depending on your usage and pricing model.
Use Oracle Cloud Free Tier / Always Free where possible for a low-cost lab (verify current Free Tier eligibility and quotas in your tenancy/region).

Tools (recommended)

OCI Console (web UI)
OCI CLI (optional but helpful): https://docs.oracle.com/en-us/iaas/Content/API/SDKDocs/cliinstall.htm
dig (DNS query tool) on your workstation
ssh client if you create compute instances for endpoints

Region availability

OCI DNS is generally available across OCI regions (service availability can vary).
Choose a region where you can also create compute instances for the lab.

Quotas / limits

DNS zones, records, steering policies, and health checks have service limits.
Check OCI Service Limits for DNS, Traffic Management, and Health Checks in your region/tenancy.

Prerequisite services for the lab

OCI Virtual Cloud Network (VCN) with a public subnet (for HTTP endpoints)
Two compute instances (optional but used in this tutorial)
OCI Health Checks

9. Pricing / Cost

Pricing model (how costs are typically incurred)

For DNS and Traffic Management, costs can come from: 1. DNS service usage (zone hosting, queries, and advanced features) — pricing may be $0 or billed depending on Oracle’s current model and your contract. 2. Traffic Management (steering policies/attachments) — often priced as part of DNS, but confirm. 3. Health Checks — may have its own pricing dimension (number of checks, frequency, probe regions/vantage points). Verify current pricing. 4. Endpoints you route to: – Compute instances – Load Balancers (commonly a major cost driver) – WAF/CDN (if used) 5. Data transfer: – Internet egress from your endpoints (not DNS itself, but the traffic you direct)

Official pricing sources (verify current SKUs)

Oracle Cloud Pricing overview: https://www.oracle.com/cloud/pricing/
Oracle Cloud Price List (search for DNS, Health Checks, Load Balancer): https://www.oracle.com/cloud/price-list/
OCI Cost Estimator: https://www.oracle.com/cloud/costestimator.html

Do not rely on third-party blogs for OCI pricing. Always validate on Oracle’s official pricing pages or your contracted rate card.

Pricing dimensions to expect (conceptually)

Depending on Oracle’s current pricing for your region/contract, you may see: – Number of DNS zones (public and/or private) – Volume of DNS queries (authoritative query count) – Number of steering policy attachments (names using Traffic Management) – Number of health checks, check interval, and probe distribution – Compute/LB hourly rates and throughput – Outbound internet data transfer (GB)

Free tier considerations

OCI Free Tier often includes Always Free compute shapes and limited networking usage.
Whether DNS and Traffic Management and Health Checks are free or included depends on Oracle’s current policy—verify in pricing docs and your tenancy’s Free Tier details.

Cost drivers (what increases your bill)

Large DNS query volumes to authoritative servers
Many attachments and many endpoints per policy
Short health check intervals (more probes)
Using paid LBs/WAF/CDN in multiple regions
High outbound traffic from endpoints (internet egress)

Hidden/indirect costs

Operational costs: staff time to manage DNS changes, incident response, and testing
Multi-region duplication: duplicate LBs and app stacks in two regions
Certificate management: if you add HTTPS endpoints, cert operations may involve other services/tools

Cost optimization tips

Use longer TTLs for stable records; use shorter TTLs only for migration windows.
Prefer Traffic Management at strategic entry points (like www and api) rather than on thousands of per-tenant names unless needed.
Avoid over-provisioning health checks; align check frequency with RTO/RPO goals.
For production, consider routing to Load Balancers (stable) rather than ephemeral instance IPs.

Example low-cost starter estimate (no fabricated numbers)

A minimal lab can be near-zero cost if you: – Use Always Free compute (if available) – Avoid paid load balancers – Keep DNS zones and health checks within free allowances (if applicable)

Because exact pricing varies by region and Oracle policy, verify in the official price list before assuming $0.

Example production cost considerations

In production, the bill is commonly dominated by: – Regional load balancers (hourly + bandwidth/LCU-style metrics depending on SKU) – Multi-region duplication (two of everything) – Outbound internet data transfer DNS and steering policies are usually a smaller fraction, but high query volume can change that—measure authoritative query rates and plan accordingly.

10. Step-by-Step Hands-On Tutorial

Objective

Deploy a small, real DNS and Traffic Management setup in Oracle Cloud: – Create two HTTP endpoints (two small OCI compute instances) – Create health checks for both endpoints – Create a DNS zone and a Traffic Management steering policy – Attach the policy to a DNS name and verify automatic failover

Lab Overview

You will build: – web-a: Nginx server returning “A” – web-b: Nginx server returning “B” – Health checks: probe both servers – DNS zone: lab.example (not delegated; we’ll test by querying OCI authoritative nameservers directly) – Steering policy attachment for www.lab.example: – Return web-a when healthy – Fail over to web-b when web-a is unhealthy

Estimated time: 60–120 minutes
Risk level: Low (uses small instances; you can fully clean up)

If you own a real domain, you can optionally delegate a subdomain to OCI DNS and test with normal resolvers. This lab does not require domain ownership.

Step 1: Create a compartment for the lab

In the OCI Console, go to Identity & Security → Compartments.
Click Create Compartment.
Name: DNS-Lab
Create.

Expected outcome: A compartment to isolate all lab resources.

Step 2: Create IAM group and policies (if you don’t already have access)

If you already have sufficient privileges, you can skip.

Go to Identity & Security → Groups → Create Group – Name: DNS-Lab-Admins
Add your user to the group.
Go to Identity & Security → Policies → Create Policy in the root compartment (or appropriate parent).
Add policy statements (edit group/compartment names as needed):

Allow group DNS-Lab-Admins to manage dns in compartment DNS-Lab
Allow group DNS-Lab-Admins to manage health-checks in compartment DNS-Lab
Allow group DNS-Lab-Admins to manage virtual-network-family in compartment DNS-Lab
Allow group DNS-Lab-Admins to manage instance-family in compartment DNS-Lab

Expected outcome: You can create DNS zones/policies, health checks, VCNs, and instances within DNS-Lab.

Verification: Try opening the DNS service page and ensure you don’t see “Not authorized”.

Step 3: Create a VCN with internet connectivity

Go to Networking → Virtual Cloud Networks.
Choose compartment DNS-Lab.
Click Start VCN Wizard.
Select VCN with Internet Connectivity.
Create with defaults (or set): – VCN name: dns-lab-vcn – Public subnet: dns-lab-public-subnet

Expected outcome: A VCN with: – Internet Gateway – Route table allowing 0.0.0.0/0 to IGW – Public subnet

Step 4: Create two compute instances (web-a and web-b)

We’ll use small Linux instances and install Nginx.

Go to Compute → Instances → Create Instance
Compartment: DNS-Lab
Name: web-a
Image: Oracle Linux (or another supported Linux)
Shape: pick an Always Free eligible shape if available (verify availability)
Networking: select dns-lab-vcn and dns-lab-public-subnet
Assign a public IPv4 address
Add your SSH public key
Create.

Repeat for web-b.

Expected outcome: Two running instances, each with a public IP.

Verification: In each instance details page, copy the Public IPv4 address.

Step 5: Open inbound port 80 to the instances

To allow HTTP and health checks, permit inbound TCP/80. Depending on how your subnet is configured, you’ll update either: – Security List rules (subnet-level), or – Network Security Group (NSG) rules (instance-level)

For a basic wizard VCN using security lists: 1. Go to Networking → Virtual Cloud Networks → dns-lab-vcn 2. Security Lists → open the one attached to your public subnet 3. Add Ingress Rules – Source CIDR: 0.0.0.0/0 (lab only; production should be tighter) – IP Protocol: TCP – Destination Port Range: 80

Expected outcome: Instances accept inbound HTTP from the internet.

Verification: From your laptop:

curl -I http://<WEB_A_PUBLIC_IP>/
curl -I http://<WEB_B_PUBLIC_IP>/

You may get a connection error until Nginx is installed (next step), but the TCP path should be open.

Step 6: Install and configure Nginx on both instances

SSH to each instance and install a web server.

For web-a:

ssh opc@<WEB_A_PUBLIC_IP>
sudo dnf -y install nginx
echo "Hello from web-a" | sudo tee /usr/share/nginx/html/index.html
sudo systemctl enable --now nginx

For web-b:

ssh opc@<WEB_B_PUBLIC_IP>
sudo dnf -y install nginx
echo "Hello from web-b" | sudo tee /usr/share/nginx/html/index.html
sudo systemctl enable --now nginx

Expected outcome: Both endpoints return unique content.

Verification:

curl http://<WEB_A_PUBLIC_IP>/
curl http://<WEB_B_PUBLIC_IP>/

You should see: – Hello from web-a – Hello from web-b

Step 7: Create OCI Health Checks for both endpoints

Go to Networking → Health Checks (service name may appear under Networking).
Compartment: DNS-Lab
Create Health Check – Name: hc-web-a – Targets: <WEB_A_PUBLIC_IP> – Protocol: HTTP – Port: 80 – Path: / – Interval/timeout: choose defaults or a reasonable low interval for the lab
Create.

Repeat for hc-web-b targeting <WEB_B_PUBLIC_IP>.

Expected outcome: Two health checks showing status for each endpoint.

Verification: – Wait for the checks to run. – Status should become Healthy.

If health checks remain unhealthy, verify your security rules allow inbound TCP/80 and the instance is running Nginx.

Step 8: Create a public DNS zone (not delegated)

Go to Networking → DNS Management (or DNS in OCI Console).
Compartment: DNS-Lab
Create Zone – Zone type: Public – Zone name: lab.example (you can use any domain-like name for testing)
Create.

Expected outcome: Zone exists and OCI provides authoritative nameservers for it.

Verification: – In the zone details, note the nameserver hostnames. – You will query these nameservers directly with dig.

Step 9: Create a steering policy (Failover) in Traffic Management

In DNS, find Traffic Management (or steering policies).
Create Steering Policy – Name: sp-failover-www – Template/Policy type: choose Failover (if templates are offered) – Add answers/endpoints:
- Primary answer: <WEB_A_PUBLIC_IP> (A record)
- Secondary answer: <WEB_B_PUBLIC_IP> (A record)
- Attach health checks:
- Primary uses hc-web-a
- Secondary uses hc-web-b
- Set TTL appropriate for lab (lower TTL makes testing faster, but caching still applies)

If OCI uses rule-based steering instead of a “failover template,” implement failover using: – A HEALTH rule referencing monitors, combined with – A PRIORITY rule choosing primary then secondary
(Exact UI terms can vary—follow the current console workflow and verify in official docs.)

Expected outcome: A steering policy exists that will prefer web-a when healthy, otherwise answer web-b.

Step 10: Attach the steering policy to `www.lab.example`

Create a Steering Policy Attachment – Zone: lab.example – Domain name: www.lab.example – Steering policy: sp-failover-www

Expected outcome: DNS queries for www.lab.example are answered by the steering policy rather than a static A record.

Step 11: Validate DNS answers using the OCI authoritative nameserver

Because we didn’t delegate the domain, query OCI nameservers directly.

Pick one authoritative nameserver from the zone details, such as: – ns1.p##.dns.oraclecloud.net (example format; use your actual value)
Query it:

dig @<AUTHORITATIVE_NS_HOSTNAME> www.lab.example A +short

Expected outcome: You see <WEB_A_PUBLIC_IP> (primary) while healthy.

Also validate HTTP content:

curl http://$(dig @<AUTHORITATIVE_NS_HOSTNAME> www.lab.example A +short)/

You should see Hello from web-a.

Step 12: Trigger failover and confirm Traffic Management behavior

Simulate failure on web-a by stopping Nginx:

ssh opc@<WEB_A_PUBLIC_IP>
sudo systemctl stop nginx

Wait long enough for the health check to detect failure (depends on interval and failure threshold).

Now query DNS again:

dig @<AUTHORITATIVE_NS_HOSTNAME> www.lab.example A +short

Expected outcome: After health transitions, the answer becomes <WEB_B_PUBLIC_IP>.

Confirm content:

curl http://$(dig @<AUTHORITATIVE_NS_HOSTNAME> www.lab.example A +short)/

You should see Hello from web-b.

Note about caching: Since you query the authoritative server directly using @nameserver, caching is minimized. If you test through normal resolvers, TTL and resolver caching can delay visible changes.

Validation

Use this checklist: – [ ] web-a and web-b respond on http://<public-ip>/ – [ ] Health checks show healthy when Nginx is running – [ ] dig @<authoritative-ns> www.lab.example A +short returns web-a when healthy – [ ] When web-a is unhealthy, the DNS answer shifts to web-b – [ ] Restoring web-a returns traffic to primary (depending on policy logic and health state)

To restore web-a:

ssh opc@<WEB_A_PUBLIC_IP>
sudo systemctl start nginx

Troubleshooting

Problem: Health checks stay unhealthy – Confirm port 80 is allowed in Security List/NSG. – Confirm Nginx is running: sudo systemctl status nginx – Confirm the instance has a public IP and route to IGW. – Check if your organization IP reputation or firewall blocks probe sources. – Verify Health Checks documentation for current probe IP ranges and allowlist guidance.

Problem: dig returns no answer – Ensure you are querying the correct authoritative nameserver hostname from zone details. – Confirm the steering policy attachment is for the exact name (www.lab.example). – Confirm record type (A) matches the attachment/policy behavior.

Problem: Failover doesn’t happen – Health checks might still be considered healthy due to thresholds. – Wait longer, or reduce health check interval/failure threshold (lab only). – Ensure the steering policy is actually using the health checks (not created but not referenced).

Problem: You see both IPs or unexpected ordering – Your policy might be load-balancing rather than failover. – Re-check the steering template/type and rules.

Cleanup

To avoid ongoing charges: 1. Delete steering policy attachment. 2. Delete steering policy. 3. Delete health checks. 4. Delete the DNS zone (only if not used elsewhere). 5. Terminate compute instances web-a and web-b. 6. Delete the VCN dns-lab-vcn (will remove subnets, IGW, etc., if not in use).

Delete in this order to avoid dependency errors.

11. Best Practices

Architecture best practices

Route users to stable front doors (Load Balancers, API Gateways, CDN/WAF endpoints) rather than directly to ephemeral instance IPs.
Use Traffic Management for:
Cross-region routing decisions
Failover and coarse traffic shifting
Use load balancers/ingress for fine-grained L7 routing.
Design with DNS caching in mind:
Keep TTLs higher for normal operation
Lower TTLs temporarily during migrations (and raise them back)

IAM/security best practices

Separate duties:
Zone administration vs record changes vs traffic policies
Use compartments:
prod-dns, nonprod-dns, shared-services
Apply least privilege:
Only CI/CD or a limited group can change production DNS
Require MFA and strong identity hygiene for privileged users

Cost best practices

Avoid “policy sprawl”: too many attachments and health checks can add cost and complexity.
Use health check frequency appropriate to your RTO (don’t probe every few seconds unless necessary).
Monitor and forecast costs for Load Balancers and egress, which usually dominate.

Performance best practices

Use geo steering (when appropriate and supported) to reduce latency.
Use multiple endpoints per region and multi-A answers where it makes sense.
Keep DNS responses small (avoid excessive record bloat).

Reliability best practices

Test failover regularly (game days).
Ensure secondary endpoints are truly independent (different region, separate dependencies).
Don’t rely on DNS alone for resilience:
Combine with multi-region data replication and application-level resilience.

Operations best practices

Track DNS changes with:
Ticketing/approvals (where required)
CI/CD pipelines and versioned DNS configurations
Maintain runbooks:
“Failover to DR region”
“Rollback to primary”
Document TTL strategy and expected propagation delays.

Governance/tagging/naming best practices

Naming conventions:
zone-prod-example-com
sp-failover-www-prod
hc-us-ashburn-lb-https
Tag resources with:
Environment=Prod
Owner=Platform
CostCenter=...
Define standard policy templates:
Failover, weighted rollout, geo steering patterns

12. Security Considerations

Identity and access model

OCI IAM controls DNS and Traffic Management resources:
Zones, records, steering policies, attachments
Use separate groups for:
Read-only DNS viewers
DNS editors
DNS admins

Encryption

Management plane traffic uses HTTPS to OCI APIs.
DNS query plane is standard DNS (UDP/TCP 53) without inherent encryption.
If your requirement is encrypted DNS transport (DoH/DoT), verify OCI DNS capabilities and consider an alternate approach if required.

Network exposure

Public zones expose names publicly once delegated.
Private DNS avoids internet exposure but must be carefully designed to prevent unintended access across networks.

Secrets handling

DNS itself doesn’t typically store secrets, but TXT records are sometimes misused for sensitive data.
Avoid putting secrets in TXT records.
Use OCI Vault or another secrets manager instead.

Audit/logging

Use OCI Audit to track who changed DNS and steering policies.
For query-level visibility, you may need external DNS analytics or upstream resolver logs (verify what OCI natively provides today; do not assume query logs exist).

Compliance considerations

DNSSEC may be required in some industries.
Change management and least privilege are common audit requirements.
Document delegation, key management (for DNSSEC), and failover testing evidence.

Common security mistakes

Allowing too many users to modify production zones
Using very low TTLs permanently (can increase query load and operational sensitivity)
Forgetting to restrict health check probe traffic rules (or accidentally blocking it)
Storing sensitive verification tokens longer than needed

Secure deployment recommendations

Enable DNSSEC where required and validated end-to-end (registrar → OCI → resolvers).
Use separate compartments and policies for prod/non-prod.
Use automation pipelines with approvals for production record changes.
Keep a well-defined break-glass procedure for incidents.

13. Limitations and Gotchas

DNS caching is unavoidable

Even with a low TTL, recursive resolvers and clients may not honor it perfectly.
Failover won’t be instantaneous for all users.

Health check realism

A health check can only test what you configure (HTTP status, TCP connect, etc.).
Your app can be “healthy” by check but still broken for users (dependency failures, auth issues).

Apex record constraints

Standard DNS does not allow CNAME at the zone apex.
If you need “apex to LB” style behavior, verify OCI’s ALIAS-like support and its exact semantics.

Multi-region dependencies

DNS failover is pointless if both regions depend on the same:
Identity provider
Database
Third-party API
Network path

Quotas/service limits

Limits exist for zones, records, policies, attachments, and health checks.
Check Service Limits and plan capacity before large migrations.

Operational propagation

Changes may take time to apply across authoritative infrastructure.
Coordinate changes with TTL reduction windows.

Vendor-specific nuances

Traffic Management rules and health check integration are OCI-specific.
If you later migrate DNS providers, you must map policies to the new provider’s model (not always 1:1).

14. Comparison with Alternatives

Nearest services in Oracle Cloud

OCI Load Balancing: best for L4/L7 traffic distribution within a region; can be multi-region only with external mechanisms (DNS/clients).
OCI WAF / CDN (if used): protects and accelerates HTTP(S) at the edge; still typically uses DNS to direct users to the edge endpoint.

Nearest services in other clouds

AWS Route 53 (DNS + routing policies + health checks)
Azure DNS + Azure Traffic Manager (DNS + DNS-based traffic steering)
Google Cloud DNS plus other traffic products (DNS is separate from traffic steering; global load balancing can play a similar role depending on design)

Open-source / self-managed alternatives

BIND / Knot / PowerDNS authoritative DNS (you run it)
Health checking + dynamic updates via custom automation

Comparison table

Option	Best For	Strengths	Weaknesses	When to Choose
OCI DNS and Traffic Management	OCI-centric DNS governance + DNS-based steering	Integrated IAM/compartments, steering policies, OCI-native patterns	DNS caching limits; policy model differs from other vendors	You run workloads in OCI and want OCI-governed DNS + traffic steering
OCI Load Balancing	In-region traffic distribution	L7 routing, TLS termination, backend health, sticky sessions	Not a global routing solution by itself	You need application-layer routing within a region/VCN
AWS Route 53	AWS-heavy or multi-cloud DNS	Mature routing policies, deep ecosystem integration	Different IAM/governance model; data residency considerations	Your core platform is AWS or you standardize on Route 53
Azure Traffic Manager + Azure DNS	Azure-heavy architectures	Simple DNS-based traffic steering	DNS-only steering (same caching limits)	Your workloads are primarily in Azure
Cloudflare DNS + steering	Internet edge performance + security	Strong edge network, advanced features	Different governance/vendor dependency	You want a third-party edge-first DNS/security platform
Self-managed BIND/PowerDNS	Full control, niche requirements	Customization, on-prem integration	You manage uptime, scaling, patching, DDoS considerations	You have strict sovereignty/air-gapped needs or legacy constraints

15. Real-World Example

Enterprise example: Multi-region customer portal with DR failover

Problem: A financial services portal must survive regional outages and meet recovery objectives. The organization requires strict IAM controls and auditable DNS changes.
Proposed architecture:
www.bank.com uses OCI DNS zone
Traffic Management steering policy implements priority failover:
- Primary: OCI WAF → OCI Load Balancer in Region A
- Secondary: OCI WAF → OCI Load Balancer in Region B
OCI Health Checks monitor /healthz over HTTPS
DNSSEC enabled for the zone (subject to registrar support)
Compartments: prod-network, prod-dns, prod-security
Why this service was chosen:
Tight integration with OCI IAM and compartment governance
Built-in steering policies and attachments
Straightforward health-check-based failover
Expected outcomes:
Reduced manual intervention during incidents
Auditable DNS change history
Predictable DR entry procedure and periodic failover testing

Startup/small-team example: SaaS migration from single VM to OCI with safe rollout

Problem: A startup runs a single VM on another provider and wants to migrate to OCI with minimal risk and an easy rollback.
Proposed architecture:
Stand up new OCI Load Balancer + app instances
Use Traffic Management weighted steering:
- 90% old endpoint
- 10% new OCI endpoint
Gradually increase OCI weight while monitoring errors and latency
Why this service was chosen:
Enables gradual cutover without complex proxying
Minimizes downtime risk
Expected outcomes:
Controlled migration with rapid rollback (set weight back)
Clear operational playbook for future releases

16. FAQ

1) Is DNS and Traffic Management a single OCI service?
In OCI, DNS is the core service, and Traffic Management is delivered through steering policies and attachments that work with DNS. Oracle documentation often presents them together.

2) Is OCI DNS authoritative?
Yes—public DNS zones hosted in OCI act as authoritative DNS for delegated domains.

3) Do I need to own a domain to practice?
No. You can create a public zone and query OCI authoritative nameservers directly using dig @nameserver. For real production resolution, you must delegate the domain at your registrar.

4) What is a steering policy attachment?
It binds a steering policy to a specific DNS name (like www.example.com) within a zone.

5) How does DNS-based failover differ from load balancer failover?
DNS failover changes which endpoint name resolves to. Load balancer failover (within a region) typically changes backend selection without changing DNS answers. DNS failover is subject to caching and TTL delays.

6) Can I route traffic based on geography?
OCI Traffic Management supports geographic-style steering via policy rules (verify the exact rule types and behaviors in current docs).

7) Can steering policies use health checks?
Yes. OCI steering policies can integrate with OCI Health Checks so unhealthy endpoints are not returned.

8) Does Traffic Management replace a CDN or WAF?
No. It decides DNS answers. CDN/WAF provide caching/protection/edge delivery for HTTP(S).

9) Should I point DNS directly at compute instance IPs?
For labs, it’s fine. In production, it’s usually better to point at stable front doors like OCI Load Balancers, because instance IPs can change and instances are not ideal as internet entry points.

10) How quickly does failover happen?
It depends on health check intervals and thresholds, plus DNS TTL and resolver caching. Some clients may continue using cached answers until TTL expiry.

11) Can I use very low TTL (like 5 seconds) to get instant failover?
Very low TTLs can increase query load and still won’t guarantee instant change due to resolver behavior. Use low TTLs strategically and test with real resolvers.

12) Does OCI DNS support DNSSEC?
OCI DNS includes DNSSEC capabilities for zones (verify current support and required steps, including registrar DS record management).

13) How do I manage DNS changes safely in teams?
Use compartments, least-privilege IAM, automation with code review, and OCI Audit tracking. Consider a formal DNS change process for production.

14) Can I integrate OCI DNS with Terraform?
Commonly yes via the OCI Terraform provider, but verify current resource support for zones, records, and steering policies/attachments in the provider documentation.

15) What’s the biggest operational gotcha?
Assuming DNS failover is immediate. Always design and test with DNS caching realities and have runbooks for incident scenarios.

16) Can I fail over between OCI and on-prem endpoints?
Yes, DNS can return any reachable endpoints. Ensure health checks can probe on-prem endpoints (firewall rules, allowlists, and routing must permit it).

17) Do I get query logs for DNS?
OCI provides strong control-plane auditing (who changed what). Query logging availability and format should be confirmed in official docs for your region and service version—do not assume per-query logs exist.

17. Top Online Resources to Learn DNS and Traffic Management

Resource Type	Name	Why It Is Useful
Official Documentation	OCI DNS Documentation – https://docs.oracle.com/en-us/iaas/Content/DNS/home.htm	Core concepts, zones, records, DNSSEC, and operational guidance
Official Documentation	OCI Traffic Management Documentation – https://docs.oracle.com/en-us/iaas/Content/TrafficManagement/home.htm	Steering policies, rule types, attachments, and examples (verify URL if Oracle reorganizes docs)
Official Documentation	OCI Health Checks Documentation – https://docs.oracle.com/en-us/iaas/Content/HealthChecks/home.htm	Health check configuration, probe behavior, and troubleshooting
Official CLI Reference	OCI CLI DNS Commands – https://docs.oracle.com/en-us/iaas/tools/oci-cli/latest/oci_cli_docs/cmdref/dns.html	Automate DNS zones/records and learn object models
Official CLI Reference	OCI CLI Health Checks Commands – https://docs.oracle.com/en-us/iaas/tools/oci-cli/latest/oci_cli_docs/cmdref/health-checks.html	Automate monitors used in Traffic Management
Official Pricing	Oracle Cloud Pricing – https://www.oracle.com/cloud/pricing/	High-level pricing model and service entry points
Official Pricing	Oracle Cloud Price List – https://www.oracle.com/cloud/price-list/	SKU-level detail (search for DNS, Health Checks, Load Balancer)
Official Cost Tool	OCI Cost Estimator – https://www.oracle.com/cloud/costestimator.html	Build estimates for multi-region and LB-heavy designs
Official Labs	Oracle LiveLabs Catalog – https://apexapps.oracle.com/pls/apex/r/dbpm/livelabs/home	Hands-on labs; search for DNS/Traffic Management/Networking
Architecture Guidance	OCI Architecture Center – https://docs.oracle.com/solutions/	Reference architectures; search for DNS, multi-region, DR patterns
Community Learning (Reputable)	OCI GitHub – https://github.com/oracle/oci	Samples and tools; verify DNS-related examples by repo and date

18. Training and Certification Providers

Institute	Suitable Audience	Likely Learning Focus	Mode	Website URL
DevOpsSchool.com	DevOps engineers, SREs, architects, beginners	OCI fundamentals, DevOps practices, cloud networking basics	Check website	https://www.devopsschool.com/
ScmGalaxy.com	Students, engineers learning tooling	SCM/DevOps foundations; may include cloud modules	Check website	https://www.scmgalaxy.com/
CLoudOpsNow.in	Cloud ops and platform teams	Operations, monitoring, reliability practices	Check website	https://www.cloudopsnow.in/
SreSchool.com	SREs, platform engineers	Reliability engineering, incident response, operations	Check website	https://www.sreschool.com/
AiOpsSchool.com	Ops + automation practitioners	AIOps concepts, automation, observability	Check website	https://www.aiopsschool.com/

19. Top Trainers

Platform/Site	Likely Specialization	Suitable Audience	Website URL
RajeshKumar.xyz	DevOps/cloud training content (verify specific OCI coverage)	Beginners to intermediate engineers	https://rajeshkumar.xyz/
devopstrainer.in	DevOps training and mentoring (verify course catalog)	Engineers seeking guided learning	https://www.devopstrainer.in/
devopsfreelancer.com	Freelance DevOps help/training (treat as a platform unless verified)	Teams needing short-term expert assistance	https://www.devopsfreelancer.com/
devopssupport.in	DevOps support/training services (verify offerings)	Ops teams and DevOps practitioners	https://www.devopssupport.in/

20. Top Consulting Companies

Company Name	Likely Service Area	Where They May Help	Consulting Use Case Examples	Website URL
cotocus.com	Cloud/DevOps consulting (verify OCI specialization)	Architecture, automation, operations improvements	DNS governance design, migration runbooks, IaC enablement	https://cotocus.com/
DevOpsSchool.com	DevOps enablement and training/consulting	Platform engineering practices, CI/CD, cloud ops	DNS automation pipeline, production change management, DR testing process	https://www.devopsschool.com/
DEVOPSCONSULTING.IN	DevOps consulting services (verify portfolio)	DevOps transformation, tooling, operations	Multi-region readiness assessment, monitoring + runbooks, Terraform adoption	https://www.devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before this service

DNS fundamentals:
Authoritative vs recursive DNS
NS delegation, SOA, TTL, record types
OCI fundamentals:
Tenancy, compartments, IAM policies
VCN basics: subnets, IGW, route tables, security lists/NSGs
Basic Linux and networking:
dig, curl, ssh, firewall basics

What to learn after this service

OCI Load Balancing (L7 routing, TLS termination, backends)
Multi-region design patterns in OCI:
Data replication, DR drills, RTO/RPO planning
Security services:
OCI WAF, OCI Vault, Cloud Guard (as applicable)
Observability:
OCI Monitoring/Logging, distributed tracing (service-dependent)
Infrastructure as Code:
Terraform for OCI DNS, health checks, and networking

Job roles that use it

Cloud Engineer / Cloud Administrator
Network Engineer (cloud)
DevOps Engineer
Site Reliability Engineer (SRE)
Solutions Architect / Cloud Architect
Security Engineer (DNS governance, DNSSEC, change control)

Certification path (if available)

Oracle updates certification tracks over time. Start by checking Oracle University certification paths relevant to: – OCI Foundations – OCI Architect – OCI Networking (if offered)

Verify current certification names and exam codes at: https://education.oracle.com/

Project ideas for practice

Build a multi-region “hello world” with DNS failover (this lab, extended to two regions)
Implement weighted rollouts for an API version upgrade
Create a private DNS zone for internal services in a VCN (verify Private DNS constructs)
Automate DNS changes with Terraform and a CI/CD pipeline including approvals
Implement DNSSEC on a test domain and validate with common DNSSEC tools

22. Glossary

Authoritative DNS: DNS servers that provide official answers for a domain’s zone data.
Recursive resolver: A DNS server that queries other DNS servers on behalf of a client and caches results.
DNS zone: Administrative boundary containing DNS records for a domain (e.g., example.com).
Record (RR): A DNS entry (A, AAAA, CNAME, TXT, MX, etc.).
RRSet: A set of records with the same name and type (e.g., multiple A records for www).
TTL (Time to Live): Cache duration for a DNS answer.
DNSSEC: Security extensions that sign DNS data to allow validation by resolvers.
Traffic Management steering policy: OCI policy defining how DNS answers are selected (failover, weighted, geo, etc.).
Steering policy attachment: Object that applies a steering policy to a specific DNS name in a zone.
Health check: Active probe to determine if an endpoint is reachable/healthy.
Endpoint: The destination returned by DNS (IP address, or sometimes hostname depending on record type).
Compartment (OCI): A logical container for resources in OCI, used for access control and organization.
IAM policy (OCI): Authorization rules controlling access to OCI resources.
VCN (Virtual Cloud Network): OCI’s virtual network construct.

23. Summary

DNS and Traffic Management in Oracle Cloud (within Networking, Edge, and Connectivity) combines managed authoritative DNS with policy-driven routing through Traffic Management steering policies. It helps you publish reliable DNS records, implement health-aware failover, and steer users across endpoints or regions for resilience and performance.

Key takeaways: – DNS gives you naming; Traffic Management helps decide which endpoint DNS should return. – Costs are usually driven more by load balancers, compute, and egress than by DNS itself, but verify DNS/health-check pricing in Oracle’s official price list. – Security and governance depend on strong OCI IAM, compartment design, auditability, and careful DNSSEC implementation where required. – Use it when you need multi-endpoint or multi-region routing, failover, and controlled rollouts—while accepting DNS caching realities.

Next step: read the official OCI DNS and Traffic Management docs, then extend the lab to two OCI regions with real delegation of a subdomain and a production-grade front door (OCI Load Balancer + TLS).

rajeshkumar

Category