Secure DNS Connection Settings

Two settings cover almost every device. Copy the one your platform accepts, or pick your device below for the exact steps.

New to encrypted DNS? See how DoH, DoT and DoQ work before you pick one.

Android · Routers · Linux
DNS-over-TLS
dnsdoh.art
Windows · Browsers · Apple
DNS-over-HTTPS
https://dnsdoh.art/dns-query

No encrypted DNS option on the device? Set 194.180.189.33 as its DNS server. Filtering and ad blocking still work, but the queries themselves are not encrypted. Windows 11 is the exception: from that address alone it finds the encrypted endpoint by itself.

Want DNS-over-QUIC or DNS-over-HTTP/3? Both are live, and both need a client that speaks them - .

Browser Configuration

Encrypt your DNS queries within Chrome, Firefox, or Edge.
Note: This only affects the browser, not other apps on your device.

Chrome, Edge, Brave, Opera, Vivaldi

DNS-over-HTTPS
Step 1

Go to Settings → Privacy and security → Security.

Step 2

Scroll to Secure DNS, set it to always use a selected provider, then open the provider list and pick Add custom DNS service provider - Edge, Brave and older Chrome builds label the same choice Custom.

Step 3

Enter the URL:
https://dnsdoh.art/dns-query

Every Chromium-based browser inherits this setting - Opera, Vivaldi, Arc and the rest - though vendors move and rename the sections around it. The shortcut that survives that: type secure DNS into the browser's own Search settings box and go straight to it. Firefox is separate, below, and has its own wording.

Mozilla Firefox

DNS-over-HTTPS
Step 1

Go to Settings → Privacy & Security → scroll to DNS over HTTPS.

Step 2

Under Enable DNS over HTTPS using: pick Increased Protection, then set Choose provider: to Custom.

Step 3

Enter the URL:
https://dnsdoh.art/dns-query

This is also where DNS-over-HTTP/3 comes from

Once that URL is in place, a Chromium browser connects to us over HTTP/3 with no further setting. We measured Chrome on Android arriving on UDP port 443 after nothing more than the three steps above. It is the only route to DoH3 that does not need extra software - and like any browser setting, it covers browsing only, not the rest of the device. More on the .

Safari / macOS Note

Safari uses the operating system's DNS settings. Use the to download the configuration profile.

How to Verify

After setup, visit Dns Leak Test. You should see servers from our encrypted upstreams - typically Cloudflare or Quad9, sometimes Google. If you see your ISP's DNS instead, the setup isn't active yet - the guide on how to fix a DNS leak walks through the common causes.

ChromeOS (Chromebook)

Chromebooks support Secure DNS system-wide - it covers every app, not just the browser:

  1. Open Settings → Security and Privacy
  2. Enable Use secure DNS and pick the custom-provider option (Add custom DNS service provider, or With custom provider on older builds)
  3. Enter https://dnsdoh.art/dns-query

DNS-over-QUIC and DNS-over-HTTP/3

Both run here and both work.
Neither is something an operating system will pick on its own - this page explains who can reach them.

All four transports are live

DNS-over-TLS · TCP 853
tls://dnsdoh.art
DNS-over-HTTPS · TCP 443
https://dnsdoh.art/dns-query
DNS-over-QUIC · UDP 853
quic://dnsdoh.art
DNS-over-HTTP/3 · UDP 443
https://dnsdoh.art/dns-query

DoH and DoH3 share one URL. Which of the two you get is decided by the client, not by the address you type.

How to actually reach DoH3

No operating system will do this for you. Windows 11 and Android both stop at DoH over HTTP/2 and DoT respectively, and no setting on our side changes that. The one route an ordinary user already has installed is a Chromium browser:

  1. Set Secure DNS to https://dnsdoh.art/dns-query - the has the exact steps.
  2. That is all. There is no HTTP/3 switch to find.

Our DoH endpoint answers with alt-svc: h3=":443"; ma=86400, and a browser already pointed at us takes the offer on its own. We measured Chrome on Android arriving on UDP port 443 after nothing more than the step above.

