How to Set Up Your Own NextDNS Profile on Fedora 43 (No Router Rules!) 🏆

This quick guide shows how to give your Fedora workstation its own personal NextDNS profile — globally enforced via a clean systemd-resolved drop-in file using DNS-over-TLS (DoT). No GNOME GUI fiddling, no NetworkManager overrides, no ghosts from Past You.

Perfect for when the router’s DNS is treating you like a naughty 12-year-old, but you just want privacy, ad-blocking, and unrestricted access. 😎

Tested with: Fedora 44 · systemd 259 · NetworkManager 1.56.1

Why Bother? (The Personal Profile Win)

My router runs a strict NextDNS config for the boys’ endless Roblox gardens and YouTube black holes.
But my Core i7 Fedora 43 battlewagon? It needed:

• Aggressive privacy + tracker blocking without bedtime schedules
• No game bans or “recreation time” nonsense
• Global enforcement in one config file, so it doesn’t depend on which WiFi network or connection profile I’m on

NextDNS makes this dead simple with unlimited configurations. Create one called mine “Lachie Fed43” (you do you!!), copy its unique DoT endpoint, and wire it directly into systemd-resolved.

Result: lookups that go through resolved head for your NextDNS profile instead of the router’s — the kid filters don’t get to answer them. 🎯

Step-by-Step: Global NextDNS DoT on Fedora 43

1. Get Your Personal NextDNS Endpoint

1. Log into my.nextdns.io
2. Create a new Configuration (or use an existing one for “for the adults”)
3. Go to Setup → Linux (systemd-resolved)
4. Copy your unique DoT endpoint (looks like abc123.dns.nextdns.io)
5. Note the IP addresses listed there too

Device naming tip: NextDNS converts spaces to -- (dashes). “Lachie Fed43” becomes Lachie--Fed43-abc123.dns.nextdns.io.

2. Create the Drop-in Config File

Fire up nano in the systemd-resolved drop-ins directory:

sudo nano /etc/systemd/resolved.conf.d/nextdns.conf

⚠️ This file sits under /etc, so it’s system-level state rather than a dotfile — get it wrong and the whole machine stops resolving, not just your shell. Note what’s already in that directory before you start so you can put it back.

Paste this exact template (replace with your IPs and endpoint):

[Resolve]
#Use NextDNS IP addresses with your unique device identifier endpoint
DNS=45.90.28.0#Lachie--Fed43-abc123.dns.nextdns.io 45.90.30.0#Lachie--Fed43-abc123.dns.nextdns.io
DNS=2a07:a8c0::#Lachie--Fed43-abc123.dns.nextdns.io 2a07:a8c1::#Lachie--Fed43-abc123.dns.nextdns.io

#Enforce DNS-over-TLS
DNSOverTLS=yes

#Route every domain to these servers
Domains=~.

The [Resolve] line is not decoration. systemd reads this as an INI file and every key above belongs to that section — leave the header out and you’ve written orphaned assignments sitting outside any section, which is exactly the config your drop-in won’t apply.

Key bits explained:

• 45.90.28.0#your-endpoint.dns.nextdns.io — the # doesn’t switch encryption on. It attaches a server name to that address, and resolved uses it for TLS Server Name Indication and to check the server’s certificate against that name. DNSOverTLS=yes is the line that turns encryption on.
• Domains=~. — the magic. ~ makes it a route-only domain (a routing hint, not a search suffix) and . is the DNS root, so these servers are the route for every domain. It doesn’t erase the router’s resolver: resolvectl status still lists it under your link, and systemd’s own config notes that DNS= “does not suppress link-specific configuration” — parallel requests still reach the per-link servers.
• IPv4 + IPv6 for maximum compatibility

Save and exit (Ctrl+O, Enter, Ctrl+X).

3. Apply & Restart

Reload the magic:

sudo systemctl restart systemd-resolved

4. Verify It’s Working

Check the global status:

resolvectl status

Under Global, you should see:

