Oracle has used its investment in Dyn to provide some of the best DNS and Edge capabilities in the market, one being active failover. Active failover ensures that sites and web services stay online if an issue occurs and works by automatically moving traffic off an unhealthy web server to a healthy secondary web server.

In this blog I talk about some of the advanced DNS services that Oracle Cloud Infrastructure (OCI) offers, and then walk through setting up active failover for your web application.

Introduction

OCI Domain Name System (DNS) service lets you create and manage your DNS zones. Traffic Management Steering Policies service serves as a critical component of OCI DNS, enabling you to configure policies to serve intelligent responses to DNS queries. Where standard DNS typically routes a domain to a single endpoint, OCI Traffic Steering Policies allow you to serve different endpoints based on logic that you define. The next section, describing the different policy types OCI offers, gives you an idea of the different logic that you can use to intelligently steer your DNS requests.

OCI Traffic Management Steering Policy types

  • Failover: Use OCI Health Checks to determine the health of answers. If the primary answer is determined to be unhealthy, DNS traffic is automatically steered to the secondary answer.
  • Load balancer: Traffic is distributed based on weights given to each endpoint. You can distribute traffic equally or give custom weights for ratio load balancing. OCI Health Checks are used, and traffic is automatically distributed to other endpoints if an endpoint is determined to be unhealthy.
  • Geolocation steering: Distributes DNS traffic to different endpoints based on the location of the user making the request. You can define geographic regions and route traffic to separate endpoints for each region.
  • ASN steering: Steers traffic based on autonomous system numbers (ASNs). DNS queries originating from a specific ASN or set of ASNs can be steered to a specific endpoint.
  • IP prefix steering: Steers DNS traffic based on the IP prefix of the originating query.

In this blog, we only set up failover, but you can read more about all the OCI Traffic Management Steering Policies in the documentation.

OCI and OCI DNS pricing

Oracle has made pricing as easy as possible. Each platform- and infrastructure-as-a-service (PaaS and IaaS) service consumes Universal Cloud Credits (UCCs), which means you’re not locked into using a specific service or subscription SKU. Another nice feature is the Pay As You Go (PAYG) purchase model. The PAYG model lets you quickly provision services with no upfront commitment. You pay for what you use as you use it.

OCI DNS also follows this model. Standard and traffic management DNS services have unit prices, and you pay based on the number of incoming queries that hit your zones. For more information, see the OCI DNS pricing page.

I bring up pricing because combining the PAYG purchase model with OCI DNS’s query-based pricing metric makes testing and migrating your zones to OCI DNS easy and cost-effective. For all our services, especially DNS, I strongly encourage you to spend 10 minutes and see how much you can save with OCI! Learn more about OCI’s different purchasing models and see our complete price list.

Prerequisites

To work with Traffic Management Steering Policies, you need an Oracle Cloud tenancy and a delegated zone in OCI DNS. If you need an OCI tenancy, you can sign up for a free trial. Oracle is not a registrar, so you need a domain if you don’t already have one. When you have your domain, you can follow my previous blog to create and delegate your OCI zone.

Scenario

My basic example consists of a web application being served in two different geographic regions:

  • Zone is elcaroydoc.com
  • Active endpoint is a web server in the Ashburn region. The website displays that we’re in Ashburn.
  • Failover endpoint is a web server in the Phoenix region. The website displays that we’re in Phoenix.
Figure 1: Architecture

 

Figure 2: Zone in OCI DNS

 

Figure 3: Ashburn (active) web server

 

Figure 4: Phoenix (failover) web server

 

Your setup is likely to differ. However, if you have an OCI DNS zone and at least two public facing endpoints, you’re good to go!

Creating an active failover policy

1. You can find Traffic Management Steering Policies under Networking and DNS Management.

Figure 5: Navigating to Traffic Management

 

2. Create a policy and input the following details:

  • Policy type: Failover
  • Policy name: A user-friendly name for the policy
  • Policy time to live (TTL): TTL for responses from the policy
Figure 6: Creating the policy, starting fields

 