The upgrade is automatic; being found is not. A browser's Automatic Secure DNS mode only recognises resolvers on a list compiled into the browser, and we are not on it. You have to enter the URL once.

How to actually reach DoQ

DNS-over-QUIC is not implemented by any operating system or browser. It needs software written for it. Where that realistically exists:

  • ·Router firmware that lists DoQ among its upstream options. GL.iNet is the one widely sold consumer brand we found with it, on firmware 4.9 and later - .
  • ·dnsproxy or AdGuard Home run as a local forwarder, both open source.
  • ·Desktop DNS tools and command-line clients.
On Android there is no mainstream free client for DoQ. We looked, so that you do not have to. If encrypted DNS on the phone is the goal, gives you DoT system-wide and covers every app.

The h3:// scheme

If your client is dnsproxy or AdGuard Home, those two accept a scheme that forces HTTP/3 and refuses to fall back to earlier HTTP versions. It is their syntax, not a universal URL - other tools will reject it:

dnsproxy -u h3://dnsdoh.art/dns-query dnsproxy -u quic://dnsdoh.art
Testing with kdig? Read this first

Versions before Knot 3.4.7 - including the 3.3.4 that ships in Ubuntu 24.04 - abort the handshake against any certificate issued without a Subject field, reporting handshake failed (The requested data were not available.).

Ours is one such certificate. It is valid, and the same endpoint verifies cleanly with gnutls-cli and openssl s_client. Upgrade kdig, or test with another client:

q -s tls://dnsdoh.art example.com q -s quic://dnsdoh.art example.com

Router Configuration

Set it once and every device behind the router is covered, including the ones with no DNS settings of their own.
Not every router that offers encrypted DNS lets you name your own resolver - the ones below say which. These are the models whose steps we could check against the manufacturer's own documentation, and each card says where its steps came from. For anything not listed, your model's manual is the honest answer: we would rather point you there than guess at a menu we have never seen.

Keenetic

DoH / DoT
  1. Install the component first. Management → System settings → Component options, and tick DNS-over-TLS proxy or DNS-over-HTTPS proxy. Nothing below appears until you do.
  2. Go to Network Rules → Internet safety → the DNS configuration tab.
  3. Click Add server at the bottom of that tab.
  4. For DoT, fill DNS server address 194.180.189.33 and TLS domain name dnsdoh.art. Leave Connection interface on Any interface.
  5. For DoH, set DNS server type to DNS-over-HTTPS and DNS server address to https://dnsdoh.art/dns-query.

KeeneticOS has supported both since version 3.0. Once a DoT/DoH server is set, Keenetic stops using the DNS servers from your ISP and any you entered by hand - so this is the whole resolver for the network, not an addition to it. Keenetic recommends adding more than one server; with a single one there is no fallback if we are unreachable. Path, field names and the component requirement are from Keenetic's own manual; we have no Keenetic here to run it on.

ASUS / Merlin

DoT Ready
  1. Go to WAN → Internet Connection, and scroll to WAN DNS Setting.
  2. Set DNS Privacy Protocol to DNS-over-TLS.
  3. Leave DNS-over-TLS Profile on Strict, its default. Strict uses a server only if its identity authenticates; Opportunistic carries on when it does not.
  4. Skip Preset servers - those only pre-fill the fields - and enter ours below:
  5. Address: 194.180.189.33
  6. Hostname: dnsdoh.art
  7. Click Add so the entry lands in the server list, then Apply. Filling the fields without adding leaves it unconfigured.

Field names and the Strict/Opportunistic difference are from ASUS's own WAN setup FAQ; we have no ASUS router here.

GL.iNet

DoT / DoH / DoQ
  1. Open NETWORK → DNS.
  2. Set the mode to Encrypted DNS, and DNS Provider to Manual.
  3. Pick the encryption type, then Add a Server and enter one of:
  4. tls://dnsdoh.art https://dnsdoh.art/dns-query quic://dnsdoh.art

The one widely sold consumer router that reaches all three. DoQ needs firmware 4.9 or later, and it only appears as an encryption type when the DNS provider is set to Manual - GL.iNet restricts DoQ on their named-provider list to Control D, NextDNS and AdGuard, so picking a provider from that list hides the option you want. GL.iNet's DNS documentation.

