The latest cloud infrastructure announcements, technical solutions, and enterprise cloud insights.

Configuring a Custom DNS Resolver and the Native DNS Resolver in the Same VCN

Sanjay Basu
Director, Emerging Technologies

One of the main objectives of the Oracle Cloud Infrastructure Blog is to serve as a forum for Cloud Solutions Architects and Product Managers to provide best practices, introduce new enhancements and offer tips & tricks for migrating and running your most important workloads in the Oracle Cloud. I'm a Solutions Architect myself, and my job is to engage with customers from the design phase all the way through to implementation. And because I've had the privilege of working on so many customer deployments we have visibility into issues and needs that span multiple accounts. The joy in this customer-vendor feedback loop comes in finding repeatable ways to solve issues, address needs and improve our service offerings.

In this blog post, I'll address a common issue that we've seen across a few customer accounts. This issue was caused by a configuration of the custom DNS resolver option in Oracle Cloud Infrastructure virtual cloud network (VCN) settings. This post explains the issue and how to resolve it.

I want to acknowledge the contributions from the following team members from our Cloud Support and Operation teams for the speedy resolution of these support requests:

  • Ankita Singh, Associate Solution Engineer
  • Saulo Cruz, Principal Member of Technical Staff


When customers configure a subnet within a VCN, they can choose Internet and VCN Resolver or Custom Resolver when configuring the DHCP options.

The default is Internet and VCN Resolver. If customers want to use their on-premises DNS servers (typically Microsoft Active Directory) across the FastConnect or IPSec VPN, they can select Custom Resolver. (For more information about the options, see the Networking documentation.) Generally, most enterprise customers put a DNS relay in the VCN within a shared services subnet. Typically the subnets within the VCN reflect this configuration. This works great for the applications. 

However, the issue starts when customers try to provision an Oracle Database Cloud Service (DBCS) instance by using a prebuilt Oracle Database image on a subnet that is using the Custom Resolver DHCP option. The typical error message is as follows: 

InvalidParameter - VCN RESOLVER FOR DNS AND DNS LABEL must be enabled for all subnets used to launch the specified shape

This message goes away when the customer changes the DNS in the DHCP options to Internet and VCN Resolver. But this change breaks other applications. This issue happens because of the recursive nature of the native VCN resolver.


We have found a workaround for this problem when the customer is using prebuilt DB images for a DBCS. The following diagram describes the architecture:

To implement this workaround, perform the following steps:

  1. Use Terraform to create the VCN and required subnets. For instructions, see the VCN Overview and Deployment white paper.
  2. Select the VCN in which the Database instance is required to be launched.
  3. Select the Internet and VCN Resolver DHCP option (which is the default option).
  4. Launch the Database instance and make the required configuration for the instance.
  5. After the Database instance is launched, go to the DHCP options, select Custom Resolver, and enter the customer’s DNS server IP address.
  6. Instantiate the DNS relay server (or Microsoft Active Directory) in the shared resources subnet (referred in the preceding diagram as the shared subnet). Keep the DHCP option as Internet and VCN Resolver (the default).
  7. In all other application subnets, select the Custom Resolver DHCP option and enter the customer’s DNS server IP address.

Note: Ensure that there is connectivity back to the customer DNS server or servers from the Oracle Cloud. Also ensure that you populate the DNS Label field when creating the VCN, or it will take the default value.

This configuration also works across VCNs in the same region or across regions. For more information, see the Automate Oracle Cloud Infrastructure VCN Peering with Terraform blog post.

Hopefully this post will help you avoid the rework involved in tearing down VCNs and subnets and re-creating them.

If you want more information about integration with Microsoft Active Directory, Infoblox, or Bluecat, please leave a comment.

Join the discussion

Comments ( 13 )
  • vlad savi Thursday, January 3, 2019
    Can we switch the databse configuration as well to reflect the new domain which is resolved by the custom resolver? That means changing /etc/hosts and TNS Listener config with the new FQDN... Is that supported by Oracle?

    Best Regards,
    Vlad Savi
  • Sanjay Basu Friday, January 11, 2019
    I have discussed your two questions in details with Ravi. He will be reaching out to you.

  • Ravi Vittal Friday, January 11, 2019
    Hi Vlad,

    Per our discussion this setup should work given some caveats which we discussed on the call.

    Ravi Vittal
  • Puneeth Friday, January 18, 2019
    Hi Sanjay,

    How do i create another DBCS instance in the same subnet which is modified to custom resolver?

    Will i be able to create another instance ? I am assuming it will give the same error message and how to overcome this

  • Ranga Sarvabhouman Saturday, March 23, 2019
    I have made changes to DBCS host after following this blog and have a document ready for sharing. please send a note to ranga.sarvabhouman@centroid.com is anyone is interested.

  • Sanjay Basu Saturday, March 23, 2019

    If you can email me the pdf of your document with your name. I can add that as link to this blog.

  • Umair Friday, April 12, 2019
    After creating A record, will my console also change?

    Customer after following the workaround, changed the DHCP option to "Custome Resolver", gave "A record" entry in the DNS for the HOST but still the hostname is not getting reflected to the UI.
  • Sanjay Basu Sunday, April 14, 2019
    The A record from customer DNS server will not be reflected in the Cloud console UI by default unless you are using the DNS API - https://docs.cloud.oracle.com/iaas/api/#/en/dns/20180115/
  • Nav Monday, April 29, 2019
    Is there any plan to fix the issue and give the functionality to have custom FQDN in DBCS? Changing the name of the DB and CRS resources post deployment is not a good option as customer expects fully automated PaaS solution.

  • Ranga Monday, April 29, 2019

    happy to share document, please send me you email address.
  • Sanjay Basu Monday, April 29, 2019
    Yes in the roadmap. I have emailed you.
  • Syed Abdul Aziz Syed Barey Thursday, June 6, 2019
    I have a customer that says

    When you provision a DBCS instance we have to disable the custom resolver in DHCP options within the VCN as provisioning DBCS requires OCI's DNS resolver.

    This impacts all environments within that VCN, effectively requiring downtime across the whole environment just to provision a DBCS instance as turning custom DNS off breaks application integration connectivity.

    When DHCP options are re-enabled it it takes 48+ hours for services to recover again.

    Is there a fix or a work around that would enable DBCS instances to be provisioned without disabling the custom resolver in DHCP options when provisioning DBCS instances?

    The downtime issue is not acceptable for a PRODUCTION environment, and would cause severe impact in lower environments when provisioning new instances.
  • Sanjay Basu Wednesday, June 12, 2019

    For this solution, we recommend to put DBCS or ExaCS in their own compartment and in their own VCN using VCN peering for connectivity to other application VCNs.

    We have launched our OCI DNS services - https://docs.cloud.oracle.com/iaas/Content/DNS/Concepts/dnszonemanagement.htm

    The OCI DNS Service should mitigate this situation and you don't need to implement the fix or workaround mentioned in this blog.

Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha