08 Networking ‐ DNS Management - KleberVales/OCI-Architect-Associate GitHub Wiki

1. What is DNS?

1.1 Introduction to DNS

1.2 How DNS Resolution Works: A Step-by-Step Example

1.3 OCI Domain Name System Capabilities

1.4 Benefits of OCI Public DNS

2. DNS Service Components

2.1 Overview

2.2 Domain

2.3 Zone

2.4 Label

2.5 Child Zone

2.6 Resource Records

3. Zones

3.1 What Is a Zone?

3.2 What Does a Zone Hold?

3.3 Records Created Automatically

3.4 Types of Zones in OCI

4. Public DNS Zones

4.1 What Is a Public DNS Zone?

4.2 The Three Steps to Implement a Public DNS Zone

5. Private DNS Zones

5.1 DNS Options in a Virtual Cloud Network (VCN)

5.2 Private DNS Zones

6. Private Views

6.1 What Is a Private View?

6.2 Key Rules

7. HTTP redirects

7.1 What Are HTTP Redirects?

7.2 Four HTTP Redirect Scenarios

7.3 Required DNS Record

7.4 Configuring HTTP Redirects (Console View)

8. Traffic Management

8.1 What Is Traffic Management?

8.2 Traffic Management Components

8.3 How It Flows

8.4 Steering Policy Types

9. Traffic Management-Policy Types

9.1 The Five Traffic Management Steering Policies

9.2 Failover Policy

9.3 Load Balancer Policy

9.4 Geolocation Steering

9.5 ASN Steering

9.6 IP Prefix Steering

9.7 Use Cases for Traffic Management Steering Policies

.
.
.
.
.

1. What is DNS?

This lesson introduced the Domain Name System (DNS), explaining that its primary function is to translate easy-to-remember domain names into IP addresses — much like how we save contacts by name on our phones instead of memorizing numbers. Using the example of visiting www.example.com, the lesson walked through the full DNS resolution flow: the browser queries a recursive (non-authoritative) DNS server, which then asks the root servers, followed by the TLD servers, and finally the authoritative customer DNS servers that hold the actual records — with the resulting IP address eventually returned to the browser. The lesson distinguished between authoritative servers (which hold records) and recursive servers (which query on your behalf). It then covered OCI DNS capabilities, including creating and managing public zones, adding records (such as NS and SOA records), letting OCI's edge network handle DNS queries, and importing zone files in standard BIND format. Finally, the benefits of OCI Public DNS were highlighted: lowest query latency via anycast across OCI's global regions, built-in DoS protection for resilience against outages and attacks, and industry-leading propagation time for fast responses to DNS changes.

1.1 Introduction to DNS

The Domain Name System (DNS) plays a critical role on the internet, and many internet services are closely related to it.

The main functionality of DNS is to translate easy-to-remember symbolic domain names into IP addresses.

A Simple Analogy

Think about your phone: if you want to call someone, what are the chances you remember their mobile number before dialing? Very slim. So what do you do? You save the number, assign it a name, and when calling, you just click on the name.

DNS works the same way. If you want to visit www.oracle.com, you understand the domain name — but computers and machines don't understand domain names. All they understand is an IP address. So DNS is essentially the mapping of a domain name to an IP address.

DNS can also associate domain names with other forms of information, but the most common example is associating human-friendly domain names with numerical IP addresses.

1.2 How DNS Resolution Works: A Step-by-Step Example

Let's say you're operating a laptop (or a compute instance) with a browser, and you want to visit www.example.com.

The machine doesn't know what www.example.com is, so here's what happens:

  1. The browser queries the DNS server (a recursive/non-authoritative server).
  2. The DNS server reaches out to the root servers (.) and asks: "What is the IP for www.example.com?"
  3. The root server responds: "Ask .com."
  4. The DNS server asks the TLD (Top Level Domain) servers for .com: "What is the IP of www.example.com?"
  5. The TLD server responds: "Ask example.com."
  6. The DNS server reaches out to the customer's DNS servers — which are authoritative and actually hold the records.
  7. The authoritative DNS server returns the answer — for example, the IP address for www.example.com.
  8. The recursive DNS server returns this IP to the browser, and now you can see the contents of example.com.

