DNS in Your Virtual Cloud Network

The Domain Name System (DNS) lets computers use hostnames instead of IP addresses to communicate with each other.

Choices for DNS in Your VCN

Following are the choices for DNS name resolution for the instances in your cloud network. You make this choice for each subnet in the cloud network, using DHCP options. This is similar to how you configure which route table and security lists are associated with each subnet. For more information, see DHCP Options.

You use the Domain Name Server DHCP option to specify the DNS Type for the associated subnet. If you change the option's value, either restart the DHCP client on the instance or reboot the instance. Otherwise, the change does not get picked up until the DHCP client refreshes the lease (within 24 hours).

VCN Resolver: Lets instances use hostnames (which you can assign) to communicate with other instances in the VCN. For more information, see About the DNS Domains and Hostnames.

By default, new VCNs you create use the Internet and VCN Resolver. If you're using the Networking API, this choice refers to the VcnLocalPlusInternet enum in the DhcpDnsOption object.

The Internet and VCN Resolver does not let instances resolve the hostnames of hosts in your on-premises network connected to your VCN by IPSec VPN connection. Use your own custom DNS resolver to enable that.

custom resolver

Use your own DNS servers (maximum three). They could be DNS servers that are:

Available through the internet. For example, 216.146.35.35 for Dyn's Internet Guide.

About the DNS Domains and Hostnames

When you initially create a VCN and subnets, you may specify DNS labels for each. The labels, along with the parent domain of oraclevcn.com form the VCN domain name and subnet domain name:

VCN domain name:<VCN DNS label>.oraclevcn.com

Subnet domain name:<subnet DNS label>.<VCN DNS label>.oraclevcn.com

When you then launch an instance, you may assign a hostname. It's assigned to the VNIC that's automatically created during instance launch (that is, the primary VNIC). Along with the subnet domain name, the hostname forms the instance's fully qualified domain name (FQDN):

The FQDN resolves to the instance's private IP address. The Internet and VCN Resolver also enables reverse DNS lookup, which lets you determine the hostname corresponding to the private IP address.

If you add a secondary VNIC to the instance, you can specify a hostname. The resulting FQDN resolves to the VNIC's private IP address (that is, the primary private IP).

If you add a secondary private IP to a VNIC, you can specify a hostname. The resulting FQDN resolves to that private IP address.

Requirements for DNS Labels and Hostnames

VCN and subnet labels: Max 15 alphanumeric characters and must start with a letter. Cannot be changed later.

Hostnames: Max 63 characters and must be compliant with RFCs 952 and 1123. Can be changed later.

The Networking service allows hostnames up to 63 characters. However, some older operating systems enforce shorter hostnames. In Linux, here's how to determine the maximum allowed hostname length:

getconf HOST_NAME_MAX

If an instance has a hostname longer than the OS-specific maximum, the instance's FQDN is not resolvable within the VCN. You can use the Networking service to update the VNIC and change the hostname to a shorter value.

Uniqueness:

VCN DNS label should be unique across your VCNs (not required, but a best practice)

Subnet DNS labels must be unique within the VCN

Hostnames must be unique within the subnet

Don't confuse the DNS label or hostname with the friendly name you can assign to the object (that is, the display name), which doesn't have to be unique.

Validation and Generation of the Hostname

If you've set DNS labels for the VCN and subnets, Oracle validates the hostname for DNS compliance and uniqueness during instance launch. If either of these requirements isn't met, the launch request fails.

If you don't specify a hostname during instance launch, Oracle tries to use the instance's display name as the hostname. If the display name does not pass the validation, Oracle automatically generates a DNS-compliant hostname that's unique across the subnet. You can see the generated hostname on the instance's page in the Console. In the API, the hostname is part of the VNIC object.

If you don't provide a hostname or display name during instance launch, Oracle automatically generates a display name but NOT a hostname. This means the instance won't be resolvable using the Internet and VCN Resolver.

The Linux OS hostname on the instance is automatically set to the hostname you set during instance launch (or the one generated by Oracle). If you change the hostname directly on the instance, the FQDN of the instance does not get updated.

If you add a secondary VNIC to an instance, or add a secondary private IP to a VNIC, Oracle never tries to generate a hostname. Provide a valid hostname if you want the private IP address to be resolvable using the Internet and VCN Resolver.

DHCP Options for DNS

Default value in the default set of DHCP options: Internet and VCN Resolver

Search Domain: To specify a single search domain. When resolving a DNS query, the OS appends this search domain to the value being queried.

Default value in the default set of DHCP options: The VCN domain name (<VCN DNS label>.oraclevcn.com), if you specified a DNS label for the VCN during creation. If you didn't, the default set of DHCP options does not include a Search Domain option.

The default set of DHCP options that you can associate with all the subnets in the VCN automatically uses the default values. This means you can simply use the <hostname>.<subnet DNS label> to communicate with any of the instances in the VCN. If the VCN uses a set of DHCP options that does not contain a Search Domain option, the instances must use the entire FQDN to communicate.

