---
title: I am experiencing DNS or SSL errors and conflicts with my Private Network
description: This page helps you troubleshoot problems that can occur when accessing your resource by its hostname over a Private Network
tags: private-network tld ssl ssl-validation-failed dns name addressing
dates:
  validation: 2025-05-30
  posted: 2024-01-31
---

Scaleway VPC and Private Networks integrate managed DNS, for the effective resolution of hostnames to IP addresses. You may be experiencing DNS and/or related SSL errors when attempting to access your resource over its [hostname](/vpc/reference-content/dns/#hostname-format) on a Private Network.

This document guides you through solutions to this type of problem.

## Basic steps to try first

- Make sure that [DHCP is activated](/vpc/how-to/activate-dhcp/) on your Private Network.
- Ensure that you have tried [detaching/reattaching](/vpc/troubleshooting/resource-attached-no-ip/#no-ip-address-is-displayed-but-i-have-activated-dhcp) the affected resources from/to the Private Network, particularly if they are older resources or you have [changed their name](/vpc/how-to/attach-resources-to-pn/#how-to-access-a-resource-on-a-private-network-via-its-hostname-dns).
- Ensure that you are correctly addressing resources attached to a Private Network, using the format `resource-name.private-network-name.internal`. The `.internal` is important to allow Scaleway DNS to distinguish public and private hostnames and correctly resolve requests. [Find out more about DNS](/vpc/reference-content/dns/).

## Check for TLD naming problem

If you have given your Private Network a name that is also a **T**op **L**evel **D**omain, you may experience SSL or addressing errors and conflicts when you try to access resources on the public internet with the same TLD as your Private Network, or when trying to reach resources on your Private Network from the public internet. Examples are:

- Errors when trying to reach  `google.dev` from a Private Network named `dev`
- Errors when trying to reach `scw.cloud.network` from a Private Network named `network`

### Solution

Scaleway is working on a solution to allow users to name their Private Networks with a TLD name without experiencing any conflicts. In the meantime, until this solution is deployed, you should **not** give your Private Network a name that is also a TLD. 

- For a complete reference of TLDs to avoid, see the full list provided by [IANA](https://data.iana.org/TLD/tlds-alpha-by-domain.txt)
- Giving a name that **uses** a TLD in combination with something else (e.g. `dev-123` or `cloud-sarah`) is OK, as long as the entire Private Network name is not the same as a TLD (e.g. `dev`, `cloud`)

You can change your Private Network name at any time in the [Scaleway console](https://console.scaleway.com/):

1. In the side menu, click **VPC**.
2. Use the **region selector** to filter for the region of the VPC containing the Private Network you want to rename, then click the VPC in the listing. A listing of Private Networks in the VPC displays.
3. Click the Private Network to rename.
4. Click the Private Network's name at the top of the screen, change it to a new name, and click <Icon name="validate" /> to confirm.

    <Message type="important">
    - After changing the name of Private Network, it can take up to five minutes for the new name to be propagated. 
    - You should also renew DHCP leases in order to update the list of search domains for the Private Network: do this by running `netplan apply` on Ubuntu servers.
    - Note that resources in a Private Network are in any case always reachable by their IP address.
    </Message>

## Check whether resource has a dot in its hostname

Issues may arise with internal addressing if you give your resource a name that includes a dot (`.`).

### Solution

Try renaming your resource to a name that does not include a dot, then detach/reattach it to the Private Network in order to update DNS.

## Distributions running Network Manager

Private DNS should work out of the box for attached resources with Debian-based distributions, and for distributions using `systemd-resolved`, such as Ubuntu.

It does **not** work out of the box for Linux distributions using Network Manager, such as **RockyLinux**. 

### Solution

If your resource is running RockyLinux, or another distribution using Network Manager, you should manually configure the system to use the nameserver `169.254.169.254`. You will then be able to resolve the name of your resources, as well as public domain names.