{"id":943,"date":"2026-04-17T05:31:14","date_gmt":"2026-04-17T05:31:14","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/oracle-cloud-dns-and-traffic-management-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-networking-edge-and-connectivity\/"},"modified":"2026-04-17T05:31:14","modified_gmt":"2026-04-17T05:31:14","slug":"oracle-cloud-dns-and-traffic-management-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-networking-edge-and-connectivity","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/oracle-cloud-dns-and-traffic-management-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-networking-edge-and-connectivity\/","title":{"rendered":"Oracle Cloud DNS and Traffic Management Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Networking, Edge, and Connectivity"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Networking, Edge, and Connectivity<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<p>Oracle Cloud Infrastructure (OCI) <strong>DNS and Traffic Management<\/strong> 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.<\/p>\n\n\n\n<p>In simple terms: <strong>DNS<\/strong> makes your application reachable by name (like <code>www.example.com<\/code>), and <strong>Traffic Management<\/strong> helps decide <em>which<\/em> IP address (or endpoint) DNS should return to each client\u2014based on health, geography, weights, or other rules.<\/p>\n\n\n\n<p>Technically, OCI DNS provides <strong>public and private managed DNS zones<\/strong>, record management APIs, and <strong>DNSSEC<\/strong> (where applicable). OCI Traffic Management is implemented through <strong>Traffic Management steering policies<\/strong> and <strong>steering policy attachments<\/strong> that dynamically answer DNS queries according to defined rules\u2014often integrating with <strong>OCI Health Checks<\/strong> for failover and high availability.<\/p>\n\n\n\n<p>This service solves problems like:\n&#8211; Replacing manual DNS changes during outages with <strong>automatic DNS-based failover<\/strong>\n&#8211; Sending users to the <strong>closest<\/strong> or <strong>best-performing<\/strong> endpoint\n&#8211; Implementing <strong>blue\/green<\/strong> or <strong>canary<\/strong> rollouts via weighted DNS\n&#8211; Centralizing DNS governance in Oracle Cloud with <strong>IAM-controlled<\/strong> changes and auditability<\/p>\n\n\n\n<blockquote>\n<p>Naming note (scope clarification): In OCI, <strong>DNS<\/strong> is the primary service name in the console and documentation, and <strong>Traffic Management<\/strong> is a closely related capability delivered through <strong>Traffic Management steering policies<\/strong>. Oracle documentation often presents them together. This tutorial uses <strong>\u201cDNS and Traffic Management\u201d<\/strong> as the umbrella term, exactly as provided.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is DNS and Traffic Management?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Official purpose<\/h3>\n\n\n\n<p><strong>DNS and Traffic Management<\/strong> in Oracle Cloud provides:\n&#8211; <strong>Authoritative DNS hosting<\/strong> (public DNS zones) to publish records on the internet\n&#8211; <strong>Private DNS<\/strong> (private zones\/views associated with VCNs) for internal name resolution\n&#8211; <strong>Traffic steering<\/strong> (Traffic Management steering policies) to control DNS answers dynamically for routing and resilience<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Core capabilities<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Create and manage DNS zones (public and private, depending on your needs)<\/li>\n<li>Create and update DNS records (A\/AAAA\/CNAME\/TXT\/MX and other supported types\u2014verify supported record types in official docs for your use case)<\/li>\n<li>Apply <strong>Traffic Management steering policies<\/strong> (failover, load distribution, geo steering, and more)<\/li>\n<li>Integrate with <strong>Health Checks<\/strong> to avoid returning unhealthy endpoints<\/li>\n<li>Sign zones with <strong>DNSSEC<\/strong> (where supported) to protect DNS integrity<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Major components (OCI terminology)<\/h3>\n\n\n\n<p>Common OCI objects you will see:\n&#8211; <strong>Zone<\/strong>: A DNS zone you manage (public or private)\n&#8211; <strong>Record \/ RRSet<\/strong>: Resource records for names in the zone\n&#8211; <strong>Steering policy<\/strong>: A Traffic Management policy defining how DNS answers are selected\n&#8211; <strong>Steering policy attachment<\/strong>: Binds a steering policy to a specific DNS name (like <code>www.example.com<\/code>) and a zone\n&#8211; <strong>Health check<\/strong> (separate OCI service): Actively probes endpoints and supplies health signals to steering policies\n&#8211; <strong>Views \/ Private DNS constructs<\/strong>: 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)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Service type<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Managed cloud networking service<\/strong> (authoritative DNS + policy-driven DNS answering)<\/li>\n<li>Control plane accessed via OCI Console, OCI CLI, SDKs, and REST APIs<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scope: regional\/global and tenancy boundaries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>DNS is generally treated as a <strong>global<\/strong> service in OCI from an authoritative DNS standpoint, even though you select regions in the Console experience for administration.<\/li>\n<li>DNS resources are <strong>tenancy-scoped<\/strong> and organized with <strong>compartments<\/strong> for access control and governance.<\/li>\n<li><strong>Traffic Management steering policies<\/strong> are managed within OCI and attached to names in zones.<\/li>\n<\/ul>\n\n\n\n<blockquote>\n<p>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.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">How it fits into the Oracle Cloud ecosystem<\/h3>\n\n\n\n<p>DNS and Traffic Management sits at the front door of OCI deployments within <strong>Networking, Edge, and Connectivity<\/strong>:\n&#8211; Points users to <strong>OCI Load Balancers<\/strong>, <strong>Compute instances<\/strong>, <strong>API Gateways<\/strong>, or <strong>external endpoints<\/strong>\n&#8211; Works alongside <strong>OCI WAF<\/strong> (application protection), <strong>OCI CDN<\/strong> (content caching, if used), and <strong>Load Balancing<\/strong> (L4\/L7 routing)\n&#8211; Uses <strong>OCI IAM<\/strong> for fine-grained change control, and <strong>Audit<\/strong> for API-call tracking\n&#8211; Integrates strongly with <strong>OCI Health Checks<\/strong> for resilient routing decisions<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use DNS and Traffic Management?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Business reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Reduce downtime impact<\/strong>: automatic DNS failover can keep customer-facing services reachable during incidents.<\/li>\n<li><strong>Improve global experience<\/strong>: steer users to regionally appropriate endpoints, improving latency and satisfaction.<\/li>\n<li><strong>Simplify operations<\/strong>: centralize DNS ownership and change process within OCI.<\/li>\n<li><strong>Support migrations<\/strong>: gradually move traffic from on-prem or another cloud into OCI using weighted steering.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Technical reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Authoritative DNS hosting<\/strong> with API-driven management<\/li>\n<li><strong>Policy-based DNS responses<\/strong> (Traffic Management steering policies)<\/li>\n<li><strong>Health-aware routing<\/strong> (avoid dead IPs)<\/li>\n<li><strong>DNSSEC support<\/strong> to reduce DNS spoofing risks (where applicable)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Compartment-based governance<\/strong>: separate dev\/test\/prod and enforce least privilege<\/li>\n<li><strong>Automation<\/strong>: manage zones\/records\/policies via Terraform (commonly used), CLI, or SDKs (verify latest provider support and resource names)<\/li>\n<li><strong>Auditability<\/strong>: track who changed DNS and when via OCI Audit<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/compliance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>IAM enforcement<\/strong>: only approved groups can modify zones\/records\/policies<\/li>\n<li><strong>DNSSEC<\/strong>: strengthen integrity of DNS answers (subject to your registrar and DNSSEC chain of trust)<\/li>\n<li><strong>Change control<\/strong>: implement tagging, approvals, and automation pipelines<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scalability\/performance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>DNS is inherently a scale component\u2014OCI runs authoritative DNS infrastructure so you don\u2019t have to build and maintain it.<\/li>\n<li>Traffic Management policies let you scale across <strong>multiple endpoints\/regions<\/strong> without forcing all traffic through a single load balancer.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose it<\/h3>\n\n\n\n<p>Choose OCI DNS and Traffic Management when you need:\n&#8211; Managed DNS for public zones used by applications\n&#8211; DNS-based global routing and\/or failover\n&#8211; A clean way to run multi-region or hybrid routing strategies\n&#8211; OCI-governed DNS changes integrated with your IAM model<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should not choose it<\/h3>\n\n\n\n<p>Consider alternatives when:\n&#8211; You need <strong>application-layer routing<\/strong> decisions (headers, paths, cookies). DNS can\u2019t see those; use <strong>OCI Load Balancing<\/strong> or an ingress\/API gateway layer.\n&#8211; You require <strong>instant<\/strong> traffic shifting with no caching effects. DNS is cached; even low TTLs are not perfect.\n&#8211; You need <strong>DoH\/DoT endpoint services<\/strong> from your authoritative provider (verify OCI capabilities; do not assume).\n&#8211; You want a \u201csingle pane of glass\u201d DNS provider across many clouds and registrars with advanced vendor-specific features (some organizations use Cloudflare\/NS1, etc.).<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is DNS and Traffic Management used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>SaaS and internet applications (public endpoints)<\/li>\n<li>Financial services (careful change control, DNSSEC, high availability)<\/li>\n<li>E-commerce (multi-region resilience)<\/li>\n<li>Media and gaming (traffic steering, rollout control)<\/li>\n<li>Enterprise internal platforms (private DNS for internal services)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Team types<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Platform engineering and SRE teams managing shared DNS platforms<\/li>\n<li>Network engineers managing authoritative zones and delegations<\/li>\n<li>DevOps engineers automating record changes and cutovers<\/li>\n<li>Security teams enforcing DNSSEC and least privilege<\/li>\n<li>Application teams needing controlled rollouts (canary\/blue-green)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Workloads<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Public web applications and APIs<\/li>\n<li>Multi-region active-active or active-passive designs<\/li>\n<li>Hybrid (on-prem + OCI) with staged migrations<\/li>\n<li>Kubernetes ingress endpoints (DNS to LB frontends)<\/li>\n<li>Disaster recovery designs using DNS failover to a standby region<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Architectures<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Single region + DR region (DNS failover)<\/li>\n<li>Global multi-region with geolocation steering<\/li>\n<li>Weighted rollouts during migration or version releases<\/li>\n<li>Split-horizon internal DNS (private zones) for service discovery patterns<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Real-world deployment contexts<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Production: delegated zones at registrar, DNSSEC enabled (when required), change approvals, health checks, and tested failover runbooks<\/li>\n<li>Dev\/test: non-delegated zones queried directly by authoritative nameserver (useful for learning), short TTLs, and isolated compartments<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">5. Top Use Cases and Scenarios<\/h2>\n\n\n\n<p>Below are realistic ways teams use <strong>Oracle Cloud DNS and Traffic Management<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Automatic regional failover for a public API<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Region A outage makes <code>api.company.com<\/code> unreachable.<\/li>\n<li><strong>Why it fits:<\/strong> Steering policy + health checks can stop returning Region A endpoint and return Region B instead.<\/li>\n<li><strong>Example:<\/strong> Primary endpoint is an OCI Load Balancer in <code>us-ashburn-1<\/code>, secondary in <code>us-phoenix-1<\/code>.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Active-active multi-region DNS load distribution<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> One region can\u2019t handle peak load alone.<\/li>\n<li><strong>Why it fits:<\/strong> Weighted answers distribute traffic across endpoints.<\/li>\n<li><strong>Example:<\/strong> Return both regions with weights 60\/40 and adjust during events.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Blue\/green deployment cutover<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Need low-risk release with easy rollback.<\/li>\n<li><strong>Why it fits:<\/strong> Weighted steering gradually increases traffic to \u201cgreen.\u201d<\/li>\n<li><strong>Example:<\/strong> Start 95% old LB, 5% new LB; ramp to 50\/50; then 100% green.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Canary testing with internal users<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Want a small subset of clients to hit a new endpoint.<\/li>\n<li><strong>Why it fits:<\/strong> DNS policies can target by geography\/ASN (capability depends on supported rules\u2014verify).<\/li>\n<li><strong>Example:<\/strong> Route EU traffic to new endpoint first.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Hybrid migration from on-prem to OCI<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Move workloads without a \u201cbig bang\u201d DNS cutover.<\/li>\n<li><strong>Why it fits:<\/strong> Use weighted or priority rules between on-prem VIP and OCI LB.<\/li>\n<li><strong>Example:<\/strong> 80% on-prem, 20% OCI; gradually invert.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Multi-cloud continuity design<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> OCI is primary, but must fail over to another provider.<\/li>\n<li><strong>Why it fits:<\/strong> Steering answers can include non-OCI endpoints as well.<\/li>\n<li><strong>Example:<\/strong> Primary OCI LB, secondary AWS ALB IP\/hostname (depending on DNS record type suitability).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Maintain availability during maintenance windows<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Planned maintenance requires draining a site.<\/li>\n<li><strong>Why it fits:<\/strong> Adjust weights or priority to steer away temporarily.<\/li>\n<li><strong>Example:<\/strong> Move all traffic to Region B for 2 hours.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Improve latency by steering users geographically<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Global users experience high latency to a single region.<\/li>\n<li><strong>Why it fits:<\/strong> Geolocation steering returns region-local answers.<\/li>\n<li><strong>Example:<\/strong> APAC users -&gt; Singapore, EMEA -&gt; Frankfurt, AMER -&gt; Ashburn.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Health-aware endpoint selection for IoT ingest<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Devices post to a DNS name; endpoints occasionally degrade.<\/li>\n<li><strong>Why it fits:<\/strong> Health checks prevent returning unhealthy collectors.<\/li>\n<li><strong>Example:<\/strong> Return only healthy ingest nodes for <code>ingest.example.com<\/code>.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) SaaS tenant isolation by DNS subdomain patterns<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Different tenants must resolve to different frontends.<\/li>\n<li><strong>Why it fits:<\/strong> Separate DNS names and attachments per tenant, managed by compartments\/tags.<\/li>\n<li><strong>Example:<\/strong> <code>tenant-a.app.com<\/code> -&gt; endpoint group A, <code>tenant-b.app.com<\/code> -&gt; endpoint group B.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<p>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.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">6.1 Managed DNS zones (public)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Hosts authoritative DNS zones and answers internet queries for delegated domains.<\/li>\n<li><strong>Why it matters:<\/strong> You don\u2019t manage DNS servers, patching, scaling, or availability.<\/li>\n<li><strong>Practical benefit:<\/strong> Faster domain changes via API\/console; consistent governance via OCI IAM.<\/li>\n<li><strong>Caveats:<\/strong> You must delegate your domain at the registrar for real-world usage; DNS propagation and caching apply.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.2 Private DNS capabilities (private zones \/ split-horizon patterns)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Provides internal-only DNS naming within OCI networking contexts (commonly VCN-associated).<\/li>\n<li><strong>Why it matters:<\/strong> Clean service discovery and internal routing without exposing names publicly.<\/li>\n<li><strong>Practical benefit:<\/strong> Avoid hardcoding IPs; standardize internal naming conventions.<\/li>\n<li><strong>Caveats:<\/strong> Private DNS behavior depends on OCI networking constructs (views\/resolvers). Verify current Private DNS features and constraints in docs before designing.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.3 Record management (RRsets, TTL control, common record types)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Create\/update\/delete DNS records and sets (e.g., A, AAAA, CNAME, TXT, MX, SRV, NS).<\/li>\n<li><strong>Why it matters:<\/strong> DNS is the canonical directory for many systems (web, email, service discovery).<\/li>\n<li><strong>Practical benefit:<\/strong> Use short TTLs for migration windows, longer TTLs for stable records.<\/li>\n<li><strong>Caveats:<\/strong> Apex CNAME is generally not allowed in DNS standards; providers often offer ALIAS\/ANAME-style features\u2014verify OCI support and semantics for your needs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.4 Traffic Management steering policies<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Defines how OCI chooses DNS answers based on a rule set (weights, priority, filters, geo, ASN, health, limits\u2014verify supported rule types in current docs).<\/li>\n<li><strong>Why it matters:<\/strong> Enables resilient and controlled routing without changing application code.<\/li>\n<li><strong>Practical benefit:<\/strong> Implement failover, active-active, regional steering, and rollout strategies.<\/li>\n<li><strong>Caveats:<\/strong> DNS is still DNS\u2014client caching, recursive resolver behavior, and TTLs affect responsiveness.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.5 Steering policy attachments<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Attaches a steering policy to a specific domain name in a zone (for example, apply policy to <code>www.example.com<\/code>).<\/li>\n<li><strong>Why it matters:<\/strong> You can reuse the same policy pattern across names, or apply different policies to different subdomains.<\/li>\n<li><strong>Practical benefit:<\/strong> Clean separation between policy logic and DNS naming.<\/li>\n<li><strong>Caveats:<\/strong> Attachments are part of the DNS answer path for that name; plan lifecycle and ownership carefully.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.6 Integration with OCI Health Checks<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Performs active probing (HTTP\/HTTPS\/TCP\u2014verify options) from OCI vantage points and reports health.<\/li>\n<li><strong>Why it matters:<\/strong> Traffic steering without health can send users to dead endpoints.<\/li>\n<li><strong>Practical benefit:<\/strong> Automated failover and safer load distribution.<\/li>\n<li><strong>Caveats:<\/strong> Health checks are an external signal and can be affected by firewall rules, WAF policies, rate limits, and transient internet routing.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.7 DNSSEC (Domain Name System Security Extensions)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Cryptographically signs DNS responses to help resolvers validate authenticity.<\/li>\n<li><strong>Why it matters:<\/strong> Reduces risk of DNS spoofing\/cache poisoning for validating resolvers.<\/li>\n<li><strong>Practical benefit:<\/strong> Stronger trust in your domain answers.<\/li>\n<li><strong>Caveats:<\/strong> DNSSEC requires careful key and delegation handling with your registrar; misconfiguration can cause resolution failures.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.8 Automation (Console, API, CLI, SDKs, Terraform)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Manage DNS zones\/records\/policies programmatically.<\/li>\n<li><strong>Why it matters:<\/strong> DNS changes are infrastructure changes; they benefit from version control and CI\/CD.<\/li>\n<li><strong>Practical benefit:<\/strong> Repeatable environments, safer migrations, standardized naming.<\/li>\n<li><strong>Caveats:<\/strong> Ensure your automation handles eventual consistency and safe rollbacks.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.9 IAM governance via compartments and policies<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Controls who can create\/modify zones, records, and steering policies.<\/li>\n<li><strong>Why it matters:<\/strong> DNS changes can cause outages or security incidents.<\/li>\n<li><strong>Practical benefit:<\/strong> Least privilege, separation of duties, and auditable operations.<\/li>\n<li><strong>Caveats:<\/strong> Mis-scoped IAM policies can block incident response or allow overly broad access.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">7. Architecture and How It Works<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">High-level architecture<\/h3>\n\n\n\n<p>At a high level:\n1. A client queries a <strong>recursive resolver<\/strong> (ISP, enterprise, or public resolver).\n2. The resolver follows delegation to your <strong>OCI authoritative DNS nameservers<\/strong>.\n3. OCI DNS returns records:\n   &#8211; Standard static records, or\n   &#8211; Dynamic answers computed from a <strong>steering policy<\/strong> (Traffic Management)\n4. Client connects to the returned endpoint (IP\/LB hostname target).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Request\/data\/control flow<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Control plane:<\/strong> You create zones, records, and steering policies through OCI Console\/API\/CLI\/SDK\/Terraform.<\/li>\n<li><strong>Data plane:<\/strong> DNS queries from resolvers to OCI authoritative nameservers; health-check probes from OCI Health Checks to your endpoints.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Key integrations (common patterns)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>OCI Load Balancing:<\/strong> DNS points to public LB. Traffic Management can distribute\/fail over between LBs.<\/li>\n<li><strong>OCI Compute:<\/strong> DNS points directly to instance public IPs (simple labs; less common in production).<\/li>\n<li><strong>OCI Health Checks:<\/strong> Provides endpoint health to steering policies.<\/li>\n<li><strong>OCI IAM + Audit:<\/strong> Access control + change tracking.<\/li>\n<li><strong>OCI WAF \/ CDN (where used):<\/strong> DNS points to WAF\/CDN front door; steering can operate at that level across regions.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Dependencies to plan for<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>A working endpoint<\/strong> (LB or instance) that accepts traffic from health checkers<\/li>\n<li><strong>Network security rules<\/strong> (security lists\/NSGs) allowing health checks and user traffic<\/li>\n<li><strong>A domain strategy<\/strong> (public delegation at registrar for production)<\/li>\n<li><strong>A monitoring strategy<\/strong> for the endpoints (DNS won\u2019t tell you app performance, only where clients go)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/authentication model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Management uses OCI IAM:<\/li>\n<li>Users\/groups with policies to manage DNS and Traffic Management objects<\/li>\n<li>API calls are signed with OCI credentials (Console\/CLI\/SDK)<\/li>\n<li>Query plane is public DNS protocol; security is improved with DNSSEC where applicable.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model (practical view)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>DNS authoritative endpoints are managed by OCI.<\/li>\n<li>Your endpoints (LBs\/instances) sit in your VCN or outside OCI.<\/li>\n<li>Health checks originate from OCI-managed vantage points; endpoints must allow that inbound traffic (verify recommended allowlists in Health Checks docs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoring\/logging\/governance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>OCI Audit<\/strong> to track DNS changes.<\/li>\n<li>Monitor endpoint availability with <strong>OCI Health Checks<\/strong> and\/or <strong>OCI Monitoring<\/strong> on the workloads.<\/li>\n<li>Use <strong>tags<\/strong> and compartment structure for cost allocation and governance.<\/li>\n<li>Consider external monitoring from another provider to validate real-world DNS resolution and application reachability.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Simple architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  U[User Device] --&gt; R[Recursive Resolver]\n  R --&gt;|DNS query| OCI_DNS[OCI Authoritative DNS]\n  OCI_DNS --&gt;|Steering policy answer| R\n  R --&gt; U\n  U --&gt;|HTTP\/HTTPS| EP1[Endpoint A\\n(OCI LB \/ Compute)]\n  U --&gt;|HTTP\/HTTPS| EP2[Endpoint B\\n(OCI LB \/ DR Region)]\n  HC[OCI Health Checks] --&gt;|Probes| EP1\n  HC --&gt;|Probes| EP2\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Production-style architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  subgraph Internet\n    Users[Users]\n    Resolvers[Recursive DNS Resolvers]\n  end\n\n  subgraph OCI_Global[\"OCI DNS and Traffic Management (Global)\"]\n    AuthDNS[Authoritative DNS Zones]\n    Steering[Traffic Management\\nSteering Policies + Attachments]\n  end\n\n  subgraph RegionA[\"OCI Region A\"]\n    WAF_A[WAF \/ Edge Policy\\n(optional)]\n    LB_A[Public Load Balancer]\n    App_A[App Tier]\n    DB_A[(Database)]\n  end\n\n  subgraph RegionB[\"OCI Region B (DR or Active-Active)\"]\n    WAF_B[WAF \/ Edge Policy\\n(optional)]\n    LB_B[Public Load Balancer]\n    App_B[App Tier]\n    DB_B[(Database \/ Replica)]\n  end\n\n  Health[OCI Health Checks]:::svc\n\n  Users --&gt; Resolvers\n  Resolvers --&gt;|DNS| AuthDNS\n  AuthDNS --&gt; Steering\n  Steering --&gt;|Answer A or B| Resolvers\n  Users --&gt;|HTTP\/HTTPS| WAF_A\n  Users --&gt;|HTTP\/HTTPS| WAF_B\n  WAF_A --&gt; LB_A --&gt; App_A --&gt; DB_A\n  WAF_B --&gt; LB_B --&gt; App_B --&gt; DB_B\n\n  Health --&gt;|Probe| LB_A\n  Health --&gt;|Probe| LB_B\n\n  classDef svc fill:#f6f6f6,stroke:#888,stroke-width:1px;\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Tenancy\/account requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>An <strong>Oracle Cloud<\/strong> (OCI) tenancy with permission to create networking and DNS resources.<\/li>\n<li>A compartment strategy:<\/li>\n<li>One compartment for the lab (recommended), separate from production.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions \/ IAM policies<\/h3>\n\n\n\n<p>You need permission to manage:\n&#8211; DNS zones and records\n&#8211; Traffic Management steering policies and attachments\n&#8211; Health Checks (for health-based steering)\n&#8211; Compute\/Networking (for lab endpoints)<\/p>\n\n\n\n<p>Example IAM policies (adjust group and compartment names):<\/p>\n\n\n\n<pre><code class=\"language-text\">Allow group DNS-Lab-Admins to manage dns in compartment DNS-Lab\nAllow group DNS-Lab-Admins to manage health-checks in compartment DNS-Lab\nAllow group DNS-Lab-Admins to manage virtual-network-family in compartment DNS-Lab\nAllow group DNS-Lab-Admins to manage instance-family in compartment DNS-Lab\n<\/code><\/pre>\n\n\n\n<blockquote>\n<p>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.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Billing requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>DNS may not have a direct line-item charge in many cases, but <strong>related resources<\/strong> do:<\/li>\n<li>Compute instances, Load Balancers, outbound data transfer, and possibly Health Checks depending on your usage and pricing model.<\/li>\n<li>Use <strong>Oracle Cloud Free Tier \/ Always Free<\/strong> where possible for a low-cost lab (verify current Free Tier eligibility and quotas in your tenancy\/region).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Tools (recommended)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>OCI Console<\/strong> (web UI)<\/li>\n<li><strong>OCI CLI<\/strong> (optional but helpful): https:\/\/docs.oracle.com\/en-us\/iaas\/Content\/API\/SDKDocs\/cliinstall.htm<\/li>\n<li><strong>dig<\/strong> (DNS query tool) on your workstation<\/li>\n<li><strong>ssh<\/strong> client if you create compute instances for endpoints<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Region availability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>OCI DNS is generally available across OCI regions (service availability can vary).<\/li>\n<li>Choose a region where you can also create compute instances for the lab.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas \/ limits<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>DNS zones, records, steering policies, and health checks have service limits.<\/li>\n<li>Check OCI <strong>Service Limits<\/strong> for DNS, Traffic Management, and Health Checks in your region\/tenancy.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services for the lab<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>OCI Virtual Cloud Network (VCN) with a public subnet (for HTTP endpoints)<\/li>\n<li>Two compute instances (optional but used in this tutorial)<\/li>\n<li>OCI Health Checks<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing model (how costs are typically incurred)<\/h3>\n\n\n\n<p>For <strong>DNS and Traffic Management<\/strong>, costs can come from:\n1. <strong>DNS service usage<\/strong> (zone hosting, queries, and advanced features) \u2014 pricing may be $0 or billed depending on Oracle\u2019s current model and your contract.\n2. <strong>Traffic Management<\/strong> (steering policies\/attachments) \u2014 often priced as part of DNS, but confirm.\n3. <strong>Health Checks<\/strong> \u2014 may have its own pricing dimension (number of checks, frequency, probe regions\/vantage points). Verify current pricing.\n4. <strong>Endpoints you route to<\/strong>:\n   &#8211; Compute instances\n   &#8211; Load Balancers (commonly a major cost driver)\n   &#8211; WAF\/CDN (if used)\n5. <strong>Data transfer<\/strong>:\n   &#8211; Internet egress from your endpoints (not DNS itself, but the traffic you direct)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Official pricing sources (verify current SKUs)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Oracle Cloud Pricing overview: https:\/\/www.oracle.com\/cloud\/pricing\/<\/li>\n<li>Oracle Cloud Price List (search for DNS, Health Checks, Load Balancer): https:\/\/www.oracle.com\/cloud\/price-list\/<\/li>\n<li>OCI Cost Estimator: https:\/\/www.oracle.com\/cloud\/costestimator.html<\/li>\n<\/ul>\n\n\n\n<blockquote>\n<p>Do not rely on third-party blogs for OCI pricing. Always validate on Oracle\u2019s official pricing pages or your contracted rate card.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing dimensions to expect (conceptually)<\/h3>\n\n\n\n<p>Depending on Oracle\u2019s current pricing for your region\/contract, you may see:\n&#8211; Number of <strong>DNS zones<\/strong> (public and\/or private)\n&#8211; Volume of <strong>DNS queries<\/strong> (authoritative query count)\n&#8211; Number of <strong>steering policy attachments<\/strong> (names using Traffic Management)\n&#8211; Number of <strong>health checks<\/strong>, check interval, and probe distribution\n&#8211; Compute\/LB hourly rates and throughput\n&#8211; Outbound internet data transfer (GB)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Free tier considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>OCI Free Tier often includes Always Free compute shapes and limited networking usage.<\/li>\n<li>Whether <strong>DNS and Traffic Management<\/strong> and <strong>Health Checks<\/strong> are free or included depends on Oracle\u2019s current policy\u2014verify in pricing docs and your tenancy\u2019s Free Tier details.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost drivers (what increases your bill)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Large DNS query volumes to authoritative servers<\/li>\n<li>Many attachments and many endpoints per policy<\/li>\n<li>Short health check intervals (more probes)<\/li>\n<li>Using paid LBs\/WAF\/CDN in multiple regions<\/li>\n<li>High outbound traffic from endpoints (internet egress)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Hidden\/indirect costs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Operational costs<\/strong>: staff time to manage DNS changes, incident response, and testing<\/li>\n<li><strong>Multi-region duplication<\/strong>: duplicate LBs and app stacks in two regions<\/li>\n<li><strong>Certificate management<\/strong>: if you add HTTPS endpoints, cert operations may involve other services\/tools<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost optimization tips<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>longer TTLs<\/strong> for stable records; use shorter TTLs only for migration windows.<\/li>\n<li>Prefer <strong>Traffic Management<\/strong> at strategic entry points (like <code>www<\/code> and <code>api<\/code>) rather than on thousands of per-tenant names unless needed.<\/li>\n<li>Avoid over-provisioning health checks; align check frequency with RTO\/RPO goals.<\/li>\n<li>For production, consider routing to <strong>Load Balancers<\/strong> (stable) rather than ephemeral instance IPs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate (no fabricated numbers)<\/h3>\n\n\n\n<p>A minimal lab can be near-zero cost if you:\n&#8211; Use Always Free compute (if available)\n&#8211; Avoid paid load balancers\n&#8211; Keep DNS zones and health checks within free allowances (if applicable)<\/p>\n\n\n\n<p>Because exact pricing varies by region and Oracle policy, <strong>verify in the official price list<\/strong> before assuming $0.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations<\/h3>\n\n\n\n<p>In production, the bill is commonly dominated by:\n&#8211; Regional load balancers (hourly + bandwidth\/LCU-style metrics depending on SKU)\n&#8211; Multi-region duplication (two of everything)\n&#8211; Outbound internet data transfer\nDNS and steering policies are usually a smaller fraction, but <strong>high query volume<\/strong> can change that\u2014measure authoritative query rates and plan accordingly.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">10. Step-by-Step Hands-On Tutorial<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<p>Deploy a small, real <strong>DNS and Traffic Management<\/strong> setup in Oracle Cloud:\n&#8211; Create two HTTP endpoints (two small OCI compute instances)\n&#8211; Create health checks for both endpoints\n&#8211; Create a DNS zone and a Traffic Management steering policy\n&#8211; Attach the policy to a DNS name and verify <strong>automatic failover<\/strong><\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p>You will build:\n&#8211; <code>web-a<\/code>: Nginx server returning \u201cA\u201d\n&#8211; <code>web-b<\/code>: Nginx server returning \u201cB\u201d\n&#8211; Health checks: probe both servers\n&#8211; DNS zone: <code>lab.example<\/code> (not delegated; we\u2019ll test by querying OCI authoritative nameservers directly)\n&#8211; Steering policy attachment for <code>www.lab.example<\/code>:\n  &#8211; Return <code>web-a<\/code> when healthy\n  &#8211; Fail over to <code>web-b<\/code> when <code>web-a<\/code> is unhealthy<\/p>\n\n\n\n<p><strong>Estimated time:<\/strong> 60\u2013120 minutes<br\/>\n<strong>Risk level:<\/strong> Low (uses small instances; you can fully clean up)<\/p>\n\n\n\n<blockquote>\n<p>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.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Create a compartment for the lab<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>In the OCI Console, go to <strong>Identity &amp; Security \u2192 Compartments<\/strong>.<\/li>\n<li>Click <strong>Create Compartment<\/strong>.<\/li>\n<li>Name: <code>DNS-Lab<\/code><\/li>\n<li>Create.<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome:<\/strong> A compartment to isolate all lab resources.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Create IAM group and policies (if you don\u2019t already have access)<\/h3>\n\n\n\n<p>If you already have sufficient privileges, you can skip.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Go to <strong>Identity &amp; Security \u2192 Groups<\/strong> \u2192 <strong>Create Group<\/strong>\n   &#8211; Name: <code>DNS-Lab-Admins<\/code><\/li>\n<li>Add your user to the group.<\/li>\n<li>Go to <strong>Identity &amp; Security \u2192 Policies<\/strong> \u2192 <strong>Create Policy<\/strong> in the <strong>root compartment<\/strong> (or appropriate parent).<\/li>\n<li>Add policy statements (edit group\/compartment names as needed):<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-text\">Allow group DNS-Lab-Admins to manage dns in compartment DNS-Lab\nAllow group DNS-Lab-Admins to manage health-checks in compartment DNS-Lab\nAllow group DNS-Lab-Admins to manage virtual-network-family in compartment DNS-Lab\nAllow group DNS-Lab-Admins to manage instance-family in compartment DNS-Lab\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> You can create DNS zones\/policies, health checks, VCNs, and instances within <code>DNS-Lab<\/code>.<\/p>\n\n\n\n<p><strong>Verification:<\/strong> Try opening the DNS service page and ensure you don\u2019t see \u201cNot authorized\u201d.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Create a VCN with internet connectivity<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Go to <strong>Networking \u2192 Virtual Cloud Networks<\/strong>.<\/li>\n<li>Choose compartment <code>DNS-Lab<\/code>.<\/li>\n<li>Click <strong>Start VCN Wizard<\/strong>.<\/li>\n<li>Select <strong>VCN with Internet Connectivity<\/strong>.<\/li>\n<li>Create with defaults (or set):\n   &#8211; VCN name: <code>dns-lab-vcn<\/code>\n   &#8211; Public subnet: <code>dns-lab-public-subnet<\/code><\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome:<\/strong> A VCN with:\n&#8211; Internet Gateway\n&#8211; Route table allowing 0.0.0.0\/0 to IGW\n&#8211; Public subnet<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Create two compute instances (web-a and web-b)<\/h3>\n\n\n\n<p>We\u2019ll use small Linux instances and install Nginx.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Go to <strong>Compute \u2192 Instances<\/strong> \u2192 <strong>Create Instance<\/strong><\/li>\n<li>Compartment: <code>DNS-Lab<\/code><\/li>\n<li>Name: <code>web-a<\/code><\/li>\n<li>Image: Oracle Linux (or another supported Linux)<\/li>\n<li>Shape: pick an Always Free eligible shape if available (verify availability)<\/li>\n<li>Networking: select <code>dns-lab-vcn<\/code> and <code>dns-lab-public-subnet<\/code><\/li>\n<li>Assign a <strong>public IPv4 address<\/strong><\/li>\n<li>Add your SSH public key<\/li>\n<li>Create.<\/li>\n<\/ol>\n\n\n\n<p>Repeat for <code>web-b<\/code>.<\/p>\n\n\n\n<p><strong>Expected outcome:<\/strong> Two running instances, each with a public IP.<\/p>\n\n\n\n<p><strong>Verification:<\/strong> In each instance details page, copy the <strong>Public IPv4 address<\/strong>.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Open inbound port 80 to the instances<\/h3>\n\n\n\n<p>To allow HTTP and health checks, permit inbound TCP\/80. Depending on how your subnet is configured, you\u2019ll update either:\n&#8211; Security List rules (subnet-level), or\n&#8211; Network Security Group (NSG) rules (instance-level)<\/p>\n\n\n\n<p>For a basic wizard VCN using security lists:\n1. Go to <strong>Networking \u2192 Virtual Cloud Networks \u2192 dns-lab-vcn<\/strong>\n2. <strong>Security Lists<\/strong> \u2192 open the one attached to your public subnet\n3. <strong>Add Ingress Rules<\/strong>\n   &#8211; Source CIDR: <code>0.0.0.0\/0<\/code> (lab only; production should be tighter)\n   &#8211; IP Protocol: TCP\n   &#8211; Destination Port Range: 80<\/p>\n\n\n\n<p><strong>Expected outcome:<\/strong> Instances accept inbound HTTP from the internet.<\/p>\n\n\n\n<p><strong>Verification:<\/strong> From your laptop:<\/p>\n\n\n\n<pre><code class=\"language-bash\">curl -I http:\/\/&lt;WEB_A_PUBLIC_IP&gt;\/\ncurl -I http:\/\/&lt;WEB_B_PUBLIC_IP&gt;\/\n<\/code><\/pre>\n\n\n\n<p>You may get a connection error until Nginx is installed (next step), but the TCP path should be open.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 6: Install and configure Nginx on both instances<\/h3>\n\n\n\n<p>SSH to each instance and install a web server.<\/p>\n\n\n\n<p>For <code>web-a<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-bash\">ssh opc@&lt;WEB_A_PUBLIC_IP&gt;\nsudo dnf -y install nginx\necho \"Hello from web-a\" | sudo tee \/usr\/share\/nginx\/html\/index.html\nsudo systemctl enable --now nginx\n<\/code><\/pre>\n\n\n\n<p>For <code>web-b<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-bash\">ssh opc@&lt;WEB_B_PUBLIC_IP&gt;\nsudo dnf -y install nginx\necho \"Hello from web-b\" | sudo tee \/usr\/share\/nginx\/html\/index.html\nsudo systemctl enable --now nginx\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Both endpoints return unique content.<\/p>\n\n\n\n<p><strong>Verification:<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">curl http:\/\/&lt;WEB_A_PUBLIC_IP&gt;\/\ncurl http:\/\/&lt;WEB_B_PUBLIC_IP&gt;\/\n<\/code><\/pre>\n\n\n\n<p>You should see:\n&#8211; <code>Hello from web-a<\/code>\n&#8211; <code>Hello from web-b<\/code><\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 7: Create OCI Health Checks for both endpoints<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Go to <strong>Networking \u2192 Health Checks<\/strong> (service name may appear under Networking).<\/li>\n<li>Compartment: <code>DNS-Lab<\/code><\/li>\n<li><strong>Create Health Check<\/strong>\n   &#8211; Name: <code>hc-web-a<\/code>\n   &#8211; Targets: <code>&lt;WEB_A_PUBLIC_IP&gt;<\/code>\n   &#8211; Protocol: HTTP\n   &#8211; Port: 80\n   &#8211; Path: <code>\/<\/code>\n   &#8211; Interval\/timeout: choose defaults or a reasonable low interval for the lab<\/li>\n<li>Create.<\/li>\n<\/ol>\n\n\n\n<p>Repeat for <code>hc-web-b<\/code> targeting <code>&lt;WEB_B_PUBLIC_IP&gt;<\/code>.<\/p>\n\n\n\n<p><strong>Expected outcome:<\/strong> Two health checks showing status for each endpoint.<\/p>\n\n\n\n<p><strong>Verification:<\/strong>\n&#8211; Wait for the checks to run.\n&#8211; Status should become <strong>Healthy<\/strong>.<\/p>\n\n\n\n<blockquote>\n<p>If health checks remain unhealthy, verify your security rules allow inbound TCP\/80 and the instance is running Nginx.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 8: Create a public DNS zone (not delegated)<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Go to <strong>Networking \u2192 DNS Management<\/strong> (or <strong>DNS<\/strong> in OCI Console).<\/li>\n<li>Compartment: <code>DNS-Lab<\/code><\/li>\n<li><strong>Create Zone<\/strong>\n   &#8211; Zone type: <strong>Public<\/strong>\n   &#8211; Zone name: <code>lab.example<\/code> (you can use any domain-like name for testing)<\/li>\n<li>Create.<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome:<\/strong> Zone exists and OCI provides authoritative nameservers for it.<\/p>\n\n\n\n<p><strong>Verification:<\/strong>\n&#8211; In the zone details, note the <strong>nameserver<\/strong> hostnames.\n&#8211; You will query these nameservers directly with <code>dig<\/code>.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 9: Create a steering policy (Failover) in Traffic Management<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>In DNS, find <strong>Traffic Management<\/strong> (or steering policies).<\/li>\n<li><strong>Create Steering Policy<\/strong>\n   &#8211; Name: <code>sp-failover-www<\/code>\n   &#8211; Template\/Policy type: choose <strong>Failover<\/strong> (if templates are offered)\n   &#8211; Add answers\/endpoints:<ul>\n<li>Primary answer: <code>&lt;WEB_A_PUBLIC_IP&gt;<\/code> (A record)<\/li>\n<li>Secondary answer: <code>&lt;WEB_B_PUBLIC_IP&gt;<\/code> (A record)<\/li>\n<li>Attach health checks:<\/li>\n<li>Primary uses <code>hc-web-a<\/code><\/li>\n<li>Secondary uses <code>hc-web-b<\/code><\/li>\n<li>Set TTL appropriate for lab (lower TTL makes testing faster, but caching still applies)<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n\n\n\n<p>If OCI uses rule-based steering instead of a \u201cfailover template,\u201d implement failover using:\n&#8211; A <strong>HEALTH<\/strong> rule referencing monitors, combined with\n&#8211; A <strong>PRIORITY<\/strong> rule choosing primary then secondary<br\/>\n(Exact UI terms can vary\u2014follow the current console workflow and verify in official docs.)<\/p>\n\n\n\n<p><strong>Expected outcome:<\/strong> A steering policy exists that will prefer <code>web-a<\/code> when healthy, otherwise answer <code>web-b<\/code>.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 10: Attach the steering policy to <code>www.lab.example<\/code><\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Create a <strong>Steering Policy Attachment<\/strong>\n   &#8211; Zone: <code>lab.example<\/code>\n   &#8211; Domain name: <code>www.lab.example<\/code>\n   &#8211; Steering policy: <code>sp-failover-www<\/code><\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome:<\/strong> DNS queries for <code>www.lab.example<\/code> are answered by the steering policy rather than a static A record.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 11: Validate DNS answers using the OCI authoritative nameserver<\/h3>\n\n\n\n<p>Because we didn\u2019t delegate the domain, query OCI nameservers directly.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p>Pick one authoritative nameserver from the zone details, such as:\n   &#8211; <code>ns1.p##.dns.oraclecloud.net<\/code> (example format; use your actual value)<\/p>\n<\/li>\n<li>\n<p>Query it:<\/p>\n<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">dig @&lt;AUTHORITATIVE_NS_HOSTNAME&gt; www.lab.example A +short\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> You see <code>&lt;WEB_A_PUBLIC_IP&gt;<\/code> (primary) while healthy.<\/p>\n\n\n\n<p><strong>Also validate HTTP content:<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">curl http:\/\/$(dig @&lt;AUTHORITATIVE_NS_HOSTNAME&gt; www.lab.example A +short)\/\n<\/code><\/pre>\n\n\n\n<p>You should see <code>Hello from web-a<\/code>.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 12: Trigger failover and confirm Traffic Management behavior<\/h3>\n\n\n\n<p>Simulate failure on <code>web-a<\/code> by stopping Nginx:<\/p>\n\n\n\n<pre><code class=\"language-bash\">ssh opc@&lt;WEB_A_PUBLIC_IP&gt;\nsudo systemctl stop nginx\n<\/code><\/pre>\n\n\n\n<p>Wait long enough for the health check to detect failure (depends on interval and failure threshold).<\/p>\n\n\n\n<p>Now query DNS again:<\/p>\n\n\n\n<pre><code class=\"language-bash\">dig @&lt;AUTHORITATIVE_NS_HOSTNAME&gt; www.lab.example A +short\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> After health transitions, the answer becomes <code>&lt;WEB_B_PUBLIC_IP&gt;<\/code>.<\/p>\n\n\n\n<p>Confirm content:<\/p>\n\n\n\n<pre><code class=\"language-bash\">curl http:\/\/$(dig @&lt;AUTHORITATIVE_NS_HOSTNAME&gt; www.lab.example A +short)\/\n<\/code><\/pre>\n\n\n\n<p>You should see <code>Hello from web-b<\/code>.<\/p>\n\n\n\n<blockquote>\n<p>Note about caching: Since you query the authoritative server directly using <code>@nameserver<\/code>, caching is minimized. If you test through normal resolvers, TTL and resolver caching can delay visible changes.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Validation<\/h3>\n\n\n\n<p>Use this checklist:\n&#8211; [ ] <code>web-a<\/code> and <code>web-b<\/code> respond on <code>http:\/\/&lt;public-ip&gt;\/<\/code>\n&#8211; [ ] Health checks show healthy when Nginx is running\n&#8211; [ ] <code>dig @&lt;authoritative-ns&gt; www.lab.example A +short<\/code> returns <code>web-a<\/code> when healthy\n&#8211; [ ] When <code>web-a<\/code> is unhealthy, the DNS answer shifts to <code>web-b<\/code>\n&#8211; [ ] Restoring <code>web-a<\/code> returns traffic to primary (depending on policy logic and health state)<\/p>\n\n\n\n<p>To restore <code>web-a<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-bash\">ssh opc@&lt;WEB_A_PUBLIC_IP&gt;\nsudo systemctl start nginx\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting<\/h3>\n\n\n\n<p><strong>Problem: Health checks stay unhealthy<\/strong>\n&#8211; Confirm port 80 is allowed in Security List\/NSG.\n&#8211; Confirm Nginx is running: <code>sudo systemctl status nginx<\/code>\n&#8211; Confirm the instance has a public IP and route to IGW.\n&#8211; Check if your organization IP reputation or firewall blocks probe sources.\n&#8211; Verify Health Checks documentation for current probe IP ranges and allowlist guidance.<\/p>\n\n\n\n<p><strong>Problem: <code>dig<\/code> returns no answer<\/strong>\n&#8211; Ensure you are querying the correct authoritative nameserver hostname from zone details.\n&#8211; Confirm the steering policy attachment is for the exact name (<code>www.lab.example<\/code>).\n&#8211; Confirm record type (A) matches the attachment\/policy behavior.<\/p>\n\n\n\n<p><strong>Problem: Failover doesn\u2019t happen<\/strong>\n&#8211; Health checks might still be considered healthy due to thresholds.\n&#8211; Wait longer, or reduce health check interval\/failure threshold (lab only).\n&#8211; Ensure the steering policy is actually using the health checks (not created but not referenced).<\/p>\n\n\n\n<p><strong>Problem: You see both IPs or unexpected ordering<\/strong>\n&#8211; Your policy might be load-balancing rather than failover.\n&#8211; Re-check the steering template\/type and rules.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Cleanup<\/h3>\n\n\n\n<p>To avoid ongoing charges:\n1. Delete steering policy attachment.\n2. Delete steering policy.\n3. Delete health checks.\n4. Delete the DNS zone (only if not used elsewhere).\n5. Terminate compute instances <code>web-a<\/code> and <code>web-b<\/code>.\n6. Delete the VCN <code>dns-lab-vcn<\/code> (will remove subnets, IGW, etc., if not in use).<\/p>\n\n\n\n<blockquote>\n<p>Delete in this order to avoid dependency errors.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">11. Best Practices<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Architecture best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Route users to <strong>stable front doors<\/strong> (Load Balancers, API Gateways, CDN\/WAF endpoints) rather than directly to ephemeral instance IPs.<\/li>\n<li>Use Traffic Management for:<\/li>\n<li><strong>Cross-region<\/strong> routing decisions<\/li>\n<li><strong>Failover<\/strong> and coarse traffic shifting<br\/>\n  Use load balancers\/ingress for <strong>fine-grained<\/strong> L7 routing.<\/li>\n<li>Design with DNS caching in mind:<\/li>\n<li>Keep TTLs higher for normal operation<\/li>\n<li>Lower TTLs temporarily during migrations (and raise them back)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM\/security best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Separate duties:<\/li>\n<li>Zone administration vs record changes vs traffic policies<\/li>\n<li>Use compartments:<\/li>\n<li><code>prod-dns<\/code>, <code>nonprod-dns<\/code>, <code>shared-services<\/code><\/li>\n<li>Apply least privilege:<\/li>\n<li>Only CI\/CD or a limited group can change production DNS<\/li>\n<li>Require MFA and strong identity hygiene for privileged users<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Avoid \u201cpolicy sprawl\u201d: too many attachments and health checks can add cost and complexity.<\/li>\n<li>Use health check frequency appropriate to your RTO (don\u2019t probe every few seconds unless necessary).<\/li>\n<li>Monitor and forecast costs for <strong>Load Balancers<\/strong> and <strong>egress<\/strong>, which usually dominate.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Performance best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>geo steering<\/strong> (when appropriate and supported) to reduce latency.<\/li>\n<li>Use multiple endpoints per region and multi-A answers where it makes sense.<\/li>\n<li>Keep DNS responses small (avoid excessive record bloat).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Reliability best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Test failover regularly (game days).<\/li>\n<li>Ensure secondary endpoints are truly independent (different region, separate dependencies).<\/li>\n<li>Don\u2019t rely on DNS alone for resilience:<\/li>\n<li>Combine with multi-region data replication and application-level resilience.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operations best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Track DNS changes with:<\/li>\n<li>Ticketing\/approvals (where required)<\/li>\n<li>CI\/CD pipelines and versioned DNS configurations<\/li>\n<li>Maintain runbooks:<\/li>\n<li>\u201cFailover to DR region\u201d<\/li>\n<li>\u201cRollback to primary\u201d<\/li>\n<li>Document TTL strategy and expected propagation delays.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance\/tagging\/naming best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Naming conventions:<\/li>\n<li><code>zone-prod-example-com<\/code><\/li>\n<li><code>sp-failover-www-prod<\/code><\/li>\n<li><code>hc-us-ashburn-lb-https<\/code><\/li>\n<li>Tag resources with:<\/li>\n<li><code>Environment=Prod<\/code><\/li>\n<li><code>Owner=Platform<\/code><\/li>\n<li><code>CostCenter=...<\/code><\/li>\n<li>Define standard policy templates:<\/li>\n<li>Failover, weighted rollout, geo steering patterns<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">12. Security Considerations<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Identity and access model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>OCI IAM controls DNS and Traffic Management resources:<\/li>\n<li>Zones, records, steering policies, attachments<\/li>\n<li>Use separate groups for:<\/li>\n<li>Read-only DNS viewers<\/li>\n<li>DNS editors<\/li>\n<li>DNS admins<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Management plane traffic uses HTTPS to OCI APIs.<\/li>\n<li>DNS query plane is standard DNS (UDP\/TCP 53) without inherent encryption.<\/li>\n<li>If your requirement is encrypted DNS transport (DoH\/DoT), verify OCI DNS capabilities and consider an alternate approach if required.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network exposure<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Public zones expose names publicly once delegated.<\/li>\n<li>Private DNS avoids internet exposure but must be carefully designed to prevent unintended access across networks.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secrets handling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>DNS itself doesn\u2019t typically store secrets, but TXT records are sometimes misused for sensitive data.<\/li>\n<li>Avoid putting secrets in TXT records.<\/li>\n<li>Use OCI Vault or another secrets manager instead.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Audit\/logging<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>OCI Audit<\/strong> to track who changed DNS and steering policies.<\/li>\n<li>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).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>DNSSEC may be required in some industries.<\/li>\n<li>Change management and least privilege are common audit requirements.<\/li>\n<li>Document delegation, key management (for DNSSEC), and failover testing evidence.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Common security mistakes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Allowing too many users to modify production zones<\/li>\n<li>Using very low TTLs permanently (can increase query load and operational sensitivity)<\/li>\n<li>Forgetting to restrict health check probe traffic rules (or accidentally blocking it)<\/li>\n<li>Storing sensitive verification tokens longer than needed<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secure deployment recommendations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enable DNSSEC where required and validated end-to-end (registrar \u2192 OCI \u2192 resolvers).<\/li>\n<li>Use separate compartments and policies for prod\/non-prod.<\/li>\n<li>Use automation pipelines with approvals for production record changes.<\/li>\n<li>Keep a well-defined break-glass procedure for incidents.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">DNS caching is unavoidable<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Even with a low TTL, recursive resolvers and clients may not honor it perfectly.<\/li>\n<li>Failover won\u2019t be instantaneous for all users.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Health check realism<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A health check can only test what you configure (HTTP status, TCP connect, etc.).<\/li>\n<li>Your app can be \u201chealthy\u201d by check but still broken for users (dependency failures, auth issues).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Apex record constraints<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Standard DNS does not allow CNAME at the zone apex.<\/li>\n<li>If you need \u201capex to LB\u201d style behavior, verify OCI\u2019s ALIAS-like support and its exact semantics.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Multi-region dependencies<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>DNS failover is pointless if both regions depend on the same:<\/li>\n<li>Identity provider<\/li>\n<li>Database<\/li>\n<li>Third-party API<\/li>\n<li>Network path<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas\/service limits<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Limits exist for zones, records, policies, attachments, and health checks.<\/li>\n<li>Check <strong>Service Limits<\/strong> and plan capacity before large migrations.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational propagation<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Changes may take time to apply across authoritative infrastructure.<\/li>\n<li>Coordinate changes with TTL reduction windows.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Vendor-specific nuances<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Traffic Management rules and health check integration are OCI-specific.<\/li>\n<li>If you later migrate DNS providers, you must map policies to the new provider\u2019s model (not always 1:1).<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Nearest services in Oracle Cloud<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>OCI Load Balancing<\/strong>: best for L4\/L7 traffic distribution within a region; can be multi-region only with external mechanisms (DNS\/clients).<\/li>\n<li><strong>OCI WAF \/ CDN<\/strong> (if used): protects and accelerates HTTP(S) at the edge; still typically uses DNS to direct users to the edge endpoint.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Nearest services in other clouds<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>AWS Route 53<\/strong> (DNS + routing policies + health checks)<\/li>\n<li><strong>Azure DNS + Azure Traffic Manager<\/strong> (DNS + DNS-based traffic steering)<\/li>\n<li><strong>Google Cloud DNS<\/strong> plus other traffic products (DNS is separate from traffic steering; global load balancing can play a similar role depending on design)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Open-source \/ self-managed alternatives<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>BIND \/ Knot \/ PowerDNS<\/strong> authoritative DNS (you run it)<\/li>\n<li>Health checking + dynamic updates via custom automation<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Comparison table<\/h4>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Option<\/th>\n<th>Best For<\/th>\n<th>Strengths<\/th>\n<th>Weaknesses<\/th>\n<th>When to Choose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>OCI DNS and Traffic Management<\/strong><\/td>\n<td>OCI-centric DNS governance + DNS-based steering<\/td>\n<td>Integrated IAM\/compartments, steering policies, OCI-native patterns<\/td>\n<td>DNS caching limits; policy model differs from other vendors<\/td>\n<td>You run workloads in OCI and want OCI-governed DNS + traffic steering<\/td>\n<\/tr>\n<tr>\n<td><strong>OCI Load Balancing<\/strong><\/td>\n<td>In-region traffic distribution<\/td>\n<td>L7 routing, TLS termination, backend health, sticky sessions<\/td>\n<td>Not a global routing solution by itself<\/td>\n<td>You need application-layer routing within a region\/VCN<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS Route 53<\/strong><\/td>\n<td>AWS-heavy or multi-cloud DNS<\/td>\n<td>Mature routing policies, deep ecosystem integration<\/td>\n<td>Different IAM\/governance model; data residency considerations<\/td>\n<td>Your core platform is AWS or you standardize on Route 53<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure Traffic Manager + Azure DNS<\/strong><\/td>\n<td>Azure-heavy architectures<\/td>\n<td>Simple DNS-based traffic steering<\/td>\n<td>DNS-only steering (same caching limits)<\/td>\n<td>Your workloads are primarily in Azure<\/td>\n<\/tr>\n<tr>\n<td><strong>Cloudflare DNS + steering<\/strong><\/td>\n<td>Internet edge performance + security<\/td>\n<td>Strong edge network, advanced features<\/td>\n<td>Different governance\/vendor dependency<\/td>\n<td>You want a third-party edge-first DNS\/security platform<\/td>\n<\/tr>\n<tr>\n<td><strong>Self-managed BIND\/PowerDNS<\/strong><\/td>\n<td>Full control, niche requirements<\/td>\n<td>Customization, on-prem integration<\/td>\n<td>You manage uptime, scaling, patching, DDoS considerations<\/td>\n<td>You have strict sovereignty\/air-gapped needs or legacy constraints<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">15. Real-World Example<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Enterprise example: Multi-region customer portal with DR failover<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A financial services portal must survive regional outages and meet recovery objectives. The organization requires strict IAM controls and auditable DNS changes.<\/li>\n<li><strong>Proposed architecture:<\/strong><\/li>\n<li><code>www.bank.com<\/code> uses OCI DNS zone<\/li>\n<li>Traffic Management steering policy implements priority failover:<ul>\n<li>Primary: OCI WAF \u2192 OCI Load Balancer in Region A<\/li>\n<li>Secondary: OCI WAF \u2192 OCI Load Balancer in Region B<\/li>\n<\/ul>\n<\/li>\n<li>OCI Health Checks monitor <code>\/healthz<\/code> over HTTPS<\/li>\n<li>DNSSEC enabled for the zone (subject to registrar support)<\/li>\n<li>Compartments: <code>prod-network<\/code>, <code>prod-dns<\/code>, <code>prod-security<\/code><\/li>\n<li><strong>Why this service was chosen:<\/strong><\/li>\n<li>Tight integration with OCI IAM and compartment governance<\/li>\n<li>Built-in steering policies and attachments<\/li>\n<li>Straightforward health-check-based failover<\/li>\n<li><strong>Expected outcomes:<\/strong><\/li>\n<li>Reduced manual intervention during incidents<\/li>\n<li>Auditable DNS change history<\/li>\n<li>Predictable DR entry procedure and periodic failover testing<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example: SaaS migration from single VM to OCI with safe rollout<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A startup runs a single VM on another provider and wants to migrate to OCI with minimal risk and an easy rollback.<\/li>\n<li><strong>Proposed architecture:<\/strong><\/li>\n<li>Stand up new OCI Load Balancer + app instances<\/li>\n<li>Use Traffic Management weighted steering:<ul>\n<li>90% old endpoint<\/li>\n<li>10% new OCI endpoint<\/li>\n<\/ul>\n<\/li>\n<li>Gradually increase OCI weight while monitoring errors and latency<\/li>\n<li><strong>Why this service was chosen:<\/strong><\/li>\n<li>Enables gradual cutover without complex proxying<\/li>\n<li>Minimizes downtime risk<\/li>\n<li><strong>Expected outcomes:<\/strong><\/li>\n<li>Controlled migration with rapid rollback (set weight back)<\/li>\n<li>Clear operational playbook for future releases<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<p>1) <strong>Is DNS and Traffic Management a single OCI service?<\/strong><br\/>\nIn OCI, <strong>DNS<\/strong> is the core service, and <strong>Traffic Management<\/strong> is delivered through <strong>steering policies<\/strong> and <strong>attachments<\/strong> that work with DNS. Oracle documentation often presents them together.<\/p>\n\n\n\n<p>2) <strong>Is OCI DNS authoritative?<\/strong><br\/>\nYes\u2014public DNS zones hosted in OCI act as authoritative DNS for delegated domains.<\/p>\n\n\n\n<p>3) <strong>Do I need to own a domain to practice?<\/strong><br\/>\nNo. You can create a public zone and query OCI authoritative nameservers directly using <code>dig @nameserver<\/code>. For real production resolution, you must delegate the domain at your registrar.<\/p>\n\n\n\n<p>4) <strong>What is a steering policy attachment?<\/strong><br\/>\nIt binds a steering policy to a specific DNS name (like <code>www.example.com<\/code>) within a zone.<\/p>\n\n\n\n<p>5) <strong>How does DNS-based failover differ from load balancer failover?<\/strong><br\/>\nDNS 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.<\/p>\n\n\n\n<p>6) <strong>Can I route traffic based on geography?<\/strong><br\/>\nOCI Traffic Management supports geographic-style steering via policy rules (verify the exact rule types and behaviors in current docs).<\/p>\n\n\n\n<p>7) <strong>Can steering policies use health checks?<\/strong><br\/>\nYes. OCI steering policies can integrate with OCI Health Checks so unhealthy endpoints are not returned.<\/p>\n\n\n\n<p>8) <strong>Does Traffic Management replace a CDN or WAF?<\/strong><br\/>\nNo. It decides DNS answers. CDN\/WAF provide caching\/protection\/edge delivery for HTTP(S).<\/p>\n\n\n\n<p>9) <strong>Should I point DNS directly at compute instance IPs?<\/strong><br\/>\nFor labs, it\u2019s fine. In production, it\u2019s usually better to point at stable front doors like <strong>OCI Load Balancers<\/strong>, because instance IPs can change and instances are not ideal as internet entry points.<\/p>\n\n\n\n<p>10) <strong>How quickly does failover happen?<\/strong><br\/>\nIt depends on health check intervals and thresholds, plus DNS TTL and resolver caching. Some clients may continue using cached answers until TTL expiry.<\/p>\n\n\n\n<p>11) <strong>Can I use very low TTL (like 5 seconds) to get instant failover?<\/strong><br\/>\nVery low TTLs can increase query load and still won\u2019t guarantee instant change due to resolver behavior. Use low TTLs strategically and test with real resolvers.<\/p>\n\n\n\n<p>12) <strong>Does OCI DNS support DNSSEC?<\/strong><br\/>\nOCI DNS includes DNSSEC capabilities for zones (verify current support and required steps, including registrar DS record management).<\/p>\n\n\n\n<p>13) <strong>How do I manage DNS changes safely in teams?<\/strong><br\/>\nUse compartments, least-privilege IAM, automation with code review, and OCI Audit tracking. Consider a formal DNS change process for production.<\/p>\n\n\n\n<p>14) <strong>Can I integrate OCI DNS with Terraform?<\/strong><br\/>\nCommonly yes via the OCI Terraform provider, but verify current resource support for zones, records, and steering policies\/attachments in the provider documentation.<\/p>\n\n\n\n<p>15) <strong>What\u2019s the biggest operational gotcha?<\/strong><br\/>\nAssuming DNS failover is immediate. Always design and test with DNS caching realities and have runbooks for incident scenarios.<\/p>\n\n\n\n<p>16) <strong>Can I fail over between OCI and on-prem endpoints?<\/strong><br\/>\nYes, DNS can return any reachable endpoints. Ensure health checks can probe on-prem endpoints (firewall rules, allowlists, and routing must permit it).<\/p>\n\n\n\n<p>17) <strong>Do I get query logs for DNS?<\/strong><br\/>\nOCI 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\u2014do not assume per-query logs exist.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn DNS and Traffic Management<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Resource Type<\/th>\n<th>Name<\/th>\n<th>Why It Is Useful<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Official Documentation<\/td>\n<td>OCI DNS Documentation \u2013 https:\/\/docs.oracle.com\/en-us\/iaas\/Content\/DNS\/home.htm<\/td>\n<td>Core concepts, zones, records, DNSSEC, and operational guidance<\/td>\n<\/tr>\n<tr>\n<td>Official Documentation<\/td>\n<td>OCI Traffic Management Documentation \u2013 https:\/\/docs.oracle.com\/en-us\/iaas\/Content\/TrafficManagement\/home.htm<\/td>\n<td>Steering policies, rule types, attachments, and examples (verify URL if Oracle reorganizes docs)<\/td>\n<\/tr>\n<tr>\n<td>Official Documentation<\/td>\n<td>OCI Health Checks Documentation \u2013 https:\/\/docs.oracle.com\/en-us\/iaas\/Content\/HealthChecks\/home.htm<\/td>\n<td>Health check configuration, probe behavior, and troubleshooting<\/td>\n<\/tr>\n<tr>\n<td>Official CLI Reference<\/td>\n<td>OCI CLI DNS Commands \u2013 https:\/\/docs.oracle.com\/en-us\/iaas\/tools\/oci-cli\/latest\/oci_cli_docs\/cmdref\/dns.html<\/td>\n<td>Automate DNS zones\/records and learn object models<\/td>\n<\/tr>\n<tr>\n<td>Official CLI Reference<\/td>\n<td>OCI CLI Health Checks Commands \u2013 https:\/\/docs.oracle.com\/en-us\/iaas\/tools\/oci-cli\/latest\/oci_cli_docs\/cmdref\/health-checks.html<\/td>\n<td>Automate monitors used in Traffic Management<\/td>\n<\/tr>\n<tr>\n<td>Official Pricing<\/td>\n<td>Oracle Cloud Pricing \u2013 https:\/\/www.oracle.com\/cloud\/pricing\/<\/td>\n<td>High-level pricing model and service entry points<\/td>\n<\/tr>\n<tr>\n<td>Official Pricing<\/td>\n<td>Oracle Cloud Price List \u2013 https:\/\/www.oracle.com\/cloud\/price-list\/<\/td>\n<td>SKU-level detail (search for DNS, Health Checks, Load Balancer)<\/td>\n<\/tr>\n<tr>\n<td>Official Cost Tool<\/td>\n<td>OCI Cost Estimator \u2013 https:\/\/www.oracle.com\/cloud\/costestimator.html<\/td>\n<td>Build estimates for multi-region and LB-heavy designs<\/td>\n<\/tr>\n<tr>\n<td>Official Labs<\/td>\n<td>Oracle LiveLabs Catalog \u2013 https:\/\/apexapps.oracle.com\/pls\/apex\/r\/dbpm\/livelabs\/home<\/td>\n<td>Hands-on labs; search for DNS\/Traffic Management\/Networking<\/td>\n<\/tr>\n<tr>\n<td>Architecture Guidance<\/td>\n<td>OCI Architecture Center \u2013 https:\/\/docs.oracle.com\/solutions\/<\/td>\n<td>Reference architectures; search for DNS, multi-region, DR patterns<\/td>\n<\/tr>\n<tr>\n<td>Community Learning (Reputable)<\/td>\n<td>OCI GitHub \u2013 https:\/\/github.com\/oracle\/oci<\/td>\n<td>Samples and tools; verify DNS-related examples by repo and date<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Institute<\/th>\n<th>Suitable Audience<\/th>\n<th>Likely Learning Focus<\/th>\n<th>Mode<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps engineers, SREs, architects, beginners<\/td>\n<td>OCI fundamentals, DevOps practices, cloud networking basics<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>ScmGalaxy.com<\/td>\n<td>Students, engineers learning tooling<\/td>\n<td>SCM\/DevOps foundations; may include cloud modules<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.scmgalaxy.com\/<\/td>\n<\/tr>\n<tr>\n<td>CLoudOpsNow.in<\/td>\n<td>Cloud ops and platform teams<\/td>\n<td>Operations, monitoring, reliability practices<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.cloudopsnow.in\/<\/td>\n<\/tr>\n<tr>\n<td>SreSchool.com<\/td>\n<td>SREs, platform engineers<\/td>\n<td>Reliability engineering, incident response, operations<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.sreschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>AiOpsSchool.com<\/td>\n<td>Ops + automation practitioners<\/td>\n<td>AIOps concepts, automation, observability<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.aiopsschool.com\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Platform\/Site<\/th>\n<th>Likely Specialization<\/th>\n<th>Suitable Audience<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>RajeshKumar.xyz<\/td>\n<td>DevOps\/cloud training content (verify specific OCI coverage)<\/td>\n<td>Beginners to intermediate engineers<\/td>\n<td>https:\/\/rajeshkumar.xyz\/<\/td>\n<\/tr>\n<tr>\n<td>devopstrainer.in<\/td>\n<td>DevOps training and mentoring (verify course catalog)<\/td>\n<td>Engineers seeking guided learning<\/td>\n<td>https:\/\/www.devopstrainer.in\/<\/td>\n<\/tr>\n<tr>\n<td>devopsfreelancer.com<\/td>\n<td>Freelance DevOps help\/training (treat as a platform unless verified)<\/td>\n<td>Teams needing short-term expert assistance<\/td>\n<td>https:\/\/www.devopsfreelancer.com\/<\/td>\n<\/tr>\n<tr>\n<td>devopssupport.in<\/td>\n<td>DevOps support\/training services (verify offerings)<\/td>\n<td>Ops teams and DevOps practitioners<\/td>\n<td>https:\/\/www.devopssupport.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Company Name<\/th>\n<th>Likely Service Area<\/th>\n<th>Where They May Help<\/th>\n<th>Consulting Use Case Examples<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>cotocus.com<\/td>\n<td>Cloud\/DevOps consulting (verify OCI specialization)<\/td>\n<td>Architecture, automation, operations improvements<\/td>\n<td>DNS governance design, migration runbooks, IaC enablement<\/td>\n<td>https:\/\/cotocus.com\/<\/td>\n<\/tr>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps enablement and training\/consulting<\/td>\n<td>Platform engineering practices, CI\/CD, cloud ops<\/td>\n<td>DNS automation pipeline, production change management, DR testing process<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>DEVOPSCONSULTING.IN<\/td>\n<td>DevOps consulting services (verify portfolio)<\/td>\n<td>DevOps transformation, tooling, operations<\/td>\n<td>Multi-region readiness assessment, monitoring + runbooks, Terraform adoption<\/td>\n<td>https:\/\/www.devopsconsulting.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">21. Career and Learning Roadmap<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn before this service<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>DNS fundamentals:<\/li>\n<li>Authoritative vs recursive DNS<\/li>\n<li>NS delegation, SOA, TTL, record types<\/li>\n<li>OCI fundamentals:<\/li>\n<li>Tenancy, compartments, IAM policies<\/li>\n<li>VCN basics: subnets, IGW, route tables, security lists\/NSGs<\/li>\n<li>Basic Linux and networking:<\/li>\n<li><code>dig<\/code>, <code>curl<\/code>, <code>ssh<\/code>, firewall basics<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after this service<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>OCI Load Balancing (L7 routing, TLS termination, backends)<\/li>\n<li>Multi-region design patterns in OCI:<\/li>\n<li>Data replication, DR drills, RTO\/RPO planning<\/li>\n<li>Security services:<\/li>\n<li>OCI WAF, OCI Vault, Cloud Guard (as applicable)<\/li>\n<li>Observability:<\/li>\n<li>OCI Monitoring\/Logging, distributed tracing (service-dependent)<\/li>\n<li>Infrastructure as Code:<\/li>\n<li>Terraform for OCI DNS, health checks, and networking<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Job roles that use it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Engineer \/ Cloud Administrator<\/li>\n<li>Network Engineer (cloud)<\/li>\n<li>DevOps Engineer<\/li>\n<li>Site Reliability Engineer (SRE)<\/li>\n<li>Solutions Architect \/ Cloud Architect<\/li>\n<li>Security Engineer (DNS governance, DNSSEC, change control)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (if available)<\/h3>\n\n\n\n<p>Oracle updates certification tracks over time. Start by checking Oracle University certification paths relevant to:\n&#8211; OCI Foundations\n&#8211; OCI Architect\n&#8211; OCI Networking (if offered)<\/p>\n\n\n\n<p>Verify current certification names and exam codes at: https:\/\/education.oracle.com\/<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Project ideas for practice<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Build a multi-region \u201chello world\u201d with DNS failover (this lab, extended to two regions)<\/li>\n<li>Implement weighted rollouts for an API version upgrade<\/li>\n<li>Create a private DNS zone for internal services in a VCN (verify Private DNS constructs)<\/li>\n<li>Automate DNS changes with Terraform and a CI\/CD pipeline including approvals<\/li>\n<li>Implement DNSSEC on a test domain and validate with common DNSSEC tools<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">22. Glossary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Authoritative DNS<\/strong>: DNS servers that provide official answers for a domain\u2019s zone data.<\/li>\n<li><strong>Recursive resolver<\/strong>: A DNS server that queries other DNS servers on behalf of a client and caches results.<\/li>\n<li><strong>DNS zone<\/strong>: Administrative boundary containing DNS records for a domain (e.g., <code>example.com<\/code>).<\/li>\n<li><strong>Record (RR)<\/strong>: A DNS entry (A, AAAA, CNAME, TXT, MX, etc.).<\/li>\n<li><strong>RRSet<\/strong>: A set of records with the same name and type (e.g., multiple A records for <code>www<\/code>).<\/li>\n<li><strong>TTL (Time to Live)<\/strong>: Cache duration for a DNS answer.<\/li>\n<li><strong>DNSSEC<\/strong>: Security extensions that sign DNS data to allow validation by resolvers.<\/li>\n<li><strong>Traffic Management steering policy<\/strong>: OCI policy defining how DNS answers are selected (failover, weighted, geo, etc.).<\/li>\n<li><strong>Steering policy attachment<\/strong>: Object that applies a steering policy to a specific DNS name in a zone.<\/li>\n<li><strong>Health check<\/strong>: Active probe to determine if an endpoint is reachable\/healthy.<\/li>\n<li><strong>Endpoint<\/strong>: The destination returned by DNS (IP address, or sometimes hostname depending on record type).<\/li>\n<li><strong>Compartment (OCI)<\/strong>: A logical container for resources in OCI, used for access control and organization.<\/li>\n<li><strong>IAM policy (OCI)<\/strong>: Authorization rules controlling access to OCI resources.<\/li>\n<li><strong>VCN (Virtual Cloud Network)<\/strong>: OCI\u2019s virtual network construct.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p><strong>DNS and Traffic Management<\/strong> in <strong>Oracle Cloud<\/strong> (within <strong>Networking, Edge, and Connectivity<\/strong>) combines managed authoritative DNS with policy-driven routing through <strong>Traffic Management steering policies<\/strong>. It helps you publish reliable DNS records, implement health-aware failover, and steer users across endpoints or regions for resilience and performance.<\/p>\n\n\n\n<p>Key takeaways:\n&#8211; DNS gives you naming; Traffic Management helps decide <em>which endpoint<\/em> DNS should return.\n&#8211; Costs are usually driven more by <strong>load balancers, compute, and egress<\/strong> than by DNS itself, but verify DNS\/health-check pricing in Oracle\u2019s official price list.\n&#8211; Security and governance depend on strong <strong>OCI IAM<\/strong>, compartment design, auditability, and careful DNSSEC implementation where required.\n&#8211; Use it when you need <strong>multi-endpoint or multi-region routing<\/strong>, failover, and controlled rollouts\u2014while accepting DNS caching realities.<\/p>\n\n\n\n<p>Next step: read the official OCI DNS and Traffic Management docs, then extend the lab to <strong>two OCI regions<\/strong> with real delegation of a subdomain and a production-grade front door (OCI Load Balancer + TLS).<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Networking, Edge, and Connectivity<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[74,62],"tags":[],"class_list":["post-943","post","type-post","status-publish","format-standard","hentry","category-networking-edge-and-connectivity","category-oracle-cloud"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/943","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=943"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/943\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=943"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=943"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=943"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}