Two Types of DNS Servers

Type Role
Recursive (Non-Authoritative) The DNS server in the middle — queries other servers on your behalf.
Authoritative The servers on the right — they actually hold the records for a domain.

Key point: The servers on the right are authoritative and not recursive, whereas the DNS server in the center is recursive.

1.3 OCI Domain Name System Capabilities

OCI provides a DNS service with the following capabilities:

  • Create and manage DNS zones — including zones your company owns.
  • After creating a zone, you can add records to it.
  • Allow OCI's edge network to handle your domain's DNS queries.
  • Import zone files — the service supports import in standard BIND zone data format, the industry-preferred zone file format (also supported by OCI DNS).

In the screenshot shown, a Public Zone was created with:

  • Zone type: Primary
  • Two associated records:
    • Name Server (NS) record
    • Start of Authority (SOA) record

1.4 Benefits of OCI Public DNS

  1. Consistently lowest query latency performance — queries are served via anycast from OCI's global commercial regions.
  2. Built-in DoS protection — highly resilient against outages and attacks.
  3. Industry-leading propagation time — ensures fast response to DNS changes.

2. DNS Service Components

This lesson explained the five core components used to build a DNS zone and make it accessible from the internet. A domain is a specific location or group of locations on the internet — a complete part of the DNS tree delegated to a user's control, such as oracle.com. A zone is a part of the DNS namespace that always includes a Start of Authority (SOA) record and a Name Server (NS) record. A label is prepended to the zone name (or separated by a period) to form a subdomain — for example, www in www.oracle.com. A child zone is an independent subdomain with its own SOA and NS records; the parent zone must contain an NS record that refers DNS queries to the child zone's nameservers. Finally, resource records contain specific domain information for a zone — such as A records (mapping a domain name to an IP address), AAAA records (IPv6 addresses), and MX records (mail server information). Together, these components form the structure that makes DNS zones functional and accessible on the internet.

2.1 Overview

This lesson covers the components used to build a DNS zone and make it accessible from the internet. There are five key components to understand.

2.2 Domain

A domain can be thought of as a specific location or a group of locations on the internet as a whole.

  • Example: oracle.com
  • It is a complete part of the DNS tree that has been delegated to a user's control.

2.3 Zone

A zone is a part of the DNS namespace.

  • Whenever you create a zone, it will contain:
    • A Start of Authority (SOA) record
    • A Name Server (NS) record

2.4 Label

Labels are prepended to the zone name, or they can be separated by a period to form the name of a subdomain.

  • Example: In www.oracle.com, the www is the label.

2.5 Child Zone

A child zone is fundamentally an independent subdomain.

  • Because it is independent, it has its own Start of Authority (SOA) and Name Server (NS) records.
  • Important: The parent zone of a child zone must contain a Name Server (NS) record that refers DNS queries to the nameservers responsible for the child zone.

2.6 Resource Records

Resource records contain specific domain information for a particular zone.

Examples:

Record Type Purpose
A record Contains an IP address for a domain name
AAAA record Contains an IPv6 address for a domain name
MX record Contains information about the mail server for a particular domain

3. Zones

This lesson introduced the concept of a DNS zone, which is the portion of the DNS namespace managed by a specific organization or administrator — essentially an administrative space that enables granular control over DNS components like authoritative nameservers. A zone holds trusted DNS records (such as A, AAAA, MX, and CNAME records) that reside on OCI nameservers. When you create a zone, two records are generated automatically: a Nameserver (NS) record and a Start of Authority (SOA) record. OCI offers two types of zones: a Public Zone, which holds trusted DNS records on OCI nameservers for public resolution, and a Private Zone, which contains domain names that resolve DNS queries for private addresses within the Virtual Cloud Network (VCN). This distinction allows organizations to manage both internet-facing and internal DNS resolution within OCI.

