Delegating subdomains from OCI managed public DNS domains

One of OCI’s many services is the management of Public DNS zones. The service comes with many built-in features such as DDOS protection and Dynamic Traffic Steering. For more information please follow this link. In this blog entry we will discuss delegating child zones of an OCI managed public zone.

Child zone delegation

When we talk about delegation of a child zone or subdomain we need to split the discussion into two big categories: delegation to an external management system, such as another CSP or your own DNS system, and delegation to another OCI tenancy.

External management system

Delegation to an external management system is straight forward. You create a new record in OCI which is the subdomain and you add NS records to point to as many remote DNS systems as you want. Here is how it looks in the OCI Console:

After this, you will manage the subdomain from inside the remote system.

Another OCI tenancy

In OCI, each defined public zone must be unique so if you want to create a subdomain directly into another tenancy you will get an error as the main zone already exists in OCI, in the first tenancy. Fortunately, we have a way to make it work with OCI’s option to manage DNS records across tenancies. How does that work? You have to create IAM policies in both tenancies which will allow users in Tenancy 2 to create records in a child of a zone owned by Tenancy 1. The list of said policies are covered here. In the end, it will look like a pseudo delegation in Tenancy 1 where the subdomain has NS records pointing back to OCI’s Name Servers.

Putting the two options on a small diagram, it looks like this:

DEMO

Let’s to a quick demo on both use cases presented above. I have the domain oci-lab.cloud managed by an OCI tenancy. We will split the demo into 2 parts:
- Delegating the child zone azure.oci-lab.cloud to Azure’s public DNS service
- Delegating the child zone tenancy2.oci-lab.cloud to a second OCI tenancy

Azure delegation

The first step is to create the child zone in the Azure console. This will provide the Azure Public NS systems.

Next, go into the OCI Console, under DNS Management -> Zones and click the zone you want. Next, simply create the child zone with NS records, as below:

Don’t forget to Publish the changes.

And that’s it. Now let’s move to Azure and create a host called demo and test DNS resolution.

OCI Delegation

As discussed, we cannot simply input OCI’s NS system in the child zone. We need to create IAM policies in both tenancies, under the root compartment.

For the primary tenancy, where the actual public zone is onboarded, we need:

define tenancy ChildZoneTenancy as ocid1.tenancy.oc1..aaaaaaaamy3a46ljb5gdtruftfg7xtuatc5ymgeob3sivuuao34sjbx3tk3q    
define group ChildZoneGroup as ocid1.group.oc1..aaaaaaaaqr5hyqposigh7lqqnp52fp6eoqm7npbut6gt6pqbiwgdlh6ersda    
admit group ChildZoneGroup of tenancy ChildZoneTenancy to manage dns-records in tenancy where all {target.dns-zone.name = 'oci-lab.cloud', target.dns-record.type = 'NS', target.dns-domain.name = 'tenancy2.oci-lab.cloud'}    
admit group ChildZoneGroup of tenancy ChildZoneTenancy to associate dns-records in tenancy with dns-zones in tenancy ChildZoneTenancy

Note that you need the OCID of the second tenancy and the OCID of an IAM group (from the second tenancy) which will handle DNS records.

For the second tenancy, which will host the child zone, we need:

define tenancy ParentZoneTenancy as ocid1.tenancy.oc1..aaaaaaaaa3qmjxr43tjexx75r6gwk6vjw22ermohbw2vbxyhczksgjir7xdq    
endorse group Administrators to manage dns-records in tenancy ParentZoneTenancy where target.dns-zone.name = 'oci-lab.cloud'
endorse group Administrators to associate dns-zones in tenancy with dns-records in tenancy ParentZoneTenancy

Once policies have been created in both tenancies you need to go to the second tenancy and add a new zone (tenancy2.oci-lab.cloud in our example).  

When you press create, OCI will also create the relevant entries in tenancy 1, under the main zone, as below:

You will now be able to add host records in tenancy2. Let’s test by creating a “demo” host entry in tenancy 2.

Notice that, in tenancy 2, the zone NS configuration is locked as those records are handled in tenancy 1.

And this concludes the demo!