Private DNS Between OCI and On-Premises or Third-Party Cloud

The domain name system (DNS) translates human-readable domain names to machine-readable IP addresses. A DNS nameserver stores the DNS records for a zone and responds with answers to queries against its database.

The following lists OCI DNS concepts:

• A private DNS solution resolves hostnames for applications running within and across VCNs, as well as between OCI, on-premises, and third-party cloud environments.
• If a DNS query can't be resolved within OCI, it can be forwarded to on-premises networks or connected third-party clouds.
• OCI private DNS is regional—to resolve queries outside your region, you must configure DNS forwarding to the target region.

You can configure DNS query resolution at the following levels:

• VCN: DNS queries within a VCN are handled automatically by OCI’s standard VCN resolver, with no extra configuration needed.
• Region:
  • When you create a VCN, OCI creates a private view for that VCN. A private view is a group of private DNS zones.
  • When you create a subnet, OCI creates a private DNS zone for that subnet within the private view (VCN).
  • All resources with private IPs in a subnet are registered in its private DNS zone.
  • Some OCI resources (like Autonomous Transaction Processing databases with private endpoints) may create their own private DNS zones.

Hub-and-Spoke VCN Resource Resolver

The Associated Private Views feature in OCI allow a DNS resolver in one VCN (the hub) to resolve hostnames from other VCNs' private views (the spokes). This feature supports up to 50 VCN in a region. A Hub Resolver can access resource records throughout the region if spoke views are associated with the hub view.The following diagram shows associated spoke private views with Hub private views to enable the resolver in Hub VCN to resolve all resources in a region:

Description of the illustration hub-vcn-oci-resource-resolver.png

To enable resources in spoke VCNs to resolve hostnames outside their own VCN, forward their DNS queries to the listener endpoint in the hub VCN. The hub can resolve hostnames in all associated spoke VCNs because the private view for all spokes are associated with hub private view.

To implement this architecture, you need the following:

• DNS listener endpoint in the Hub VCN.
• DNS forwarding endpoint in Hub VCN to forward queries to external networks, such as on-premises or other clouds.
• DNS forwarding endpoint in each Spoke VCN.

If a spoke VCN does not have a DNS subnet, create one or select an appropriate existing subnet.

Tip:

Oracle recommends that you:

• Create a DNS subnet in the Hub VCN and place DNS endpoints there.
• Associate an NSG with each of endpoints using appropriate ingress and egress stateless rules. Stateless rules provide better response times, but stateful rules are also supported.

Resolver Rules

The following diagram shows example rules in private DNS resolvers that forward DNS requests to the Hub Listener endpoint, on premise DNS systems, or DNS systems in other clouds:

Description of the illustration dns-private-resolver-hub-listener.png

Note:

• Subnets for private DNS endpoints must be IPv4 only. You can't create a private DNS endpoint in an IPv6-enabled subnet.
• You can create custom private views and DNS zones with your own domain names, and associate them with a hub DNS resolver to resolve specific DNS names for your resources.