3.1 What Is a Zone?

A DNS zone is the portion of the DNS namespace that is managed by a specific organization or administrator.

Think of it as an administrative space that allows for more granular control of DNS components — such as the nameservers, specifically authoritative nameservers.

3.2 What Does a Zone Hold?

A DNS zone holds trusted DNS records. These records reside on OCI nameservers.

Examples of DNS records:

  • A record
  • AAAA record
  • MX record
  • CNAME record
  • And others

3.3 Records Created Automatically

Whenever you create a zone, two records are created automatically:

  1. Nameserver (NS) record — associated with the zone
  2. Start of Authority (SOA) record

3.4 Types of Zones in OCI

OCI supports two types of zones:

Zone Type Purpose
Public Zone Holds trusted DNS records that reside on OCI nameservers
Private Zone Contains domain names that resolve DNS queries for private addresses within the Virtual Cloud Network (VCN)

4. Public DNS Zones

This lesson explained public DNS zones, which are used to resolve host names on the internet and hold trusted DNS records residing on OCI nameservers. Implementing a public DNS zone involves three steps: first, create the public DNS zone, which automatically generates Name Server (NS) and Start of Authority (SOA) records; second, delegate the zone to make it accessible from the internet — this involves copying the NS records created in OCI and updating them in your domain registrar's DNS panel (such as GoDaddy), replacing the registrar's default nameservers; and third, add records to the zone, where each record type contains RDATA (record data), such as an IP address for an A record. The zone must be created with the same name as your purchased domain (e.g., create a public DNS zone for abc.com after purchasing that domain). Until the zone is delegated, it remains inaccessible from the internet — making delegation the critical step that connects your OCI-hosted zone to the global DNS system.

4.1 What Is a Public DNS Zone?

A public DNS zone is used to resolve host names on the internet. As the name suggests, "public" means it resolves host names on the internet.

There are two types of DNS zones:

  1. Public DNS zones (covered in this lesson) — resolve host names on the internet.
  2. Private DNS zones — resolve host names privately (covered elsewhere).

Because a public DNS zone is still a zone, it holds trusted DNS records, and these records reside on OCI nameservers.

4.2 The Three Steps to Implement a Public DNS Zone

Step 1: Create a Public DNS Zone

When you create a public DNS zone, it results in the automatic creation of:

  • Name Server (NS) records
  • Start of Authority (SOA) record

The list of nameservers generated here is used in Step 2.

Step 2: Delegate the Zone

Delegation is what makes the hosted zone accessible from the internet. Until you delegate the zone, it is not accessible from the internet.

How delegation works — an example:

  1. Assume you purchased the domain samvit.site from GoDaddy (a domain name registrar).
  2. When you purchased the domain, GoDaddy automatically provided you with a list of nameservers.
  3. To delegate the zone, you must first create a public DNS zone in OCI with the same name as your domain — in this case, samvit.site.
  4. Then, you copy the nameserver records that were created when you created the public DNS zone in OCI.
  5. You update these nameserver records in your domain registrar's DNS panel (e.g., GoDaddy) — replacing the original list provided by the registrar with the OCI nameservers.

Key point: The delegation step is performed in the registrar's DNS panel, not in OCI.

Step 3: Add Records to the Zone

Once the zone is delegated, you can add records to the zone.

  • Every record type contains information called RDATA (record data).
  • Example: For an A record, the RDATA is an IP address.

5. Private DNS Zones