TP-Link Deco

DoH / DoT
  1. In the Deco app: More → Advanced → DoH&DoT.
  2. Turn the toggle on and choose DoH or DoT.
  3. Choose Enter DNS Server Address, not the preset list.
  4. DoH: https://dnsdoh.art/dns-query
    DoT: dnsdoh.art
  5. Tap Detect, then Save.

Default Mode falls back to unencrypted DNS if we are unreachable; Secure Mode does not, and drops the internet instead. TP-Link's own guide.

Synology SRM

DoH Ready
  1. On SRM 1.3+: Network Center → Local Network → Network, pick your network, then Edit → General. On SRM 1.2 it is Local Network → General directly.
  2. Advanced Options → check Enable DoH.
  3. Click Custom.
  4. DoH URL: https://dnsdoh.art/dns-query

DoH needs SRM 1.2.3 or later. If it appears on but nothing is encrypted, Synology's own checklist is the place to start: the router has to be the client's DNS server, no other DNS servers set on the client, the router the only DHCP server on the network, and the DNS Server package must not be installed on it. Path and versions from Synology's DoH troubleshooting article; we have no Synology router here.

FRITZ!Box

DoT Ready
  1. Internet → Account Information → the DNS Server tab.
  2. Tick Use other DNSv4 servers and put 194.180.189.33 in Preferred DNSv4 server.
  3. Tick Encrypted name resolution in the internet (DNS over TLS).
  4. In Resolved Names of the DNS Server, enter dnsdoh.art - one name per line.
  5. Click Apply and confirm on the box if it asks.

Two things AVM tells you that are easy to miss. Alternative DNSv4 server is a real second resolver, not a spare copy of the first - whatever you put there sees those queries, and leaving it empty means no fallback if we are unreachable. And Failover to public DNS servers when DNS disrupted does what it says: it leaves us for public servers when resolution breaks.

It is never exclusively your resolver. AVM states plainly that the FRITZ!Box always uses the internet provider's own DNS servers for internet telephony, push service mails and several other functions, whatever you set here. That is a property of the box, not of the resolver you point it at - and it is the honest reason a FRITZ!Box alone cannot put every lookup on an encrypted path. Steps and field names from AVM's own knowledge base; we have no FRITZ!Box here.

TP-Link Archer

DoT / DoH
  1. Open Advanced → Network → Internet.
  2. DNS Privacy: choose DoT or DoH.
  3. DNS Mode: Ultra Secure Mode uses only the server you name; Default Mode falls back to unencrypted if it is unreachable.
  4. Type into the first DNS Server box:
    DoT: dnsdoh.art
    DoH: https://dnsdoh.art/dns-query
  5. Press Detect DNS Server, then save. The two extra boxes are optional and can stay empty.

Verified on an Archer AX72 Pro (AX5400), firmware 1.4.5. Once DoT or DoH is on, the router's Primary and Secondary DNS fields stop taking effect - TP-Link says so on the same page, and it catches people out. AC-series models offer DoH only. TP-Link's DoH/DoT guide for the wireless routers, which also warns that Ultra Secure Mode stops resolving outright if the servers it names go unreachable.

MikroTik (v7+)

DoH CLI

Paste these into your MikroTik terminal, in this order:

# 1. the root our certificate chains to /tool fetch url="https://letsencrypt.org/certs/isrg-root-x2.pem" /certificate import file-name=isrg-root-x2.pem passphrase="" # 2. so the router can resolve us before DoH is up /ip dns static add name=dnsdoh.art address=194.180.189.33 # 3. now turn it on /ip dns set use-doh-server="https://dnsdoh.art/dns-query" verify-doh-cert=yes

Order matters. verify-doh-cert=yes checks the server against RouterOS's /certificate list, which is empty on a fresh router - MikroTik's own DNS documentation says to import the DoH server's root CA. Ours chains to ISRG Root X2 (leaf, then Let's Encrypt YE2, then ISRG Root YE, then X2), so that is the one to import. The static entry solves the other half: without it the router cannot resolve dnsdoh.art to reach the DoH server in the first place.

Syntax is from MikroTik's property table for use-doh-server and verify-doh-cert; we have no RouterOS device here, so unlike the Linux steps it is not something we ran ourselves.

OpenWrt

DoH via HTTPS-DNS-Proxy
# OpenWrt 25.12 and later apk update && apk add https-dns-proxy luci-app-https-dns-proxy # OpenWrt 24.10 and older opkg update && opkg install https-dns-proxy luci-app-https-dns-proxy # In LuCI: Services → HTTPS DNS Proxy → Add # URL: https://dnsdoh.art/dns-query

OpenWrt replaced opkg with apk in 25.12. You can tell which you have from the repository itself: 25.12 serves .apk packages, 24.10 serves .ipk. If apk is not found, you are on the older branch and the second line is yours.

Plain IPv4, for routers with no encrypted option

Filtering and ad blocking work exactly the same. What you do not get is encryption: your ISP can still read the queries in transit. Every device behind the router is covered.

Xiaomi / Redmi
  1. Open 192.168.31.1 and sign in.
  2. Advanced Settings → Network → DNS.
  3. Choose Manual DNS and enter the address below.

We have not found an encrypted DNS setting in Xiaomi's router firmware, so this is the route on the router itself. If yours has one, it will be in the same DNS section - and if not, encrypt on the devices instead.

Netgear, D-Link, Linksys, Huawei, Tenda, Zyxel, and every other brand

We cannot test every router, and the menus move between models and firmware versions of the same brand, so we are not going to describe screens we have not seen. Use the manual for your exact model, from the manufacturer, and find its DNS section - that is the one source that is right for the box in front of you.

The admin console is typically 192.168.1.1 for Netgear and Linksys - Netgear also answers on routerlogin.net - and 192.168.0.1 for D-Link. Write down whatever DNS addresses are already in those fields before you change them.

Primary DNS
194.180.189.33
Secondary DNS
Leave empty or 0.0.0.0

Also the fallback for any router whose encrypted DNS setting only accepts providers from a built-in list.

How to tell which kind you have, on any brand. Open the DNS page and read the field names. Anything saying DNS over TLS, DNS over HTTPS, DNS Privacy, Encrypted DNS or Secure DNS means the router can do it itself, and the cards above show the shape it takes. A single box marked Primary DNS with nowhere to enter a hostname or a URL means plain DNS is all the router offers - use the address above, and encrypt on the devices that matter.

Check it from a device behind the router

A router gives you nowhere to read the result, and several of the firmwares above accept a server that never gets used. So test from a laptop or phone on that network, with no DNS set on the device itself - whatever answers is coming from the router.

# Linux or macOS dig dnsdoh.art A +short # Windows nslookup dnsdoh.art

Then open the DNS leak test in a browser on the same network: it should report our upstreams rather than your provider's. That tells you the router is forwarding to us. Whether it is doing so encrypted is a separate question, and only the router's own status page can answer it - which is why the firmwares that show a connection state are worth preferring.

Smart TVs & Game Consoles

PlayStation, Xbox, Nintendo Switch, and most Smart TVs do not support encrypted DNS natively. The best option is to configure DoH/DoT on your router (above) - every device on your network is then covered automatically. Alternatively, set 194.180.189.33 as the Primary DNS in the device's own network settings: unencrypted, but you still get ad-blocking and filtering.

Android Configuration

Enable Private DNS to encrypt all DNS traffic on your device - both Wi-Fi and mobile data.

Step 1: Find the Setting

Stock Android / Pixel

Settings → Network & Internet → Private DNS

Samsung (OneUI)

Settings → Connections → More connection settings → Private DNS

Xiaomi (MIUI / HyperOS)

Settings → Connection & sharing → Private DNS

Oppo / Realme / OnePlus

Settings → Connection & sharing → Private DNS

Step 2: Enter Hostname

Select Private DNS provider hostname.

Enter the following hostname exactly:

dnsdoh.art

Tap Save. A small lock icon may appear in the status bar confirming Private DNS is active.

How to Verify

Open your browser and visit our DNS Leak Test. You should see servers from our encrypted upstreams - typically Cloudflare or Quad9, sometimes Google - not your ISP's DNS. Android uses DNS-over-TLS (port 853), which encrypts all traffic system-wide. On a VPN, check that the lookups still come from us - see does your VPN leak DNS.

What you get, and what you do not

Private DNS is DNS-over-TLS on port 853 - measured on the wire, and it covers every app on the phone, on Wi-Fi and on mobile data alike. That is a proper encrypted transport and it is what the mainstream gets.

Android does not offer DoH, DoQ or DoH3 system-wide, and no server can change that: the resolvers Android will discover on its own are compiled into the operating system. If you specifically want DNS-over-HTTP/3, the route is a browser you already have - see the . It covers browsing only, so most people are better served leaving Private DNS on.

Troubleshooting

"Couldn't connect" - Some networks (corporate, school, hotel Wi-Fi) block DNS-over-TLS on port 853. Switch to the Wi-Fi's DNS while on that network, or use a VPN.

Setting keeps resetting - Some Samsung devices reset Private DNS after reboot. Go to Settings → Battery → Battery Optimization and exclude the Settings app.

Android TV / Google TV

Private DNS also works on Android TV 9+ and Google TV devices (Chromecast, Nvidia Shield, Sony, TCL, Philips): go to Settings → Network & Internet → Private DNS (the exact path varies slightly by manufacturer), choose Private DNS provider hostname, and enter dnsdoh.art.

Configuration Profile (Recommended)

One-tap setup for iPhone, iPad, and Mac. Installs a system-wide encrypted DNS profile that works on both Wi-Fi and cellular data - something manual DNS settings in iOS cannot do.

Download Profile

.mobileconfig · DNS over HTTPS · ~2 KB

What the profile configures:

✓ DNS over HTTPS → https://dnsdoh.art/dns-query

✓ Works on all networks (Wi-Fi + Cellular + VPN)

✓ Ad & tracker blocking via server-side filters

✓ No app required - uses Apple's native DNS framework

Automatic discovery: iOS 16+ and macOS 13+ support DDR (RFC 9462). When a network assigns our resolver 194.180.189.33 as its plain DNS server, the system can discover the encrypted endpoint and verify it against a certificate that carries the resolver IP, with no configuration at all. The profile above is still the recommended setup because it follows you onto every network, including cellular. Details: how devices discover encrypted DNS.

Apple notes one limit worth knowing if you run your own resolver: DDR does not work when the DNS server's address is a private one such as 192.168.x.x, because private addresses cannot be put in a TLS certificate - nobody can prove they own them. That is why the resolver being discovered has to sit on a public address.

The install screen will say "Unverified", in red. That is expected. It means the profile carries no code-signing signature, not that anything is wrong with it or with the resolver. Signing a profile needs a certificate bought for that purpose, and we do not have one. What you can check instead is where the file came from: it is served over HTTPS from dnsdoh.art, the same domain it configures, and it is a 2 KB plain-text file you can open and read before installing. It sets one DNS server and nothing else.

iPhone & iPad

Step 1 - Download

Tap Download Profile above in Safari. You'll see a prompt: "This website is trying to download a configuration profile." Tap Allow.

Step 2 - Install

Open Settings → General → VPN & Device Management. Tap DNSDOH.ART DNS → Install. Enter your passcode when prompted.

Step 3 - Verify

Go to Settings → General → VPN & Device Management → DNS. You should see DNSDOH.ART as the active DNS provider.

macOS (Sequoia / Sonoma / Ventura)

Step 1 - Download

Click Download Profile above. The file dnsdoh.art.mobileconfig saves to your Downloads folder.

Step 2 - Install

Double-click the file. Open System Settings → Privacy & Security → Profiles. Select DNSDOH.ART DNS → click Install.

Step 3 - Verify

Open System Settings → Privacy & Security → Profiles. DNSDOH.ART DNS listed there is the confirmation that it installed.

Do not judge it from scutil --dns. That command prints Apple's dnsinfo structure, whose fields are nameserver addresses, search domains, flags, timeout and order - there is no field in it for a DoH URL, so an encrypted profile's template cannot appear there whether or not it is working. Same trap as Get-DnsClientDohServerAddress on Windows. To check that lookups really are ours, use the leak test below.

