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:
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:
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.