Oracle Cloud Infrastructure Documentation

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 VCN. You make this choice for each subnet in the VCN, using the subnet's set of 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.

Note

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

DEFAULT CHOICE: INTERNET AND VCN RESOLVER
This is an Oracle-provided option that includes two parts:
  • Internet Resolver: Lets instances resolve hostnames that are publicly published on the internet. The instances do not need to have internet access by way of either an internet gateway  or a connection to your on-premises network (such as a Site-to-Site VPN IPSec connection through a DRG ).
  • VCN Resolver: Lets instances resolve hostnames (which you can assign) of other instances in the same 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.
Note

By default. the Internet and VCN Resolver does not let instances resolve the hostnames of hosts in your on-premises network connected to your VCN by Site-to-Site VPN or FastConnect. That functionality can be achieved either by using a custom resolver or by configuring the VCN's private DNS resolver.

CUSTOM RESOLVER
Use DNS servers of your choice for resolution (maximum three). They could be DNS servers that are:
  • Available through the internet. For example, 216.146.35.35 for Dyn's Internet Guide.
  • In your VCN.
  • In your on-premises network, which is connected to your VCN by way of a Site-to-Site VPN or FastConnect (through a DRG ).

About the DNS Domains and Hostnames

When you initially create a VCN and subnets, you may specify DNS labels for each. Subnet DNS labels can only be set if the VCN itself is created with a DNS label. 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):

  • Instance FQDN: <hostname>.<subnet-DNS-label>.<VCN-DNS-label>.oraclevcn.com

For example: database1.privatesubnet1.abccorpvcn1.oraclevcn.com.

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

Important

Oracle recommends that you always use the instance FQDN when sending messages to a host, or alternately specify only the hostname for messages sent within a VCN.

Requirements for DNS Labels and Hostnames

  • VCN and subnet labels: Max 15 alphanumeric characters and must start with a letter. Notice that hyphens and underscores are NOT allowed. The value cannot be changed later.
  • Hostnames: Max 63 characters, letters and numbers are allowed. Hyphens are allowed. Notice that periods are NOT allowed, hyphens aren't allowed at the beginning or end of the hostname, and the hostname can't be all numbers. Hostnames must be compliant with RFCs 952 and 1123. The value can be changed later.
Important

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
Tip

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 using the SDK or CLI, Oracle does not generate a display name or hostname. This means the instance won't be resolvable using the Internet and VCN Resolver.

If you don't provide a hostname or display name during instance launch using the Console, Oracle will auto-generate a display name and a corresponding DNS record, provided the subnet has a valid DNS label associated with it.

Note

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

Two DHCP options are related to DNS in your VCN:

  • Domain Name Server: To specify your choice for DNS type (either Internet and VCN Resolver, or Custom Resolver).

    • 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. You can specify only one search domain for the set of DHCP options.

    • 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 but did not specify a search domain value. If you specified a search domain value, then that value is used for the Search Domain option. If you did NOT specify a DNS label, the default set of DHCP options does not include a Search Domain option.
Caution

Oracle recommends that you always use the instance FQDN when sending messages to a host in another subnet/VCN and do not rely on the DNS search domain.

Important

In general, when any set of DHCP options is initially created (the default set or a custom set you create), the Networking service automatically adds the Search Domain option and sets it to the VCN domain name ( <VCN-DNS-label>.oraclevcn.com) if all of these are true:

  • The VCN has a DNS label
  • DNS Type = Internet and VCN Resolver
  • You did NOT specify a search domain of your choice during creation of the set of DHCP options

After the set of DHCP options is created, you can always remove the Search Domain option or set it to a different value.

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.

If you create a VCN and subnets with the Console
  1. When creating the VCN:
    • Select the check box for Use DNS Hostnames in this VCN
    • Specify a DNS label of your choice for the VCN. If you check the check box 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 About the DNS Domains and Hostnames.
  2. When creating the subnets:
    • Again, select the check box for Use DNS Hostnames in this Subnet
    • Specify a DNS label of your choice for each subnet. If you check the check box 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 About the DNS Domains and Hostnames.
      Note

      Subnet DNS labels can only be set if the VCN itself is created with a DNS label.
    • 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.
  3. When launching instances:
    • Select the option to assign a private DNS record.
    • Specify a hostname (or at least a display name) for each instance. For more information, see About the DNS Domains and Hostnames.

If you don't check the check box 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.

Note

The previous 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.