How to remove the profile

iPhone/iPad: Settings → General → VPN & Device Management → DNSDOH.ART DNS → Remove Profile.

macOS: System Settings → Privacy & Security → Profiles → DNSDOH.ART DNS → remove (−).

Your device will instantly revert to your network's default DNS.

Alternative: DNSecure App

If you prefer an app to quickly toggle encrypted DNS on/off or manage multiple DNS providers, DNSecure is a free app for iPhone, iPad and Mac, published under the MIT licence.

1. Install

Download DNSecure from the App Store.

2. Add Server

Open the app → tap + → select DNS over HTTPS.
Enter URL: https://dnsdoh.art/dns-query

3. Activate

Toggle the server on. iOS will ask to allow a VPN configuration - tap Allow. On macOS the last step is elsewhere: System Settings → Network → Filters, then enable DNSecure. All DNS traffic is now encrypted.

Troubleshooting

Q:

"This network is blocking encrypted DNS traffic"

Some corporate/hotel Wi-Fi networks block DoH. This is expected - the network administrator requires you to use their DNS. On cellular data, the profile will continue to work normally. You can also try switching to DNS over TLS (port 853), which some networks don't block.

Q:

Profile doesn't appear in Settings after download

Make sure you opened the download link in Safari, not Chrome or Firefox. Third-party browsers cannot install configuration profiles on iOS. If using macOS, double-click the .mobileconfig file to trigger the install prompt.

Q:

Does it work with iCloud Private Relay?

No - Private Relay overrides custom DNS profiles. If you use Private Relay, it handles DNS internally via Apple's servers. You must choose one: Private Relay or DNSDOH.ART. For ad blocking and custom filtering, disable Private Relay and use our profile instead.

Q:

Can I use this alongside a VPN?

It depends on the VPN. Most commercial VPNs (NordVPN, ExpressVPN, Mullvad) override DNS settings when active. When the VPN disconnects, the DNSDOH.ART profile takes over again automatically. WireGuard-based VPNs can be configured to use your DNS alongside.

Apple TV (tvOS)

tvOS has no on-screen setting for encrypted DNS. The practical route is to configure DoH on your router (see the Routers tab) so the Apple TV is covered automatically. Advanced users can install the same configuration profile via Apple Configurator from a Mac.

Windows 11

Native DoH

Windows 11 supports DNS-over-HTTPS natively - everything is done in Settings, no command line needed.

New: automatic setup (verified discovery)

Windows 11 can now find the encryption by itself. Enter only the DNS server address (steps 1-4 below): Windows sends the resolver one discovery query (DDR, RFC 9462), checks that the answer is backed by a certificate carrying our resolver IP, and fills the DoH template https://dnsdoh.art/dns-query in on its own.

Windows then resolves over DNS-over-HTTPS on TCP port 443 - measured on Windows 11 with fallback to unencrypted turned off. Windows has no system-wide DoH3 or DoQ, and advertising them cannot change that.

If that template appears automatically, verified discovery worked and steps 5-6 are already done for you. How it works: how devices discover encrypted DNS.

Configure DNS in Settings

1. Open Settings → Network & internet → Ethernet (or Wi-Fi → your network → Hardware properties).

2. Find DNS server assignment and click Edit.

3. Change from Automatic (DHCP) to Manual and turn on IPv4.

4. Preferred DNS: 194.180.189.33

5. Preferred DNS encryption: Encrypted only (DNS over HTTPS)

6. DNS over HTTPS template: select Manual Template and enter
https://dnsdoh.art/dns-query

7. Click Save.

No template field? (original Windows 11, 21H2)

On the first Windows 11 release the Settings UI only offered the built-in providers. Register our server once via PowerShell as Administrator, then repeat the steps above:

Add-DnsClientDohServerAddress -ServerAddress "194.180.189.33" -DohTemplate "https://dnsdoh.art/dns-query" -AllowFallbackToUdp $False -AutoUpgrade $True

How to Verify