For any set of DHCP options (including the default set): If your VCN has a DNS label, the Networking service automatically adds a Search Domain option and sets the value to the VCN domain name (<VCN DNS label>.oraclevcn.com). You can always override this default value and set a value of your choice.

How to Enable DNS Hostnames in Your VCN

Only new VCNs created after the release of the Internet and VCN Resolver feature have automatic access to it. How to enable DNS hostnames for a new VCN depends on which interface you're using.

Specify a DNS label of your choice for the VCN. If you check the checkbox but don't specify a DNS label, the Console assumes that you want to use the Internet and VCN Resolver in your VCN and automatically generates a DNS label for the VCN. The Console takes the VCN name you provided, removes non-alphanumeric characters, ensures that the first character is a letter, and truncates the label to 15 characters. The Console displays the result, and if you don't like it, you can instead enter your own value in the DNS Label field. See Requirements for DNS Labels and Hostnames.

When creating the subnets:

Again, check the checkbox for Use DNS Hostnames in this Subnet

Specify a DNS label of your choice for each subnet. If you check the checkbox but don't specify the DNS label for a given subnet, the Console assumes you want to use the Internet and VCN Resolver for the subnet and automatically generates a DNS label for the subnet. The Console takes the subnet name you provided, removes non-alphanumeric characters, ensures that the first character is a letter, and truncates the label to 15 characters. The Console displays the result, and if you don't like it, you can instead enter your own value in the DNS Label field. See Requirements for DNS Labels and Hostnames.

Associate any set of DHCP options that has DNS type = Internet and VCN Resolver. The default set of DHCP options in the VCN uses the Internet and VCN Resolver by default.

If you don't check the checkbox for Use DNS Hostnames in this VCN when creating the VCN, you can't set the DNS label for the VCN or subnets, and you can't specify a hostname during instance launch.

The above procedure assumes you create the VCN and subnets one at a time in the Console. The Console has a feature that automatically creates a VCN with subnets and an internet gateway all at the same time. If you use that feature to create the VCN and subnets, the Console automatically generates DNS labels for them.

Specify a DNS label for each subnet. See Requirements for DNS Labels and Hostnames. If you specified a DNS label for the VCN, but you don't specify a DNS label for the subnet, Oracle assumes you don't want the instances in the subnet to use the Internet and VCN Resolver. They will not be able to use hostnames to communicate with instances in the VCN.

Associate any set of DHCP options that has DhcpDnsOptionserverType = VcnLocalPlusInternet. The default set of DHCP options in the VCN uses this by default.

If you don't specify a DNS label when creating the VCN, you can't set the DNS label for the subnets (the CreateSubnet call will fail), nor specify a hostname during instance launch (the LaunchInstance call will fail). You also cannot assign a hostname to a secondary VNIC or a secondary private IP.

Scenario 1: Use Internet and VCN Resolver with DNS Hostnames Across the VCN

The typical scenario is to enable the Internet and VCN Resolver across your entire VCN. This means all instances in the VCN can communicate with each other without knowing their IP addresses. To do that, follow the instructions for creating a new VCN in How to Enable DNS Hostnames in Your VCN, and make sure to assign a DNS label to the VCN and every subnet. Then make sure to assign every instance a hostname (or at least a display name) at launch. If you add a secondary VNIC or secondary private IP, also assign it a hostname. The instances can then communicate with each other using FQDNs instead of IP addresses. If you also set the Search Domain DHCP option to the VCN domain name (<VCN DNS label>.oraclevcn.com), the instances can then communicate with each other using just <hostname>.<subnet DNS label> instead of the FQDN.

Scenario 2: Use Custom DNS Servers to Resolve DNS Hostnames

You can set up an instance to be a custom DNS server within your VCN and configure it to resolve the hostnames that you set when launching the instances. You must configure the servers to use 169.254.169.254 as the forwarder for the VCN domain (that is, <VCN DNS label>.oraclevcn.com).

The custom DNS servers must be located in a subnet that uses Internet and VCN Resolver for DNS.

Scenario 3: Use Different DHCP Options Per Subnet

Scenario 1 assumes you want to use the Internet and VCN Resolver the same way across all subnets, and thus all instances in the VCN. You could, however, configure different DNS settings for each subnet, because the DHCP options are configured at the subnet level. The important thing to understand is this: The subnet where you want to generate the DNS query is where you need to configure the corresponding Internet and VCN Resolver settings.

For example, if you want instance A in subnet A to resolve the hostname of instance B in subnet B, you must configure subnet A to use the Internet and VCN Resolver. Conversely, if you want instance B to resolve the hostname of instance A, you must configure subnet B to use the Internet and VCN Resolver.

You can configure a different set of DHCP options for each subnet. For example, you could set subnet A's Search Domain to subnet-a.vcn-1.oraclevcn.com, which means all instances in subnet A could use just hostnames to communicate with each other. You could similarly set subnet B's Search domain to subnet-b.vcn-1.oraclevcn.com to enable Subnet B's instances to communicate with each other with just hostnames. But that means any instances in a given subnet would need to use FQDNs to communicate with instances in other subnets.