If you create a VCN and subnets with the API

  1. When creating the VCN:

    • Specify a DNS label for the VCN. See About the DNS Domains and Hostnames. If you don't set a value (if it's null), Oracle assumes that you don't want to use the Internet and VCN Resolver, even if the DHCP options have DhcpDnsOption serverType = VcnLocalPlusInternet.

  2. When creating the subnets:

    • Specify a DNS label for each subnet. See About the DNS Domains and Hostnames. If you specified a DNS label for the VCN, but you don't specify a DNS label for the subnet, Oracle assumes that you don't want the instances in the subnet to use the Internet and VCN Resolver and the ability to use hostnames to communicate with instances in the VCN is no longer available.
      Note

      Subnet DNS labels can only be set if the VCN itself was created with a DNS label.
    • Associate any set of DHCP options that has DhcpDnsOptionserverType = VcnLocalPlusInternet, which is the default DHCP option in the VCN.

  3. When launching instances:

    • Select the option to assign a private DNS record.
    • Specify a hostname (or at least a display name) for each instance. For more information, see About the DNS Domains and Hostnames.

If you don't specify a DNS label when creating the VCN, you can't do the following things:

  • Set the DNS label for the subnets (causing the CreateSubnet call to fail)
  • Specify a hostname during instance launch (causing the LaunchInstance call to fail)
  • 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, which allows all instances in the VCN to communicate with each other without knowing their IP addresses. To do that, follow the instructions in About the DNS Domains and Hostnames, and assign a DNS label to the VCN and every subnet. Then 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.

Scenario 2: Use a Private DNS Resolver to Resolve DNS Hostnames

You can use a private DNS resolver to answer DNS queries for a VCN using a configuration you create. The resolver listens on 169.254.169.254 by default, but also allows you to define endpoints for listening for queries and forwarding them to other resolvers in other VCNs, a customer's on-premises network, or other private network. For more information, see Private DNS resolvers.

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: 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 subneta.vcn1.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 subnetb.vcn1.oraclevcn.com to enable Subnet B's instances to communicate with each other with just hostnames.

Private DNS resolvers

A private DNS resolver answers DNS queries for a VCN per a configuration you create.

When you create a VCN and select the Use DNS hostnames in this VCN option, this choice creates a dedicated private DNS resolver and a default private view with system-managed zones. A private DNS resolver also handles internal DNS queries for your VCN based on private views and the private zones that you have created and the rules you create for the resolver. A private DNS zone has capabilities similar to an internet DNS zone, but only provides responses for clients that can reach it through a VCN. The default view is only used if the resolver does not get a match from the other attached private views, if there are any. A private resolver can be configured to use views and zones as well as conditional forwarding rules to define how to respond to DNS queries. To better understand views and zones, refer to Private DNS.

You can create your own custom domains to use in addition to the system-generated names based on VCNs and subnets, and you can do VCN to VCN and VCN to on-premises resolution

To add a private view to a private resolver
  1. From the Virtual Cloud Network Details screen for your VCN, look in the VCN Information tab and click the name of the DNS resolver for the VCN. The Private Resolver Details screen appears.
  2. From the Private Resolver Details screen, click Manage Private Views. The Manage Private Views screen appears.
  3. Select a previously created private view from the drop down menu in the numbered Private view list.
  4. To associate another view, click Additional Private View select another view.
  5. When you are finished, click Save Changes.

Views created automatically by Oracle are available in addition to views you create.

To remove a private view from a private resolver
  1. From the Private Resolver Details screen, click the check box next to the private view you want to remove from the resolver. Remove turns red, and can now be clicked. You can select other private views if necessary.
  2. Click Remove.
Note

You can also remove a private view from the Manage Private Views screen by clicking the red button labeled - and then clicking Save Changes.
To rename a private resolver
  1. From the Private Resolver Details screen, click Edit.
  2. Enter the new name for the resolver. Avoid entering confidential information. Then, click Save Changes.
To manage DNS zones and views

See Managing DNS Service Zones.

Resolver Endpoints

A DNS forwarding resolver endpoint is required before you can create a resolver rule. Resolver endpoints are attached to a VCN or a subnet. No listening endpoint is required for compute instances sending queries to 169.254.169.254. Two types of endpoint are used:

  • Listening - A listening endpoint receives queries from these sources: within the VCN, other VCN Resolvers, or your on-premises network's DNS. Once created, no further configuration is needed for a listening endpoint.
  • Forwarding - A forwarding endpoint forwards DNS queries to the Listening endpoint for resolvers in other peered VCNs or your on-premises network's DNS. Decisions about where to forward queries are based on resolver rules that you define.
Note

IPv6 is not supported for listening or forwarding endpoints.

An endpoint can only be configured to either forward or listen.

Note

Network security groups (NSGs) act as a virtual firewall for your DNS resolver endpoints. An NSG consists of a set of ingress and egress security rules that apply only to the associated DNS resolver endpoints.

Oracle recommends that you modify your security list or NSG security rules to allow traffic bound for UDP Port 53 (and optionally TCP Port 53) on your DNS listener endpoints.