Protocols: LLMNR=resolve -mDNS +DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 45.90.28.0#Lachie--Fed43-abc123.dns.nextdns.io
DNS Servers: 45.90.28.0#Lachie--Fed43-abc123.dns.nextdns.io 45.90.30.0#Lachie--Fed43-abc123.dns.nextdns.io 2a07:a8c0::#Lachie--Fed43-abc123.dns.nextdns.io 2a07:a8c1::#Lachie--Fed43-abc123.dns.nextdns.io
DNS Domain: ~.

5. Confirm on NextDNS Dashboard

Visit your NextDNS Setup page — it should cheer:

✅ All good! This device is using NextDNS with this configuration

Device: Lachie—Fed43

You’ll also see real-time logs from your Fedora laptop hitting your personal profile, separate from the router’s kid lockdown.

Troubleshooting: If It Doesn’t Work

Still seeing router DNS?

Nuke any NetworkManager DNS overrides first

nmcli -t -f UUID connection show --active | while IFS= read -r uuid; do
  nmcli connection modify "$uuid" ipv4.dns "" ipv4.ignore-auto-dns no
  nmcli connection modify "$uuid" ipv6.dns "" ipv6.ignore-auto-dns no
  nmcli connection up "$uuid"
done

Iterating over connection names splits them on any space — Home WiFi becomes two words and the modify step fails on both. Keys off UUIDs instead: no spaces, no splitting.

Scope check while we’re here: this only clears what NetworkManager has stored per connection. It deliberately keeps ignore-auto-dns no, so DHCP keeps handing the router’s resolver to resolved — clearing it isn’t the point. The drop-in changes where queries go, not what gets configured.

Ensure no other drop-ins are fighting you

ls /etc/systemd/resolved.conf.d/

Check for ghosts (like my old Cloudflare config):

sudo rm /etc/systemd/resolved.conf.d/99-dns-over-tls.conf # If it exists
sudo systemctl restart systemd-resolved

Test resolution:

dig @45.90.28.0 google.com # plain-DNS reachability: does the endpoint answer?
resolvectl query example.com # transport-aware: did the answer arrive encrypted?

These two check different things. dig @45.90.28.0 talks to that IP over ordinary UDP/TCP, so a reply only proves the endpoint is up and answering DNS — it says nothing about DoT, because dig isn’t using it here. The transport question belongs to resolvectl query:

-- Information acquired via protocol DNS in 16.5ms.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: yes

The second line is the one that matters: local or encrypted transport: yes. authenticated: no answers a different question — DNSSEC-style authentication of the data, which this setup doesn’t enable.

Why This Beats GUI / NMCLI Methods

• Global, not per-connection: one file covers every connection instead of repeating it per WiFi network
• DoT baked in: DNSOverTLS=yes applies to every server in the file, so you never repeat it per entry
• Not router-proof: resolved still learns the router’s resolver from DHCP — resolvectl status keeps showing it on your link — and anything that bypasses resolved (a resolver inside an app, DoH, a VPN) never reads this file. Hard enforcement is a job for the router or for policy, not a drop-in
• Drop-in clean: Easy to backup, version, or remove (sudo rm nextdns.conf)

As a recovering Windows registry tweaker, this felt like coming home. One config file rules them all. No more GNOME Settings → WiFi → IPv4 → “Why isn’t this applying?” loops. 😄

Pro Tips for Power Users

• Multiple profiles? Create separate drop-ins (nextdns-work.conf, nextdns-home.conf) and switch by moving one in or out of the directory — sudo mv /etc/systemd/resolved.conf.d/nextdns-work.conf{,.disabled} — then sudo systemctl restart systemd-resolved. systemctl manages units, and a drop-in isn’t one, so there’s no unit to enable here; the file only counts once resolved reloads.
• Logs & analytics: Watch your Fedora’s unique traffic in real-time on the NextDNS dashboard
• Backup: cp /etc/systemd/resolved.conf.d/nextdns.conf ~/dot-backup.conf
• IPv6-only networks: The IPv6 lines ensure you don’t break

Now my Fedora 43 sips from its own privacy-focused NextDNS well while the router keeps the screen goblins in check. Everyone’s happy. Except maybe Roblox’s bottom line. 🎮🚫

NextDNS FREE Plan has a default allocation of 300k queries pm, I’m using their affiliate link in this article - Just so that I can get few extra DNS Queries added to my account.