Automate DNS Private Zone Entries with OCI Functions

In some situations, customers want to customize the DNS settings for a VCN and, instead of oraclevcn.com, use a different domain for VCN-connected hosts. The DNS Private Zone feature within Oracle Cloud Infrastructure's (OCI) DNS service allows the users to expand the capabilities of the built-in VCN DNS resolver, so they can use custom domain names for the resources within the VCNs. This architecture expands on the solution described in the blog post Use Case - OCI VCN Custom DNS (accessible from the Explore More section, elsewhere in this reference architecture) by using OCI Events and Functions to automate DNS zone entries management.

Architecture

This architecture describes how you can use OCI Functions and Events to automatically populate a private zone with DNS entries, reducing the need for manual updates and potential errors. You can then use Events to capture new instance creation requests at the compartment level, then trigger the Add DNS record function to collect instance metadata, add a DNS record to the private DNS zone, and finally confirm record insertion by updating instance free-form tags. When the instance is terminated, the event triggers the Remove DNS record function to delete the associated DNS record.

The following diagram illustrates this reference architecture.


Description of dns_private_zones.png follows
Description of the illustration dns_private_zones.png

dns-private-zones-oracle.zip

This architecture has the following components:
  • Region

    An Oracle Cloud Infrastructure region is a localized geographic area that contains one or more data centers, called availability domains. Regions are independent of other regions, and vast distances can separate them (across countries or even continents).

  • Compartment

    Compartments are cross-region logical partitions within an Oracle Cloud Infrastructure tenancy. Use compartments to organize your resources in Oracle Cloud, control access to the resources, and set usage quotas. To control access to the resources in a given compartment, you define policies that specify who can access the resources and what actions they can perform.

  • Availability domains

    Availability domains are standalone, independent data centers within a region. The physical resources in each availability domain are isolated from the resources in the other availability domains, which provides fault tolerance. Availability domains don’t share infrastructure such as power or cooling, or the internal availability domain network. So, a failure at one availability domain is unlikely to affect the other availability domains in the region.

  • Virtual cloud network (VCN) and subnets

    A VCN is a customizable, software-defined network that you set up in an Oracle Cloud Infrastructure region. Like traditional data center networks, VCNs give you complete control over your network environment. A VCN can have multiple non-overlapping CIDR blocks that you can change after you create the VCN. You can segment a VCN into subnets, which can be scoped to a region or to an availability domain. Each subnet consists of a contiguous range of addresses that don't overlap with the other subnets in the VCN. You can change the size of a subnet after creation. A subnet can be public or private. Security list For each subnet, you can create security rules that specify the source, destination, and type of traffic that must be allowed in and out of the subnet.

  • NAT gateway

    The NAT gateway enables private resources in a VCN to access hosts on the internet, without exposing those resources to incoming internet connections.

  • Service gateway

    The service gateway provides access from a VCN to other services, such as Oracle Cloud Infrastructure Object Storage. The traffic from the VCN to the Oracle service travels over the Oracle network fabric and never traverses the internet.

  • Private DNS zone

    Private DNS allows you to use your own private DNS domain names and fully manage the associated zones and records to provide hostname resolution for your applications running within and between virtual cloud networks (VCNs), as well as your on-premises or other private network.

  • Oracle Cloud Infrastructure Events

    OCI Events enables you to create automation based on the state changes of resources throughout your tenancy. The emitted events can be filtered with the help of Rules and then processed as part of an Action in other OCI services (Notification, Streaming, Functions).

  • Oracle Functions

    With Oracle Functions, developers can take advantage of a fully managed, multi-tenant, highly scalable, on-demand, Functions-as-a-Service platform to write and execute code in the cloud without having to manage the underlying infrastructure. In this architecture, the Functions are Add DNS record and Remove DNS record.

  • VCN DNS Resolver

    The VCN DNS resolver allows VCN-attached instances to resolve hostnames (which you can assign) of other instances in the same VCN. You can extend the default capabilities of the VCN DNS resolver by attaching private zones to the VCN private view.

Recommendations