To create a resolver endpoint
  1. From the Virtual Cloud Network Details screen for your VCN, look in the VCN Information tab and click the name of the DNS resolver for the VCN. The Private Resolver Details screen appears.
  2. From the Private Resolver Details screen, click Endpoints in the left-hand navigation.
  3. Click Create Endpoint. The Create Endpoint screen appears.
  4. Make choices for the following settings:
    • Select a name for the endpoint. The name can use any combination of letters and numbers, but the only supported special character is an underscore.
    • Select a subnet for the endpoint from the pull-down list.
    • Select the endpoint type, which can be either Listening or Forwarding. When you make this choice, you provide an IP address, or allow Oracle to assign one for the endpoint. This IP address is used by the resolver to forward DNS queries, or to listen for DNS queries from other systems. The IP address must be in the same CIDR block used by the VCN or subnet associated with the resolver.
    • Optional: Use a Network Security Group to control traffic. To use this feature, select an NSG to use with the endpoint. You can also add an NSG after the endpoint is created.
To delete a resolver endpoint
  1. From the Private Resolver Details screen, click the Action button to the right of the endpoint you want to delete, and then click Delete.
  2. Confirm the deletion by clicking Delete.
To add an NSG to a resolver endpoint
  1. From the Private Resolver Details screen, click the name of the endpoint you want to associate with a Network Security group. The Endpoint Details screen appears.
  2. Click Add Network Security Groups, and select up to five security groups to associate with the endpoint.
  3. When finished, click Add Network Security Groups.
To remove an NSG from a resolver endpoint
  1. From the Private Resolver Details screen, click the name of the endpoint you want to de-associate with a Network Security group. The Endpoint Details screen appears.
  2. Click the X button to the right of the listed NSG. You could change to a different NSG if necessary.
  3. When finished, click Add Network Security Groups.

Resolver Rules

Rules are used to answer queries that aren't answered by a resolver's views. They are checked in order, and each can optionally have conditions that limit which queries they apply to. Queries not matched by any view or rule are resolved from internet DNS. You can have up to 10 rules per resolver.

Note

Endpoints are used in the rule, and they must exist before you create a resolver rule.

Use case

The most common application is to have one or more rules that follow this general form:

If <query domain> is <example.com>, forward using <forwarding-endpoint> to IP address X.X.X.X.

Followed by a final rule that follows this form:

If <anything else> , forward using <forwarding-endpoint> to IP address Y.Y.Y.Y.

So if the query is looking for example.com, the resolver internally forwards it to X.X.X.X through the specified forwarding endpoint and responds with the answer it receives. For any other query, it forwards to Y.Y.Y.Y through the same forwarding endpoint and responds with that answer it gets from Y.Y.Y.Y.

To create resolver rules
  1. From the Private Resolver Details screen, click Rules in the Resources column. Click Manage Rules. The Manage Rules screen appears.
  2. You can have up to 10 rules per resolver. For each rule, select:
    • Rule condition: Determines whether routing decisions are made based on the query's originating CIDR Block or Domain (up to 10 hostnames), or neither (Select None to match any CIDR Block or Domain).
    • Client CIDR blocks or Domains: Up to 10 CIDR blocks or domains.
    • Rule action: This field is read-only. Forward is the only option.
    • Source endpoint: The private endpoint used to forward queries when the rule condition is met.
    • Destination IP address: The address to forward the query to if the rule condition is met.
  3. Click +Additional Rule to create another rule if necessary.
  4. Click Save Changes when finished.
To edit resolver rules
  1. From the Private Resolver Details screen, click Rules in the Resources column.
  2. Click Manage Rules. The Manage Rules screen appears.
  3. Make changes based on your intended design. These changes can include changing options in a rule, changing the order of rules, and removing rules altogether.
  4. When finished, click Save Changes.
To remove resolver rules
  1. From the Private Resolver Details screen, click Rules in the Resources column.
  2. Click the check box in the row for the rule or rules you want to delete. Click Remove. The Confirm Removal screen appears.
  3. Click Remove.

Reverse DNS (PTR)

A reverse DNS record, also known as a pointer record (PTR), resolves an IP address back to a fully qualified domain name (FQDN). It functions in the opposite way of an A (IPv4) or AAAA (IPv6) forward record. For example: 192.0.2.5 → myhost.mydomain.com.

You can request that a PTR record be established for your cloud IP addresses:
  1. Create an A (IPv4) or AAAA (IPv6) forward record that points the fully qualified domain name to the IP prior to opening the request. You can create the record using the Oracle Cloud Infrastructure DNS service, or a third-party DNS provider.
  2. Open a service request and include the following information:
    1. The IP address and fully qualified domain name (FQDN) you want in the PTR.
    2. The FQDN of the forward record that you created in step 1.
After the service request is received, the forward (A or AAAA) record information is validated to be sure it can be successfully resolved, and Oracle creates the PTR record on your behalf.

Using the API

Use the following operations to manage resolvers and resolver endpoints: