Discuss with expertTry it for free
© 2026 Direct Cursus Technology L.L.C.

Configuring DNS in a private subnet

Written by
Updated at October 30, 2026
View in Markdown

In a BareMetal private subnet, you can configure DNS servers and a domain name that will be provided to servers via DHCP. You can use inbound Cloud DNS connections, custom DNS servers, or a combination of both options.

Getting started

  1. Ensure DHCP is enabled in the private subnet and the server private network interfaces receive IP addresses via DHCP. Optionally, create a subnet with DHCP enabled.

  2. Set up your DNS servers:

    • To use Cloud DNS, configure network connectivity between your private subnet’s VRF and the Virtual Private Cloud cloud network. Create an inbound DNS connection in this cloud network or use an existing one. Make sure the subnet prefix hosting the active inbound DNS connection IP address is announced by the virtual router.
    • To use a custom DNS server, prepare its IPv4 address and ensure this address is accessible from the BareMetal private subnet.

Warning

The new DNS settings will be provided to all servers within the subnet that use DHCP. This new list of DNS servers will replace your previous private interface DNS settings. Make sure the selected DNS servers resolve all required names. For more information, see Restrictions.

Configure DNS

  1. In the management console, select the folder housing the private subnet.

  2. Navigate to BareMetal.

  3. In the left-hand panel, select  Private subnets.

  4. Open the private subnet for editing.

  5. Make sure Assigning IP addresses via DHCP is on.

  6. Configure DNS:

    1. Enable the DNS server option.
    2. In the Domain name server field, select the inbound DNS connection from the list or enter the IPv4 address of your own DNS server and add it to the list.
    3. Optionally, to specify another DNS server, click Add server and select an inbound DNS connection or enter an IPv4 address. You can specify up to three DNS servers.
    4. Optionally, in the Domain name field, specify the search domain without leading or trailing dots, e.g., example.internal. When resolving short names, the OS will automatically append this domain: app → app.example.internal. Make sure all specified DNS servers can resolve names within this domain.

  7. Click Save changes.

If you do not have the Yandex Cloud CLI yet, install and initialize it.

The folder used by default is the one specified when creating the CLI profile. To change the default folder, use the yc config set folder-id <folder_ID> command. You can also specify a different folder for any command using --folder-name or --folder-id.

If you access a resource by its name, the search will be limited to the default folder. If you access a resource by its ID, the search will be global, i.e., through all folders based on access permissions.

To configure DNS, use CLI version 1.37.0 or higher.

  1. See the description of the CLI command for updating a private subnet:

    yc baremetal private-subnet update --help

  2. Get the private subnet ID:

    yc baremetal private-subnet list

  3. View the current subnet settings:

    yc baremetal private-subnet get <subnet_ID>

    Save the vrf_id, cidr, gateway_ip, dhcp_options.start_ip, and dhcp_options.end_ip values from the vrf_options section. Remember to provide them unchanged when configuring DNS.

  4. If using an inbound Cloud DNS connection, get its ID:

    yc dns inbound-endpoint list

  5. Specify the subnet's DNS settings:

    yc baremetal private-subnet update <subnet_ID> \
  --update-mask vrf_options_spec \
  --vrf-options-spec '{
    vrf-id=<VRF_ID>,
    cidr=<CIDR>,
    gateway-ip=<gateway_IP_address>,
    dhcp-options={
      start-ip=<IP_address_range_start>,
      end-ip=<IP_address_range_end>,
      dns-options={
        servers=[
          {server={dns-inbound-endpoint-id=<DNS_connection_ID>}}
        ],
        domain-name=example.internal
      }
    }
  }'

    Where:

    • <subnet_ID>: ID of the subnet you want to update. This is a required setting.

    • dev-route.yaml: Updates only routing and DHCP settings. The subnet name, description, or labels do not change.

    • --vrf-options-spec: Routing and DHCP settings. Set vrf-id, cidr, gateway-ip, start-ip, and end-ip to the saved values from the subnet's current settings respectively.

    • dns-options.servers: List of DNS servers. For each server item, specify either of these parameters:

      • dns-inbound-endpoint-id: Inbound DNS connection ID.
      • ip-address: Custom DNS server's IPv4 address, e.g., {server={ip-address=192.168.10.2}}.

      You can specify up to three items, comma-separated. When updating the list, provide all DNS servers you want to remain in the settings.

    • dns-options.domain-name: Search domain. This is an optional parameter. Replace example.internal with a custom domain, or delete the parameter if you do not need a search domain.

The settings will be provided to the servers upon DHCP rental renewal, within five minutes. They apply only to interfaces for which the OS is configured to receive the corresponding parameters via DHCP.

Verify that the settings apply

The examples below use Ubuntu with systemd-resolved. For other operating systems, use your OS tools to verify network settings.

  1. Connect to the server via the KVM console or over SSH.

  2. Find out the private network interface name:

    ip -4 address

  3. Check the interface DNS settings:

    resolvectl status <private_interface_ID>

    The DNS Servers field should specify the IP addresses of your selected DNS servers. If you specified a domain name and the OS applied it, that name will appear in the DNS Domain field.

  4. Verify that the resource's fully qualified domain name resolves correctly:

    resolvectl query <resource_FQDN>

    If a search domain is configured and includes a DNS record for the resource, also check whether the short name resolves correctly:

    resolvectl query <resource_short_name>

OS fails to apply DHCP parameters

If the new parameters do not propagate within five minutes, make sure DHCP is enabled for the private interface and the OS accepts DNS servers and the domain name from DHCP options. For example, in Ubuntu with Netplan and the systemd-networkd network service, the private interface description may require the following parameters:

dhcp4: true
dhcp4-overrides:
  use-dns: true
  use-domains: true

The use-dns parameter authorizes the use of DNS servers from DHCP option 6, and use-domains applies the search domain. For a physical interface, the parameters are set under ethernets; for an MC-LAG aggregation group, under bonds. Leave the other interface parameters unchanged.

If the network configuration is generated by cloud-init or alternative engine, make changes to that system’s persistent configuration, as edits to the generated file may be overwritten upon server reboot.

After updating the Netplan configuration, verify it:

sudo netplan try

If the configuration is correct, confirm your changes and repeat the check using resolvectl.

DNS server is unresponsive

Run a test request directly against your configured DNS server:

dig @<DNS_server_IP_address> <resource_FQDN>

If there is no response, check your network connectivity, routes, and traffic filtering rules. For an inbound DNS connection, also check it is placed in the correct cloud network and confirm that its subnet prefix is announced by the virtual router. If you get an NXDOMAIN response, check that the record exists and that the DNS zone is available to your selected DNS server.

Disable the distribution of DNS settings

Open the private subnet for editing, disable the DNS server option, and save your changes. This does not require disabling DHCP.

Re-run the subnet update command, with the dns-options part removed from the --vrf-options-spec value. Keep the remaining parameters, including dhcp-options with the current start-ip and end-ip values, so that your DHCP continues to issue IP addresses.

If you plan to delete an inbound DNS connection, first exclude it from the DNS settings of all private subnets that use it. If other DNS servers remain in the subnet, only remove the record of the connection you no longer need from the list and save your changes.

Useful links

Previous
Creating a private subnet
Next
Ordering a dedicated public subnet