This lesson covered private DNS zones in OCI, starting with the three DNS name resolution options available in a VCN: the default Internet and VCN Resolver (which resolves public hostnames and hostnames of instances within the same VCN), a custom resolver (allowing you to choose a DNS server over the internet, in your VCN, or on-prem), and the newer Private DNS service. Private DNS extends hostname resolution within VCNs, across VCNs, and between VCNs and on-premises or other private networks — a capability that previously required custom solutions. The lesson then detailed the resources associated with private DNS zones: the zone (which holds DNS data), the view (a collection of zones, each belonging to a single view), the resolver (which holds the configuration serving DNS responses within the VCN), private DNS records (supporting A, AAAA, and PTR records, among others), and the resolver endpoint (which sets up ingress and egress, consumes private IPs, and comes in two types — listening for queries from outside the VCN/OCI, and forwarding to redirect queries to other DNS servers). The most important takeaway is the hierarchy: Resolver → Views → Zones → Records, which determines how DNS queries are answered within a VCN. A practical on-prem-to-OCI example illustrated how the listener handles inbound queries from outside OCI, while the forwarder redirects outbound queries to external DNS servers.

5.1 DNS Options in a Virtual Cloud Network (VCN)

Before diving into private DNS zones, it's important to understand the DNS name resolution choices available for instances provisioned in a VCN.

Option 1: Internet and VCN Resolver (Default)

This is the default choice, and it provides two capabilities:

  • Internet Resolver – Lets instances resolve hostnames that are publicly published on the internet.
  • VCN Resolver – Lets instances resolve hostnames of other instances in the same VCN.

Example: If you have a VCN with two subnets, and an instance in each (Instance A and Instance B), Instance A can reach Instance B using its fully qualified domain name — because the VCN resolver handles this by default.

Option 2: Custom Resolver

With a custom resolver, you can select a DNS server of your choice. Multiple options exist:

  1. A DNS server available over the internet.
  2. A custom DNS server in your VCN.
  3. A custom DNS server in your on-premises network.

Option 3: Private DNS (New)

Oracle launched a service called Private DNS, which is now the third option. It provides hostname resolution:

  • Within the VCN (just like the VCN resolver).
  • Across VCNs — previously, this required a custom solution.
  • Between a VCN and your on-premises network (or any other private network).

5.2 Private DNS Zones

Private DNS provides hostname resolution within VCNs, between VCNs, and between VCN and on-prem networks.

Resources Associated with Private DNS Zones

  1. Private DNS Zone The zone itself contains the DNS data.

  2. Private DNS View A private DNS view is a collection of private DNS zones. Each private DNS zone can belong to a single view.

  3. Private DNS Resolver The private DNS resolver contains the configuration that serves responses to DNS queries within the VCN.

Hierarchy within the resolver:

  • The resolver contains views.
  • Each view contains zones.
  • Each zone contains record data.

Key insight: The resolver holds the configuration that serves responses to DNS queries within the VCN. The views on the resolver decide the zone and record data applicable for the response.

  1. Private DNS Records Private DNS zones support a number of DNS record types:
Record Type Mapping
A Hostname to IPv4
AAAA (Quad A) Hostname to IPv6
PTR (Pointer) Reverse DNS mapping
  1. Private DNS Resolver Endpoint The private DNS resolver endpoint sets up ingress and egress in the VCN.
  • It consumes private IP addresses.
  • A corresponding VNIC is created for each resolver endpoint.

Two types of resolver endpoints:

Endpoint Type Purpose
Listening (Listener) Responds to queries from outside the VCN or OCI
Forwarding (Forwarder) Uses rules to redirect queries to different DNS servers

How the Resolver Hierarchy Fits Together

Remember: Resolver → Views → Zones → Records

The resolver contains the information that serves responses to DNS queries within the VCN.

Practical Example: On-Prem to OCI Resolution

Imagine an OCI VCN with a subnet containing a listener and a forwarder. An on-premises network is connected via Site-to-Site VPN (with CPE on-prem and DRG on the VCN side).

  • Scenario 1: An on-prem VM wants to resolve the hostname of a VM running in OCI.

    • → The listener comes into action, listening to queries from outside OCI.

  • Scenario 2: An OCI VM wants to resolve the address of an on-prem VM.

    • → The request is sent to the forwarder endpoint, which redirects queries to different DNS servers (e.g., a DNS server on-prem).

6. Private Views

This lesson explained private views in OCI, which are essentially collections of private DNS zones used to logically group zones together. The key constraint is that a zone can belong to only a single view — if a zone like samvit.com is part of one private view, it cannot be part of another. Every VCN has a resolver with a default view that is always present, and you can add zones to it. In addition to the default view, you can create and attach additional views to the resolver, with the goal of making the zones in those views resolvable within the VCN. While a zone can belong to only one view, a single view can be used by multiple resolvers. The overarching purpose of private views is to enable sharing of private DNS data across VCNs and to control which DNS zones are resolvable within a given VCN, providing flexibility and granularity in private DNS management.

6.1 What Is a Private View?

A private view is a collection of private DNS zones. You can think of it as a way to logically group a set of private DNS zones together.

Example: A private view could contain zones such as samvit.com and others.

6.2 Key Rules

Rule 1: A Zone Belongs to Only One View

A zone — for example, samvit.com — can belong to only a single view.

  • If samvit.com belongs to Private View A, it cannot belong to Private View B.
  • This is not possible.

Rule 2: Every VCN Resolver Has a Default View

When you create a VCN, the VCN has a resolver, and this resolver has a default view. This default view is always there.

  • You can add zones to the default view.
  • You can also create and attach another view to the resolver, in addition to the default view.

Why Attach Additional Views?

The purpose is that the zones that are part of a view should be resolvable in the VCN — because ultimately, zones contain records that need to be resolved.

Summary of Key Points

Concept Details
Private view A collection of private DNS zones
Zone membership A zone can belong to only one view — never multiple views
Default view Every VCN resolver has one; it is always present
Additional views You can create and attach additional views to a resolver
View usage One view can be used by multiple resolvers
Purpose Ensure zones are resolvable in the VCN; share private DNS data across VCNs

7. HTTP redirects

This lesson introduced HTTP redirects, a supporting service in DNS management that lets you redirect HTTP traffic to another URL. Four scenarios were covered: redirecting all HTTP traffic for an entire zone to another zone (e.g., test.net → test.com), redirecting a specific subdomain to an HTTP URL, redirecting a subdomain to a URL with a port number (e.g., http://sample.test.net:8080), and permanently redirecting a domain name using a 301 response code — which is especially useful when a domain has been deprecated, as it informs search engines and browsers how to handle the change. For any redirect to work, you must also create the relevant CNAME record in the DNS zone. When configuring a redirect in the console, you select a zone and specify the domain/subdomain plus target details including protocol, host, port, and optionally path and query — along with the response code (301 for permanent, 302 for temporary). The console also offers an option to automatically create the required DNS record, simplifying the setup of HTTP redirects within OCI DNS.

7.1 What Are HTTP Redirects?

The DNS service lets you redirect HTTP traffic to another URL. This is useful when you want traffic hitting one domain or subdomain to be sent somewhere else.

Example: A company owns both test.net and test.com. Using HTTP redirect, you can redirect all HTTP traffic for test.net and send it to test.com.

Note: This is a one-to-one mapping.

7.2 Four HTTP Redirect Scenarios

Scenario 1: Redirect All HTTP Traffic for a Zone

Redirect all HTTP traffic for an entire zone (e.g., test.net) to another zone (e.g., test.com).

Scenario 2: Redirect a Specific Subdomain to an HTTP URL

Redirect a specific subdomain to an HTTP URL.

Scenario 3: Redirect a Subdomain to a URL with a Port Number

Redirect a subdomain — for example, example.test.net — to a URL with a port number, such as http://sample.test.net:8080.

Scenario 4: Permanently Redirect a Domain Name

Use this when a domain name has been deprecated. You typically want to display a 301 response code.

Benefit: Permanently redirecting a domain name informs search engines and browsers what to do with the information.

7.3 Required DNS Record

After creating the redirects, you must also create the relevant DNS record — specifically a CNAME record.

Important: You must add the CNAME record to the DNS zone for the redirect to work successfully.

7.4 Configuring HTTP Redirects (Console View)

When configuring an HTTP redirect, you provide:

  • Zone – Select the zone.
  • Domain and Subdomain – Specify the source.
  • Target details:
    • Protocol
    • Host
    • Port
    • Path (optional)
    • Query (optional)

Response Codes

Code Meaning
301 Moved Permanently
302 Temporary redirect

There is also an option in the console that helps you create the DNS record in the DNS zone automatically.

8. Traffic Management

This lesson introduced traffic management, a key component of the OCI DNS service that sits between users making DNS queries and the endpoints that serve them, providing intelligent responses based on conditions rather than simply returning static records. Unlike a regular public DNS zone (which holds records like A, AAAA, and MX), traffic management defines conditions — such as the user's geographical location or the health of endpoints — and routes traffic accordingly to different answer pools. The lesson covered four components: steering policies (which contain rules/logic for intelligently serving DNS answers), attachment (linking a steering policy to a public DNS zone, after which DNS responses are constructed from the steering policy rather than the zone's records), rules (guidelines that filter answers based on DNS request properties like geolocation or endpoint health), and answers (answer pools containing the records provided as responses — the actual endpoints). OCI supports multiple steering policy types — failover, load balancer, geolocation, ASN, and IP prefix — each defining different logic for how queries are answered. In the flow, a user's query goes through a recursive server to OCI DNS, where the steering policy is applied, and the appropriate endpoint is returned based on the defined logic.