Open PowerShell and run: Resolve-DnsName google.com | Select-Object Name,Type,IPAddress
Or visit DNS Leak Test - you should see servers from our encrypted upstreams - typically Cloudflare or Quad9, sometimes Google. If you see your ISP's DNS instead, the setup isn't active yet.

Windows 10

No Native DoH

Windows 10 has no built-in encrypted DNS - the Settings app only accepts plain DNS servers. You have two choices: plain DNS (simple, unencrypted) or a small helper app for full DoH encryption.

Option A: Plain DNS (No Encryption)

Ad blocking and filtering work, but your ISP can still see your queries.

  1. Control Panel → Network and Sharing Center.
  2. Change adapter settings → right-click your adapter → Properties.
  3. Select Internet Protocol Version 4 (TCP/IPv4) → Properties.
  4. Select Use the following DNS server addresses.
  5. Preferred DNS: 194.180.189.33 - leave Alternate empty.
  6. Click OK, then run ipconfig /flushdns in a command prompt.

Option B: Encrypted DoH (Free Software)

Two free ways to get the encryption Windows 10 itself lacks:

Browser DoH EASIEST

Chrome, Edge, and Firefox have built-in DoH - covers browsing only. See the .

dnscrypt-proxy SYSTEM-WIDE

Free, open-source local resolver. Install from GitHub and add https://dnsdoh.art/dns-query as a DoH server in dnscrypt-proxy.toml.

systemd-resolved (Ubuntu / Debian / Fedora / Arch)

The default DNS resolver on most modern Linux distributions. Supports DNS-over-TLS natively.

On Debian, check it is there first

Ubuntu ships systemd-resolved and turns it on. Debian does not - it is a separate package that a default install leaves out, so resolvectl answers command not found and there is no service to restart. Checked on Debian 12: no resolvectl, and zero systemd-resolved unit files.

# installs resolvectl and the service if they are missing command -v resolvectl || sudo apt install systemd-resolved

If nothing else manages /etc/resolv.conf on that machine, point it at the stub afterwards: sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf. Leave it alone if NetworkManager, Tailscale or your VPN writes that file - they will overwrite it anyway.

# Edit the resolved config sudo nano /etc/systemd/resolved.conf # Under [Resolve], all three lines: [Resolve] DNS=194.180.189.33#dnsdoh.art DNSOverTLS=yes Domains=~.
# Restart the service sudo systemctl restart systemd-resolved # Verify it's working resolvectl status | grep -E 'Protocols|DNS Server'

The Global block should list 194.180.189.33 under DNS Servers, and its Protocols line should read +DNSOverTLS - the two facts sit on separate lines, which is why the filter above keeps both.

Do not skip Domains=~.

Without it the setting looks right and half your lookups still leave in the clear. systemd's own manual for DNS= says these requests are sent "in parallel to suitable per-link DNS servers" - the ones your router hands out over DHCP. The routing domain ~. makes your server the one used for every name instead.

So read resolvectl status in full, not just the Global block. Any link below it showing +DefaultRoute together with its own DNS Servers line is still answering queries.

Why the name after the #. With a bare address, resolved checks the certificate against the IP; with #dnsdoh.art it validates the name and sends SNI. Both work here - our certificate carries IP Address:194.180.189.33 among its SANs - and the second is the one to prefer.

Yes means strict. If port 853 is blocked on the network you are on, name resolution stops rather than quietly falling back. DNSOverTLS=opportunistic falls back instead, which the same manual notes can be downgraded by a forged response.

NetworkManager (Desktop GUI)

For GNOME, KDE, and other desktop environments with a network manager GUI.

Step 1

Open Settings → Network → click the gear icon next to your connection.

Step 2

Go to the IPv4 tab. Set DNS to Manual. Enter: 194.180.189.33

Step 3

Click Apply. Toggle the connection off and on to activate.

Note: NetworkManager does not support DNS-over-TLS natively. For encrypted DNS, use the systemd-resolved method above or install stubby.

Stubby (Advanced - Any Distro)

A dedicated DNS-over-TLS resolver. Works on any Linux distribution, even older ones without systemd-resolved.

sudo apt install stubby # Debian/Ubuntu sudo dnf install stubby # Fedora

