DNS

With default DNS, the domain is derived from the delegated subnet and VNet names, whether the deployment uses a Network Anchor or selects the VNet and delegated subnet directly.

Oracle AI Database@Azure generates each label by using the oci prefix followed by the first 11 normalized characters of the corresponding Azure name:

oci<first-11-characters-of-delegated-subnet>.oci<first-11-characters-of-vnet>.oraclevcn.com

Hyphens, underscores, and periods are removed during label generation. The first 11 characters are taken after this normalization.

For example:

Azure VNet and delegated subnet names are normalized and can be shortened when DNS domains are generated.

Long, similar VNet and delegated subnet names can therefore produce identical or overlapping oraclevcn.com domains.

Select VNet and delegated subnet names whose first 11 normalized characters distinguish the deployment, region, or availability zone. Put multiple distinguishing characters near the beginning of each name because characters beyond that limit don't appear in the generated DNS labels. For example, oradb-production-eastus and oradb-production-westus both begin with the normalized value oradbproduc. Names such as eus1-oradb-production and wus1-oradb-production preserve the regional identifier in the generated labels.

The Exadata Host name prefix affects the generated host and SCAN names, but it doesn't affect the generated domain or its forwarding path.

Before provisioning, check that the first 11 normalized characters of the selected VNet and delegated subnet names don't duplicate the corresponding values for another deployment. Then verify each generated Host domain name and SCAN FQDN after provisioning. Forward the complete generated domain, such as ocidbsubnet.ociexamplevnet.oraclevcn.com, to the endpoint that serves all its records. If domains overlap, use distinct custom subdomains or a central DNS authority.

A database node name follows this general structure:

<hostname-prefix>-<generated-string><node-number>.<subnet-domain-label>.<vcn-domain-label>.oraclevcn.com

The service adds the generated node suffix so that each node has a distinct name. Applications typically connect by using the SCAN name or another FQDN supplied in the database connection details. The DNS resolver resolves the node names and returns the SCAN virtual IP addresses for the SCAN name.

In the Azure portal, start the Exadata VM cluster creation flow, leave Custom DNS unselected, and provide a Host name prefix, such as oradb. If you use resource and network anchors, select them in the flow. Check the generated Host domain name and Host and domain URL before creating the cluster.

Choose the custom domain and its Network Anchor before provisioning.

Use a distinct delegated subdomain for each Network Anchor or availability-zone deployment, such as az1.eastus.db.example.com. Each suffix must lead to an endpoint that can resolve every record in that zone.

Review the naming limits for Exadata VM clusters and custom DNS zones.

Existing databases retain the endpoint names assigned during provisioning, including names that don't contain the Azure region label.

Continue to use the endpoint names supplied in the database details and client credentials.

For a private endpoint, the service creates two Azure Private DNS zones in the resource group that contains the VNet selected during provisioning.

This resource group can differ from the resource group that contains the Autonomous Database resource. One zone is named for the exact database endpoint under oraclecloud.com, and the other is named for the exact application endpoint under oraclecloudapps.com. Each zone contains an apex A record for the database private IP address and is linked to the selected VNet.

Link both zones to every additional VNet whose clients or DNS resolvers must resolve the endpoint names. The zones and an additional linked VNet don't need to be in the same resource group; DNS resolution depends on the VNet link. However, a VNet can't be linked to multiple Private DNS zone resources with the same or overlapping namespace, even when those zones are in different resource groups or subscriptions. If a VNet is already linked to another zone for the same namespace, consolidate the required records into one zone or use DNS forwarding instead.

For clients outside the linked VNets, configure a DNS path to a resolver that can resolve both service-created Azure Private DNS zones.

This requirement can apply to clients in on-premises networks, other Azure VNets, or other clouds.

The following reference architecture diagram shows DNS resolution through a Network Anchor.

The Network Anchor groups the delegated subnet, vNICs, database resource, and DNS endpoints. DNS queries use UDP or TCP port 53, and responses return through the corresponding query path.

The diagram shows two independent DNS query paths. The upper path resolves an Oracle AI Database@Azure database name for a client in Azure. In the lower path, a database resource resolves a name hosted in Azure or an on-premises network.

A dedicated Network Anchor can provide a shared DNS transit path for database resources attached to other Network Anchors and for resources that don't support direct Network Anchor attachment.

The resource remains in its own service network and doesn't become managed by the hub Network Anchor. The customer configures private connectivity and DNS forwarding between the resource network and the DNS hub network.

Dedicated DNS hub Network Anchor. The database network and DNS hub network remain separate. Private connectivity and DNS resolver rules provide the resolution path between them.

For queries from a database resource to Azure or an on-premises network, the resolver in the database network forwards the selected domains to a listening endpoint in the DNS hub network. The DNS hub resolver then applies its forwarding rules and sends the queries through the Network Anchor forwarding endpoint to Azure DNS Private Resolver or another customer DNS service.

For queries from Azure or an on-premises network to a database resource, customer DNS forwards the database domain to the DNS hub listening endpoint. The DNS hub resolver then resolves the query from its private zones.

To resolve database domains hosted in other database VCNs, associate their private views with the DNS hub resolver. An attached private view makes its private zones available to the hub resolver without copying the DNS records. A private view can contain multiple zones and can be associated with multiple resolvers. Attach the private views that contain every database domain the hub must resolve. Azure and on-premises clients can then use the hub listening endpoint as the resolution path for those domains.

If a private view isn't attached to the hub resolver, configure a forwarding rule for the specific database domain that targets a reachable listening endpoint in the database network. This alternative requires private connectivity, routes, and security rules between the DNS hub and database networks. A database resource that doesn't support Network Anchors might require customer-managed OCI resolver endpoints and rules for this path.

The DNS hub design must meet these requirements:

• Configure supported private connectivity between each database network and the DNS hub network.
• Configure OCI route tables in both networks so that DNS traffic reaches the resolver endpoints through the private network path.
• On the database network forwarding endpoint OCI NSG, allow outbound UDP and TCP port 53 to the DNS hub listening endpoint. On the DNS hub listening endpoint OCI NSG, allow the corresponding inbound traffic from the database network forwarding endpoint.
• For every domain sent to the DNS hub, its resolver must have an attached private view containing the zone or a forwarding rule to a resolver that can answer for it.
• If the DNS hub resolves database domains for Azure clients, it must have access to all records for each domain through its attached private views or forward each distinct database domain to the resolver endpoint that serves it.