Private Traffic Management - DNS Failover

April 26, 2023 | 4 minute read
Andrei Stoian
Master Principal Cloud Architect | North America Cloud Engineering
Text Size 100%:

In the last couple of months I worked together with some of my customers on a solution that will be able to provide traffic failover from one region to another region (DR scenario) for the private traffic running on IPSec VPN or FastConnect private VCs. In regards to private traffic running over IPSec and/or FastConnect, the DNS Traffic Management Steering Policies does not apply since it can only be used in conjunction with the public facing traffic.

There are multiple ways to achieve the goal, using a third party device on the customer side, using the OCI private DNS capabilities or a combination between the two.  In the next section we will analyze the OCI capabilities to provide the solution to our customers. Mostly, we will rely on the OCI Private DNS and Private Zones. 

A very simple networking scenario will reveal the configuration that needs to be in place for our private traffic to be switched from the Primary Region to the DR Region in a DR event. More than that, in some cases, the DR region should become the active without necessary having a DR event in place, just to make sure everything is well prepared. It will run on the DR Region for a period of time and after that the traffic will be switched back to the Primary Region.

Our networking scenario looks like in the below picture:

1

Our application sits behind two private LBaaS, one in the Primary Region at 10.0.0.160 and another one in the DR Region at 192.168.1.11. Both App VM1 serves the same application with the hostname webapp1.production.oci.com.

In a DR event or just after a planned migration to the DR region, the On-premises user at 10.120.0.117 should be able to access the application in couple of seconds.

Configuration

1. The Primary Region

In the Primary Region we will configure a private DNS listener in the designated DNS subnet:

2

A private zone will be created called oci.com and A entry matching webapp1.production.oci.com to 10.0.0.160 (floating private IP address of the Primary Region LBaaS) will be added:

3

The Private Zone created will be associated with a Private View that will be used by the Private DNS to respond to DNS queries received from On-premises for webapp1.production.oci.com:

4

2. The DR Region

Using the same logic as above, we need to define the DNS Listener and the Private Zone.

The DNS Listener:

5

The private zone called oci.com contains one A entry matching webapp1.production.oci.com to 192.168.1.11 (floating private IP address of the DR Region LBaaS):

6

And the associated private view:

7

Note 1: The On-premises DNS servers needs to point for *.production.oci.com received queries to the Primary DNS Listener at 10.0.2.6 and in case 10.0.2.6 does not respond, to  the DR Listener DNS at 192.168.1.34.

Configuration Test

1. Normal condition: Region 1 -> Primary, Region 2 -> DR; webapp1.production.oci.com served by 10.0.0.160

8

2. DR event or planned switchover the private traffic from Primary to DR: webapp1.production.oci.com served by 192.168.1.11

Note 2: To simulate this use case I just denied the DNS queries sent to the Primary DNS Listener so the next DNS Listener from the DR region to be used.

After clearing the browser cache:

9

3. Switchback to the Primary region -> normal condition:

10

The above configuration confirms that in a DR event scenario we can rely on the OCI Private DNS function for DNS failover.

Andrei Stoian

Master Principal Cloud Architect | North America Cloud Engineering


Previous Post

OCI IAM - The What, Why, and How of Passwordless Authentication

Praveen Hanchate | 10 min read

Next Post


Cleaning up your JIT-provisioned users

Christopher Johnson | 7 min read