Android has a built-in way to encrypt the DNS lookups from every app on your phone, on Wi-Fi and mobile data alike. It's called Private DNS, and it works without installing anything. It is also one of the most confusing settings on the phone, because when something is wrong it says only "Couldn't connect", and then your internet stops.

This guide explains what Private DNS actually does, how to set it up with your own DNS hostname, and, most usefully, how to work out why it fails, step by step, in the order that finds the cause fastest.

What Private DNS is, and what it isn't

Every app on your phone starts connections with a DNS lookup: "what is the address of this name?" Normally those lookups travel unencrypted, so your Wi-Fi operator, mobile carrier, or ISP can read them. Private DNS wraps them in encryption, using DNS over TLS (DoT) on port 853. It has been available since Android 9.

What it does:

• Encrypts the lookups from your phone to the DNS server you choose.
• Applies to all apps, and to both Wi-Fi and mobile data.

What it doesn't do:

• It doesn't block ads by itself. Blocking is done by the DNS server you point it at. Private DNS is only the encrypted pipe.
• It doesn't hide where you connect. Your network can still see the IP addresses you connect to.
• It isn't a VPN. It protects lookups, not the traffic itself.

The three modes

You'll find the setting by searching for "Private DNS" in Settings. The menu path varies by manufacturer, for example Network & internet → Private DNS on many phones, or Connections → More connection settings → Private DNS on Samsung. It has three options:

To use your own DNS server, such as a private Pi-hole or AdGuard Home node, you need the third option. It is also the one that produces the "Couldn't connect" error, because it's the only mode that refuses to fall back.

One more detail: on Android 11 and later, picking some well-known providers, such as Google's dns.google or Cloudflare's one.one.one.one, reportedly makes Android use DNS over HTTP/3 instead of DoT. Google hasn't published exactly which providers that applies to. A custom hostname of your own uses DoT on port 853, which is what the rest of this guide assumes.

What a hostname needs to work

When you tap Save, Android tries to open a TLS connection to port 853 on that hostname and checks the server's certificate against the name you typed. Every one of these must be true:

1. You entered a hostname, not an IP address. The field takes a name like dns.example.com. It has no field for a port or a URL, and DoT always uses port 853.
2. The hostname resolves. Android first has to look the name up using the network's own DNS, before any encryption starts.
3. The server listens for DoT on port 853, and nothing between your phone and the server blocks that port.
4. The server presents a valid certificate for exactly that hostname, issued by a certificate authority Android trusts, not expired, and with the complete chain.

If any of the four fails, you get "Couldn't connect". The rest of this guide is a way to find which one.

How to set it up

1. Get your DoT hostname from your DNS provider or your own server.
2. Open Settings and search for Private DNS.
3. Choose Private DNS provider hostname.
4. Type the hostname exactly, with no https://, no port, and no trailing spaces.
5. Tap Save.

If the settings screen now shows your hostname with no error, Android has validated the server. If it shows "Couldn't connect", go to the fix section below.

Check that it's really being used. Browse for a minute, then look at your DNS server's query log or dashboard. Your phone's lookups should appear there. If you use a blocking server, blocked ads and trackers should show up as blocked. A matching log is better proof than a green setting.

Fix: "Couldn't connect"

Two things to know first. In hostname mode Android deliberately does not fall back to plain DNS when the server can't be reached, which is why the whole internet stops. And the error message gives no reason, so you have to test for it.

Step 1: Get back online

Set Private DNS to Automatic (or Off). Your internet returns immediately. This is a temporary measure: you're unencrypted until the problem is fixed, but you can now test properly.

Step 2: Check the hostname itself

Most failures are small:

• No https://, no port number such as :853, no path.
• No capital letters swapped in or extra spaces, which phone keyboards often add after autocomplete.
• It's a hostname, not an IP address.
• It matches the provider's instructions exactly. A single wrong character in a subdomain gives the same error as a dead server.

Step 3: Test on another network

This one test splits the problem in half. Try the same hostname on mobile data and on Wi-Fi.

Step 4: Test the server from a computer

If it fails everywhere, check the server directly. The kdig tool (part of knot-dnsutils) makes a real DoT query and verifies the certificate the way a phone does:

kdig @dns.example.com +tls-ca +tls-hostname=dns.example.com example.com

If this fails or reports a certificate error, you have found your problem, and it is on the server. Then inspect the certificate:

openssl s_client -connect dns.example.com:853 -servername dns.example.com </dev/null

Look for these in the output:

• Verify return code: 0 (ok) at the end. Anything else is a problem Android will also hit.
• The certificate chain. If only one certificate is listed and the intermediate is missing, that is a likely cause. Desktop browsers can often cope with this, but Android generally doesn't fetch missing intermediates for you, so serve the full chain (fullchain.pem, not cert.pem).
• The dates. An expired certificate is one of the most common causes of a DNS server that "suddenly stopped working", since renewals fail silently.
• The name. The certificate must be valid for exactly the hostname you typed.

Step 5: Certificate problems that only affect your phone