3. Answer pools contain the group of answers served in response to DNS queries. My configuration has two answer pools, one for the web server in Ashburn (150.136.123.109) and one for the web server in Phoenix (129.146.161.240).

Each answer has the following inputs:

  • Name: User-friendly name for the answer. This name must be unique within the entire steering policy.
  • Type: The record type. Only A, AAAA, CNAME are supported.
  • RDATA: The record’s data
Figure 7: Creating the policy, answer pools

 

4. You can add multiple responses to an answer pool by clicking +Additional Answer. You can also add more answer pools by clicking +Additional Pool.

5. The pool priority is where you input the priority of a pool in the answer chain. The order of the pools, from top to bottom, is the order in which they’re evaluated. My primary pool is Ashburn, so I give this region the highest priority, followed by Phoenix.

Figure 8: Creating the policy, policy priority

 

6. Health checks monitor the availability of a target. If you have an existing health check, you can use that, but you can create one by selecting the Add New option.

  • Zone: elcaroydoc.com
  • Subdomain: failover

You can configure the following details for your health check. Click Show Advanced Options to view all.

  • Health check name: Name used for the health check
  • Interval: Period between health checks of the target
  • Protocol: Network protocol used to interact with your endpoint
  • Port (Optional): Port for the monitor to look at for a connection
  • Path (Optional): Specific path to be monitored
  • Method (Optional): HTTP method used for check
  • Timeout (Optional): Maximum time to wait for a reply before marking the health check as failed
  • Header name (Optional): Name of request header to send as part of health check
  • Header value (Optional): The data requested by the header

I use the following configuration in this example:

  • Health check name: BlogHealthCheck
  • Interval: 30 Seconds
  • Protocol: HTTP
  • Port (Optional): 80
Figure 9: Creating the policy, health check

 

7. Attached Domain is the domain name that you want to attach to the policy. I use the following configuration:

My policy is attached to the domain failover.elcaroydoc.com. If you want to attach this policy to multiple domains, click +Additional Attached Domain.

Figure 10: Creating the policy, attached domain

 

8. Finally, we can click Create Policy. A summary of the policy is displayed. Here, we can view policy information, policy narrative, policy answer data, and attached domains.

Figure 11: Policy summary, information

 

Figure 12: Policy summary, narrative

 

Figure 13: Policy summary, answer data

 

Figure 14: Policy summary, attached domains

 

Note on health checks

At the time of writing this blog, OCI automatically chooses vantage points (the location from which the health of the target is monitored) for your health check. If you want to configure these yourself, navigate to the health check by clicking its name in the policy and selecting Edit.

Figure 15: Health check vantage points

 

Note on attached domains

The policy that we created supersedes any previous entry that you have on your attached domains. You can see an “occluded by Steering Policy” message on the record.

Figure 16: Existing record occlusion

 

If your attached domain doesn’t have an existing entry, no extra records are added in the Console. The domain works as expected, but you don’t see any new records inserted into your zone.

Testing

Now that our policy is created, we can move to the fun part: Testing! We set Ashburn as our primary answer pool, so navigating to our domain yields the Ashburn web server.

Figure 17: Primary test success

 

It works! Now, I turn off the Ashburn web server.

Figure 18: Stopping the Ashburn web server

 

The first thing we see is that our health check to ash-webserver fails.

Figure 19: Ashburn health check failure

 

Our policy now starts steering responses to the Phoenix web server.

Figure 20: Policy failover to Phoenix

 

Our failover policy works as expected! If we start the Ashburn web server again, the health becomes healthy, and traffic is redirected back to Ashburn.

Conclusion

This blog touched on OCI’s DNS and Edge services and walked through setting up a simple active failover steering policy. Downtime of any kind can mean large revenue loss for companies. Configuring DNS failover ensures that your site stays online if an outage occurs. To read more about OCI’s DNS and Edge services, read the full documentation.

Oracle Cloud Infrastructure provides Enterprise features for developers to build modern cloud applications. Try the Oracle Cloud Free Tier with $300 credits for a 30-Day Free Trial. Free Tier also includes several “Always Free” services that are available for an unlimited time, even after your free credits expire.