8.1 What Is Traffic Management?

Traffic management is a key component of the OCI DNS service offering. It sits between the user (making a DNS query) and the endpoints on the other side.

Example: A user tries to access a website like abc.com. This operation can be thought of as a DNS query. The traffic management service sits in between and serves intelligent responses.

How It Differs from a Regular Public DNS Zone

A regular public DNS zone can have various record types — MX records, AAAA records, A records, etc. — and it simply returns those records.

Traffic management, however, provides intelligent responses to DNS queries. It does this by defining conditions and, based on those conditions, returning an appropriate answer to the DNS query.

What Kinds of Conditions?

Conditions can include:

  • Geographical location of the user trying to access the website
  • Health of the endpoints

Based on the condition, traffic can be sent to Endpoint 1, Endpoint 2, or Endpoint 3.

Policy Types (Preview)

Different traffic management steering policy types exist, such as:

  • Load balancing traffic among endpoints
  • Failover policies — send traffic to Endpoint 1, but if it's unavailable, send it to Endpoint 2

These are covered in the next lesson.

8.2 Traffic Management Components

1. Steering Policies

Steering policies contain rules that help intelligently serve DNS answers. Think of them as the logic behind traffic management.

2. Attachment

Attachment means linking a steering policy to a public DNS zone.

Important: When you link a steering policy to a public DNS zone, the DNS response is constructed from the steering policy — not from the records you created in the public DNS zone.

Even though the public DNS zone has its own records, the DNS response always comes from the steering policy.

3. Rule

A rule is a guideline that steering policies use to filter answers based on the DNS request and its properties.

Examples of rule properties:

  • Geolocation
  • Health of the endpoint

4. Answers

When you create a traffic management steering policy, there is a concept of an answer pool. These answer pools contain the records that will be provided as answers.

In the earlier example, the endpoints (Endpoint 1, Endpoint 2, Endpoint 3) are actually answer pools.

8.3 How It Flows

  1. A user makes a request (DNS query).
  2. The query goes to a recursive server.
  3. The recursive server reaches OCI DNS, where traffic management steering policies are applied.
  4. Based on the defined logic, an intelligent response is returned — directing the user to the appropriate endpoint/answer pool.

8.4 Steering Policy Types

OCI supports several steering policy types, including:

  • Failover policy
  • Load balancer policy
  • Geolocation steering policy
  • ASN steering policy
  • IP prefix steering policy

The logic you define in the steering policy determines which endpoint is served for a given query.

9. Traffic Management-Policy Types