Use the following recommendations as a starting point when automating DNS private zone entries with OCI Functions. Your requirements might differ from the architecture described here.
  • VCN

    When you create a VCN, determine the number of CIDR blocks required and the size of each block based on the number of resources that you plan to attach to subnets in the VCN. Use CIDR blocks that are within the standard private IP address space.

    Select CIDR blocks that don't overlap with any other network (in Oracle Cloud Infrastructure, your on-premises data center, or another cloud provider) to which you intend to set up private connections.

    After you create a VCN, you can change, add, and remove its CIDR blocks.

    When you design the subnets, consider your traffic flow and security requirements. Attach all the resources within a specific tier or role to the same subnet, which can serve as a security boundary.

    Use regional subnets.

  • Security

    Use Oracle Cloud Guard to monitor and maintain the security of your resources in Oracle Cloud Infrastructure proactively. Cloud Guard uses detector recipes that you can define to examine your resources for security weaknesses and to monitor operators and users for risky activities. When any misconfiguration or insecure activity is detected, Cloud Guard recommends corrective actions and assists with taking those actions, based on responder recipes that you can define.

    For resources that require maximum security, Oracle recommends that you use security zones. A security zone is a compartment associated with an Oracle-defined recipe of security policies that are based on best practices. For example, the resources in a security zone must not be accessible from the public internet and they must be encrypted using customer-managed keys. When you create and update resources in a security zone, Oracle Cloud Infrastructure validates the operations against the policies in the security-zone recipe, and denies operations that violate any of the policies.

  • Cloud Guard

    Clone and customize the default recipes provided by Oracle to create custom detector and responder recipes. These recipes enable you to specify what type of security violations generate a warning and what actions are allowed to be performed on them. For example, you might want to detect Object Storage buckets that have visibility set to public.

    Apply Cloud Guard at the tenancy level to cover the broadest scope and to reduce the administrative burden of maintaining multiple configurations.

    You can also use the Managed List feature to apply certain configurations to detectors.

  • Security zones

    Security zones enforce security postures on OCI compartments and prevent actions that could weaken a customer's security posture. You can apply security zone policies to various cloud infrastructure types (network, compute, storage, database, and so on) to ensure that cloud resources stay secure and to prevent security misconfigurations.

  • Network security groups (NSGs)

    You can use NSGs to define a set of ingress and egress rules that apply to specific VNICs. We recommend using NSGs rather than security lists, because NSGs enable you to separate the VCN's subnet architecture from the security requirements of your application. You can use NSGs to define a set of ingress and egress rules that apply to specific VNICs. We recommend using NSGs rather than security lists, because NSGs enable you to separate the VCN's subnet architecture from the security requirements of your application.

  • Load balancer bandwidth

    While creating the load balancer, you can either select a predefined shape that provides a fixed bandwidth, or specify a custom (flexible) shape where you set a bandwidth range and let the service scale the bandwidth automatically, based on traffic patterns. With either approach, you can change the shape at any time after creating the load balancer.

Considerations

When provisioning the infrastructure, consider the following:

  • Deployment

    The user deploying the architecture must have administrative privileges.

  • DNS zone

    The configured DNS zone must be in the same compartment as the selected subnet.

Deploy

The Terraform code for this reference architecture is available as a sample stack in Oracle Cloud Infrastructure Resource Manager. You can also download the code from GitHub, and customize it to suit your specific requirements.

  • Deploy using the sample stack in Oracle Cloud Infrastructure Resource Manager:
    1. Click Deploy to Oracle Cloud.

      If you aren't already signed in, enter the tenancy and user credentials.

    2. Select the region where you want to deploy the stack.
    3. Follow the on-screen prompts and instructions to create the stack.
    4. After creating the stack, click Terraform Actions, and select Plan.
    5. Wait for the job to be completed, and review the plan.

      To make any changes, return to the Stack Details page, click Edit Stack, and make the required changes. Then, run the Plan action again.

    6. If no further changes are necessary, return to the Stack Details page, click Terraform Actions, and select Apply.
  • Deploy using the Terraform code in GitHub:
    1. Go to GitHub.
    2. Clone or download the repository to your local computer.
    3. Follow the instructions in the README document.

Explore More

Learn more about DNS private zones in OCI, see the following resources:.

Review these additional resources:

Acknowledgments

Author: Andrei Ilas