• 

  Eric Nix

  • March 06, 2026 17:19
  • Edited

  

  If I already have a relay.conf file in a directory, how do I edit the config to load the relay.conf into the new installation?  Is there a directory I should copy the relay.conf file?
  
  UPDATE:  I was able to copy it to /root/.relay/binary and it loaded the relay.conf.

  Kudos for developing this.  It makes it much easier to maintain the relay!  Love the options to simply run an update with relay-manager instead of needing to manually copy the relay, edit permissions, etc.  Great job DNSFilter team!

  0
• 

  Minetta Gould Community Team DNSFilter Staff

  • March 06, 2026 19:46

  Thanks for the kind words, Eric Nix! The team is really proud of this one, so glad you're enjoying it so far—I passed along your message to the whole company 💖

  And…you found a bug 🐛 😅
  
  The expected behavior for the Relay Manager should be a bit more intuitive than what you discovered, so the team has a ticket in to address it in the next version release. I'll update this article once the fix releases. 

  In the meantime, I’ve updated the article to note how to copy an existing relay.conf until the fix is implemented. Thanks for making our customer experience better!  

  1
• 

  T

  • March 17, 2026 16:56

  [root@perfecthost bin]# ./relay-manager config edit
Failed to edit config: exec: "nano": executable file not found in $PATH

  I'm pretty sure that none of ed, nano, nor emacs are installed on this host.
  Please don't add ‘dnf -y nano’ to the hack installer, but please simply detect editors and let us choose if there are more than one available.

  0
• 

  Minetta Gould Community Team DNSFilter Staff

  • March 17, 2026 21:16

  Hi T , thanks for the feedback! Totally understand where you're coming from, so I went ahead and added the feature request on your behalf. Feel free to comment there if I missed anything! 

  0
• 

  Admin

  • March 19, 2026 15:53
  • Edited

  If we are putting this on a server that already has the old relay running, will the relay-manager remove the old entry from systemd and shut it down or do we need to do that manually first? This article sounds like the expectation is to do a clean install. That's fine for Docker people but what about those of us running the binary directly inside a real metal linux install? If we need to first remove the old systemd entry and delete relay-linux-amd64, you should put a note with a link to the old article for people who set it up long enough ago that they forgot how they did it. :)

  0
• 

  Minetta Gould Community Team DNSFilter Staff

  • March 19, 2026 22:09

  Great question, Admin! No need to shut down the existing relay first—if you copy the existing binary into the Relay Manager, it'll take over for the existing deployment. We list the pathways to copy the existing relay .conf to help jog your memory 😉

  If you run into any snags along the way, drop a comment here and we'll get you sorted. 🙌

  0
• 

  Admin

  • March 20, 2026 13:29

  It didn't go exactly smoothly. Just out of curiosity, I left the old one in place and ran the script, then `relay-manager install` to see what would happen. When I told it I wanted to use an existing relay.conf in a custom path it didn't seem to let me tell it where to look, but looked for itself and failed to find. Checking status showed no config. At that point, I stopped the old relay using systemctl and then reran the install and acted like it was a fresh install, then edited the config it created. After that, status said the binary in /root/.relay/binary was not running so I edited the old systemd service config file to point to the new path, then had systemd reload all the modules. Finally, it was running and I was able to test it.

  So, from my experience it is best to first stop and disable the old systemd entry, run the script, then run relay-manager to install, then edit the config it creates or copy the old one over top of it and reload everything, then edit the systemd entry to point to the new path, then enable that again. On our second relay, even after doing this, the status still said the proper binary wasn't running and it took another run of the install through relay-manager to get the proper binary running. Very odd but we got there. Note that this is all on Kubuntu 24.04, not straight debian, so I don't know if that was part of the issue with a different version of systemd. Also, the relay-manager install should be checking for an existing dnsfrelay.service and editing the path in there to make it smoother.

  Honestly, the instructions should probably just tell people who want to replace an old install to refer to the old deploy instructions and undo everything they did with systemd to make sure the old one is no longer running or existent before running these steps above. Then they can stop the service using relay-manager, move the old config into place, then start it back up.

  0
• 

  Minetta Gould Community Team DNSFilter Staff

  • March 20, 2026 18:47

  Thanks for the detailed writeup, Admin—and glad you got both relays up and running, even if the road was a little bumpier than expected!

  Your experience is really helpful feedback, and the edge cases you hit around the config path handling and systemd service updates are things we'll be looking into with our engineering team. The Kubuntu note is a good catch too.

  In the meantime, if anyone else lands here mid-migration and gets stuck, the relay-manager status, relay-manager logs, and relay-manager troubleshoot commands are your best friends for figuring out what's going on. 🛠️ 

  **Open a Support Ticket** with these outputs and the team can help get you fixed up!

  0
• 

  Peter Kline

  • April 24, 2026 18:23

  Reminders to save someone else the several hours of time I spent on this. The relay-manager installs the binaries in /root/.relay. Pretty much every Linux distribution will come with selinux installed and running out of the gate. When this is the case, you will find the service will simply not start, and in my case (Alma Linux, a RedHat clone) the service will get stuck at “activating…”. A ‘journalctl -u dnsfrelay’ showed it could not access the binary, but that's because selinux was preventing it. Search how to disable selinux to fix this issue (or audit it to correct the needed access).

  Many sure you open TCP and UDP 53 on your firewall or the queries won't work.

  You seem to have to configure the local domains in the /root/.relay/binary/relay.conf file regardless of what's configured in the web interface. My relay did not pitch internal lookups to the correct DNS servers without doing this. Docker containers will use the appropriate path.

  0
• 

  Minetta Gould Community Team DNSFilter Staff

  • April 24, 2026 21:15

  Thanks for taking the time to document this, Peter Kline—these are genuinely helpful callouts! 🙌

  And yes, to confirm: local domain configuration for Relays is handled directly in the relay.conf file, not through the dashboard. Here's the relevant article for reference for those following along.  

  0

Please sign in to leave a comment.