This lesson covered the five traffic management steering policy types in OCI — Failover, Load Balancer, Geolocation, ASN Steering, and IP Prefix — each defining different logic for how DNS queries are answered. Failover prioritizes a primary endpoint, with health checks automatically redirecting traffic to a secondary when the primary becomes unhealthy. Load Balancer distributes DNS traffic across endpoints using configurable weights (e.g., 50/50 or custom ratios like 10/90), falling back to healthy endpoints when needed. Geolocation steers traffic based on the end user's physical location, ASN Steering routes based on Autonomous System Numbers, and IP Prefix Steering routes based on the IP prefix of the originating query. The lesson then explored practical use cases: automated failover between primary and secondary servers; cloud migration using weighted load balancing to gradually shift traffic (e.g., starting at 10% and increasing); load balancing and scaling across many servers; multi-environment steering — since traffic management is agnostic, it can direct traffic to OCI resources, other clouds, on-premises data centers, or any publicly exposed resource; worldwide geolocation steering for dividing global users into geographic regions (e.g., by country); canary testing using IP Prefix steering to serve different responses to internal vs. external users; and zero-rating services using ASN steering to direct preferred ASNs to free resources while sending other traffic to paid resources. Together, these policies enable intelligent, condition-based DNS traffic management tailored to a wide range of business and technical needs.

9.1 The Five Traffic Management Steering Policies

OCI offers five steering policy types:

  1. Failover
  2. Load Balancer
  3. Geolocation
  4. ASN Steering
  5. IP Prefix

9.2 Failover Policy

Use this when you have multiple endpoints (e.g., two) and want to prioritize the order in which answers are served.

How it works:

  • You designate one endpoint as primary and the other as secondary.
  • OCI health checks monitor both endpoints.
  • If both are healthy, DNS traffic is steered to the primary.
  • If the primary goes down (or its answer is unhealthy), traffic is automatically sent to the secondary.

9.3 Load Balancer Policy

Use this to distribute DNS traffic across multiple endpoints.

How it works:

  • You can configure weights for each endpoint.
    • 50/50 → traffic distributed evenly.
    • Custom (e.g., 10/90) → 10% to Endpoint 1, 90% to Endpoint 2.
  • If one endpoint becomes unhealthy, traffic is sent to the healthy endpoint.

Note: This is about DNS traffic distribution.

9.4 Geolocation Steering

These policies distribute DNS traffic based on where the end user is located.

Example:

  • A user in a particular country → routed to a specific endpoint.
  • A user in Australia → routed to a separate endpoint.

9.5 ASN Steering

Steers traffic based on ASN (Autonomous System Numbers).

  • A DNS query originating from a specific ASN can be steered to a specific endpoint.

9.6 IP Prefix Steering

Enables customers to steer DNS traffic based on the IP prefix of the originating query.

9.7 Use Cases for Traffic Management Steering Policies

Automated Failover

Provide automated failover between primary and secondary servers.

Cloud Migration

Traffic Management Steering Policies support weighted load balancing, which is useful for migrations:

  • Steer a small amount of traffic (e.g., 10%) to a new resource in the cloud to verify it works as expected.
  • Gradually increase the ratio until you're comfortable fully migrating all DNS traffic to the cloud.

Load Balancing and Scaling

Configure load balancing across many servers or scale as needed.

Multi-Environment and Multi-Cloud Steering

Traffic management is an agnostic service — you can steer traffic to:

  • OCI resources
  • Any publicly exposed resources
  • Other cloud service providers
  • On-premises data centers

Only requirement: The resource must be publicly exposed (resolvable on the internet).

Worldwide Geolocation Steering

Divide your global user base into geographically defined regions — for example, at the country level — and steer customers to specified resources based on their physical location.

Canary Testing (via IP Prefix Steering)

Configure policies to serve different responses for internal users versus external users.

Zero-Rating Services (via ASN Steering)

Use ASN steering based on the originating enterprise or mobile operator:

  • Preferred ASNs → directed to free resources.
  • All other traffic → directed to paid resources.