Installing it also starts it, already pointed at the upstreams the package ships with. The next step is what changes that, so do it before you judge whether anything works.

# Edit /etc/stubby/stubby.yml. REPLACE the whole existing # upstream_recursive_servers: block with these three lines: upstream_recursive_servers: - address_data: 194.180.189.33 tls_auth_name: "dnsdoh.art"
sudo systemctl restart stubby # Confirm it answers before you rely on it dig @127.0.0.1 example.com A +short # Then set your system DNS to 127.0.0.1 (stubby listens locally)

Replace the list, do not add to it

The shipped stubby.yml already carries six upstreams of its own - three operators over IPv4 and IPv6 - and sets round_robin_upstreams: 1. Append a seventh entry and most of your queries go to somebody else.

Measured on Debian 12, n=10 each: with our server as the only upstream, 10 of 10 lookups answered, median 108 ms. With our entry appended to the shipped list instead, 8 of those 10 took about 5 seconds, because two of the shipped addresses would not accept a connection on port 853 from that host at all.

Stubby runs its strict profile by default (tls_authentication: GETDNS_AUTHENTICATION_REQUIRED) and logs Verify passed : TLS against our certificate - unlike kdig, which has its own trouble with it. It listens on 127.0.0.1 port 53, so the last step only works if nothing else holds that port: sudo ss -lntup | grep ':53 ' tells you.

Confirm it actually worked

Changing a setting is not the same as the setting taking effect, and encrypted DNS fails quietly: everything keeps working, it is just not encrypted. Three ways to check, from easiest to most conclusive.

1. In a browser, on any device

Open the DNS leak test. It mints a name that has never existed, so the lookup has to reach our own nameserver, and it reports which resolver arrived. You should see our upstreams - Cloudflare or Quad9 - and not your provider. What it cannot tell you is whether the query travelled encrypted; that is a separate check, one per protocol.

2. On Windows, the system tells you outright

Open Network & internet, pick the adapter, and read the line for the DNS server. If encryption is in effect it says so in as many words:

IPv4 DNS servers: 194.180.189.33 (Encrypted)

In Edit DNS settings the DNS over HTTPS dropdown will read On (automatic template) with the template filled in for you, or On (manual template) if you typed it. Either is fine; Off means your lookups are still in the clear. Do not judge this from PowerShell - Get-DnsClientDohServerAddress lists only the servers Windows ships with and stays silent about a discovered template.

3. From a terminal, one command per transport

This proves the endpoints answer for you, from your network, which is the useful thing to know before blaming a device. q is a small DNS client that speaks all of them; dig and curl cover the rest.

$ dig @194.180.189.33 example.com A +short          # plain, port 53
104.20.23.154

$ q -t A example.com @tls://dnsdoh.art --short    # DoT, port 853
104.20.23.154

$ q -t A example.com @quic://dnsdoh.art --short   # DoQ, port 853/UDP
172.66.147.243

$ curl ... /dns-query?dns=...                      # DoH
DoH  200 http/2
DoH3 200 http/3

If one of these fails while the others answer, the transport is being blocked on your network rather than misconfigured on your device - port 853 is the usual casualty, which is why DoH on 443 is the safest first choice.

If the check names a resolver you never configured

A VPN or mesh client can take DNS over after you have set it up, and none of them say so on screen. Tailscale is the common case: accept DNS configuration is on by default, so joining a tailnet makes it write /etc/resolv.conf and put its own forwarder at 100.100.100.100 in front. Lookups go there and on to whatever resolver the tailnet specifies, and the encrypted resolver you configured stops being used. The only notice is a comment in resolv.conf. Checking whether accept DNS configuration replaced your resolver shows the three commands that reveal where queries really go, and how to keep MagicDNS and encrypted DNS at once.

After setup

Verify it works

Run a DNS leak test - you should see our encrypted upstreams, not your ISP.
Troubleshooting

"Couldn't connect" on a network that blocks port 853 - the answer opens in the knowledge base, with the broken-site case right below it.
How it works

The protocols behind each option, with benchmarks and trade-offs.
What it doesn't cover

Encrypting DNS hides your lookups, not your IP address or browser fingerprint - see what a site still reads.