If the certificate checks out on your computer but your phone still fails:

• Check the phone's date and time. A wrong clock makes every valid certificate look expired or not yet valid. Set it to automatic.
• Consider the phone's age. Android validates against its own list of trusted certificate authorities, which older phones don't update. A certificate chaining to a newer authority may not be trusted on an old device. A well-known case happened around 2021 when a widely used authority's root certificate expired and older Android versions rejected certificates that still worked elsewhere.

Step 6: Network blocks and captive portals

• Port 853 blocked. Many corporate, school, and public networks block DNS over TLS. You can't fix that from the phone. Use Automatic mode on that network, or one of the workarounds below.
• Captive portals. Hotel, airport, and café Wi-Fi that make you log in can break hostname mode, because the network answers every lookup, including your hostname's, with its own login page. The fix: set Private DNS to Automatic or Off, complete the login, then switch the hostname back.
• The Wi-Fi warning "Private DNS server cannot be accessed." This is the same failure shown on the network's detail screen. It means the phone couldn't complete a TLS connection on port 853, which points at a firewall or login page far more often than a wrong hostname.

Step 7: VPNs and other DNS apps

VPN apps, ad-blocking apps, and DNS changers can interfere. Depending on the app and the Android version, they may use their own DNS, block port 853, or ignore the Private DNS setting. If the error only appears while such an app is running, turn it off and retest, then check whether it has its own DNS or Private DNS option. Occasionally the "Couldn't connect" label has also been reported to appear even though lookups work, which is another reason to judge by whether the internet actually works and what your server's log shows.

Step 8: If you run the server yourself

Check, in this order: the DoT service is running; port 853/TCP is open in the firewall and forwarded correctly; the hostname's DNS records point at the right address (and if it has an IPv6 record, the server must also listen on IPv6, since a broken one can cause failures on IPv6 networks); the certificate hasn't expired and renewal actually reloads the service.

Quick reference

If port 853 is blocked and you can't change it

Android's Private DNS can't switch to another port or protocol for a custom hostname, so on a network that blocks 853 you have three realistic options:

• Use Automatic or Off on that network and accept unencrypted DNS there.
• Use an app that speaks DNS over HTTPS (DoH), which travels on port 443 like normal web traffic and is much harder for a network to block. Apps such as Intra and AdGuard for Android let you enter a custom DoH address.
• Use a browser's built-in secure DNS setting with your DoH link, which covers that browser only.

Things that surprise people

• It fails closed. With a hostname set, a server outage means no internet, not unencrypted internet. That is by design.
• It follows you everywhere. It applies on every Wi-Fi network and on mobile data, so any network that blocks 853 will break it.
• Some phones come with a provider already set, so check the setting before assuming it is off.
• There is no per-device or per-profile information in a plain Private DNS hostname. Every lookup from the phone looks the same to the server.
• Privacy depends on the server. Encryption protects the trip, but the server still sees your lookups.

Where NxValue fits

Every NxValue Stack node comes with its own DoT endpoint , so setup is just..paste it into Private DNS provider hostname and save. Because the node is yours, your lookups go to a private Pi-hole or AdGuard Home instance with an Unbound resolver, and your dashboard shows the blocked queries live, which is the quickest way to confirm your phone is really using it.

Most of the causes in the fix section, such as certificates, port 853, and the DoT service itself, are server-side, and those are ours to keep working. The network-side causes are not: a Wi-Fi network that blocks port 853, a captive portal, or a VPN app conflict will affect any Private DNS provider, NxValue included, and the steps above apply equally.

One practical tip: if you delete a node, your phone will keep trying its hostname and show "Couldn't connect". Switch Private DNS back to Automatic or Off first.

To see how it works before deploying, try the demo node, use the DNS Tester to check whether a resolver supports DoT and DoH, and use the DNS Setup tool for configuration on Android, iOS, Windows, and more.

Summary

• Private DNS encrypts your phone's DNS lookups with DoT on port 853. It doesn't block ads by itself, and it doesn't hide the IP addresses you connect to.
• For your own server, use Private DNS provider hostname. It's the only mode that always uses your server, and the only one that fails closed.
• A hostname works only if it resolves, accepts DoT on 853, and presents a valid, complete certificate for that exact name.
• When it fails, switch to Automatic to get online, then test on a second network. That single test tells you whether to look at the network or at the server.
• On a computer, kdig and openssl s_client show the same failure Android sees, with a reason.
• On networks that block port 853, use Automatic, a DoH-capable app, or a browser's secure DNS setting.

Android and Pixel are trademarks of Google LLC. Pi-hole is a registered trademark of Pi-hole LLC. AdGuard Home and AdGuard for Android are trademarks of AdGuard Software Limited. Samsung is a trademark of Samsung Electronics Co., Ltd. NxValue Stack is an independent service provider and is not affiliated with any of these organizations.

Further reading

• RFC 7858: DNS over TLS
• Internet Society: DNS privacy in Android 9
• Google Public DNS: secure transports