Print-nameservers: Samba-DC IP not filtered from forwarder list, causing DNS loopback after core update

Support
,
1

Introduction

I’d like to share a recurring issue I encountered on my NS8 installation, which I investigated and resolved with the help of Claude (Anthropic’s AI assistant). I’m posting this here in case it reflects a structural problem worth fixing upstream — but if this turns out to be a misconfiguration on my end, I’d equally welcome guidance from the community or support team.

The issue reproducibly reappears after every NS8 core update, which suggests the fix belongs in the codebase rather than as a manual post-update patch.

@davidep @giacomo — tagging you as the relevant contributors based on recent core changes.

Bug Report / Community Post for NethServer

Observation

After every NS8 core update, DNS resolution on the host becomes slow (3–5 seconds per query) or fails entirely with timeouts. The symptom appears immediately after the update and persists until manually corrected. Affected services include all containers using --network=host, rclone/restic backup, and Redis connectivity.

ss -tulpn | grep :53 shows dns[master] bound to the Samba-DC IP on the host, but queries to that IP time out or respond with high latency.

Suspected Root Cause

/home/samba1/.config/bin/print-nameservers reads /etc/resolv.conf via Python’s dns.resolver.Resolver() and passes all listed nameservers to Samba-DC as DNS forwarders. If the Samba-DC’s own IP (e.g. 172.17.0.235) is listed in /etc/resolv.conf — which is a valid and intentional configuration when containers need to resolve internal split-horizon zones — Samba-DC sets itself as a forwarder, creating a DNS loopback.

Contributing Factor / Possible Misconfiguration

It is acknowledged that the initial network configuration used DHCP, which may have populated /etc/resolv.conf with nameserver entries that were later manually adjusted. However, having the Samba-DC IP as the primary nameserver in /etc/resolv.conf is a legitimate and recommended setup for NS8 nodes hosting a Samba-DC — it enables internal split-horizon DNS resolution for all host-network services. The loopback risk therefore exists in any standard NS8 deployment where the node also runs Samba-DC.

Additionally, print-nameservers is overwritten on every core update, meaning any manual patch is lost silently.

Fix Applied

Patched /home/samba1/.config/bin/print-nameservers to filter out the Samba-DC’s own IP from the forwarder list:

import dns.resolver
rsv = dns.resolver.Resolver()
filtered = [ns for ns in rsv.nameservers if ns != 'my.networl.0.ip']
print(" ".join(filtered))

Proposed Solution

The print-nameservers script should natively exclude any IP listed in Samba’s own interfaces directive from the forwarder list. These IPs are already known from smb.conf and can be filtered dynamically. A self-referencing DNS forwarder loop cannot be intentional in any deployment scenario and should be structurally prevented rather than requiring manual post-update patches.

2 Likes
2

The Samba DNS should NOT be added to /etc/resolv.conf as it causes loops, see System requirements | NethServer 8 documentation

Why do you need it?

3

You may not imagine, how often I tried / tried without …

The reason a Samba-DC IP must be listed in /etc/resolv.conf: Podman containers running with --network=host (restic, rclone) inherit /etc/resolv.conf from the host. Without the Samba-DC as the first nameserver, these containers cannot resolve internal split-horizon zones. External nameservers have no knowledge of these internal zones.

This is not a misconfiguration but an architectural requirement when running split-horizon DNS combined with --network=host containers on the same node as the Samba-DC.

The documentation warning is correct for standard deployments — but does not apply to installations using internal split-horizon DNS.

To be more precise my Synology NAS (running MiMO S3) has two routes via Traeffic to is ip other than the NS8 leader node itself, required for restic / rclone to circumvent “can not run without SSL” - I spent hours in this to get a reasonable backup

4

Could you please provide an example/use case?
I just do not understand why another container needs the internal Samba DNS.

5

see above (edit):slight_smile:
To be more precise my Synology NAS (running MiMO S3) has two routes via Traeffic to is ip other than the NS8 leader node itself, required for restic / rclone to circumvent “can not run without SSL” - I spent hours in this to get a reasonable backup

1 Like
6

So the full story ist:

I wanted some backup (we discussed it) besides NS8 itself … manual iscsi would have been a solution, but again on the internal replacement app of MiMo (sorry, forgot its name) ist not a "full external solution. Also iscsi is manual work and nfs does not work either … really annyuing (sorry to be honest, but here, NS8 should include such basic features from the GUI) … Anyway I decided for my Synology (we discussed it, too), as I do not want to pay Amazon (I had that for NS7 and und became reasonably expensive every month) … but the price is the requirement for SSL - here I had to have the Traffic route …

But if you look how Claude solved it - it seems not to be “non standard” and the the three lines in the code do not seem to be a big issue :slight_smile:

7

What about adding the needed DNS entry for the Synology NAS to /etc/hosts of the NS8 node?

I’m not sure about the proposal because the documentation also recommends to not mix DNS servers from different scopes in /etc/resolv.conf:

Do not mix DNS servers from different network scopes, for example, 1.1.1.1 (public, Cloudflare) and 192.168.1.1 (private). Doing so can lead to inconsistent DNS query results.

1 Like
8

Thank you for the hint regarding the documentation, and noted on the 1.1.1.1 entry — it is a leftover from early troubleshooting and will be removed.

To clarify why the Samba-DC IP is in /etc/resolv.conf: Podman containers running with --network=host (restic, rclone) inherit /etc/resolv.conf from the host. Without the Samba-DC as the first nameserver, these containers cannot resolve internal split-horizon zones. External nameservers have no knowledge of these zones. This is an architectural requirement, not a misconfiguration.

Regarding the loop itself: I come from a GMP-regulated environment (pharmaceutical industry), where we follow the principle that technical controls must be the first line of defence against recurring deviations — organisational measures like “remember to re-apply the patch after every update” are explicitly the last resort.

From that perspective, the current behaviour of print-nameservers — blindly forwarding all entries from /etc/resolv.conf including the Samba-DC’s own IP — represents a structural risk. The fix is straightforward: filter out IPs listed in Samba’s own interfaces directive before passing them as forwarders. A self-referencing DNS forwarder loop cannot be intentional in any deployment scenario.

The patch we applied:

import dns.resolver
rsv = dns.resolver.Resolver()
filtered = [ns for ns in rsv.nameservers if ns != '172.17.0.235']
print(" ".join(filtered))

A more robust version would derive the excluded IPs dynamically from smb.conf rather than hardcoding them.

9

and yes, A-Records would solve als well, as one root cause is the wildcard record for split horizon, but I would like to avoid manual maintanence which I allready do for hosts not at the leader node

10

I still have doubts about the proposal as the documentation is based on user experiences and I’m afraid of negative side effects when adding samba DC or 127.0.0.1 to /etc/resolv.conf but let’s wait for other opinions…

Sorry for asking again but I don’t get it. Which container needs to resolve all internal hosts? I think it’s just about the Synology DNS entry to be able to find the backup device, isn’t it?

Even containers without host network inherit the /etc/resolv.conf.

1 Like
11

Thank you for the feedback, and thanks for taking the time to look into this — I really appreciate the support from this community!

I agree on you, however, I would like to point out a little and underline my argument :innocent:

I’d like to share two references that might help clarify why the Samba DC IP ends up in /etc/resolv.conf in the first place, and why I believe the issue might be worth a closer look upstream.

Samba Wiki (Linux and Unix DNS Configuration):

“Set the DNS server IP and AD DNS domain in your /etc/resolv.conf.”

This is the documented standard for any host running or joined to a Samba AD DC.

Ubuntu Server documentation (Provisioning a Samba AD DC) actually describes our exact situation and its root cause really nicely:

“First, adjust dns forwarder in /etc/samba/smb.conf to point at your DNS server. The provisioning script simply copied the server IP from /etc/resolv.conf to this parameter, but if we leave it like that, it will point back to itself.”

This is exactly what print-nameservers does on every core update — it passes nameserver entries from /etc/resolv.conf directly into the Samba forwarder configuration, recreating the self-referencing loop that Ubuntu’s own documentation explicitly warns about.

So the Samba DC IP in /etc/resolv.conf is not a misconfiguration — it follows the documented standard. The loop arises because print-nameservers doesn’t apply the filter that every Samba setup guide implicitly requires: don’t forward back to yourself.

I’m absolutely open to other perspectives on this — maybe there’s a cleaner architectural solution I’m missing. Either way, thank you again for engaging with this, it’s genuinely appreciated! :blush:

1 Like
12

While in the Samba wiki it’s about configuring Linux clients, the Ubuntu server documentation really recommends adding the Samba DNS to /etc/resolv.conf on the server side.
Thanks for the pointer to the Ubuntu docs.

2 Likes
13

I fully agree with Markus’ points.

The Administrator’s Manual intentionally recommends that /etc/resolv.conf contains only external recursive DNS servers, and not DNS services provided by NS8 itself.

Suppose we changed the documentation and allowed the local Samba DC address there.

  • If the Samba DC were the only nameserver, print-nameservers would have to filter it out to avoid a forwarding loop. The result would be an empty list of forwarders, so Samba would no longer be able to resolve public names.
  • If upstream DNS servers were also listed, we would be mixing private and public DNS resolvers. This is something we explicitly discourage because it can lead to inconsistent resolution results depending on which resolver is queried.

For these reasons, I don’t think print-nameservers should implement the proposed filtering behavior. The underlying configuration would still be one we don’t want to recommend.

Going back to the original backup scenario, I think there are a few alternatives:

  1. If possible, use the SMB backend instead of S3. For a Synology server on the same LAN, SMB is generally a better fit and avoids the DNS issue entirely.
  2. Use the Synology’s LAN IP address instead of its AD hostname. Alternatively, add a static entry to the host’s /etc/hosts, as Markus suggested.
  3. Starting with Core 3.20, a new feature allows supplying a fully custom Rclone configuration (documentation is still in progress). This also makes it possible to configure options such as accepting self-signed TLS certificates when required.

To me, these approaches solve the original use case without relaxing the DNS requirements documented for NS8.

1 Like
14

Thank you David, that’s a very helpful breakdown and I appreciate the detailed explanation!

One clarification on the LAN IP suggestion: in my case, the MinIO instance on the Synology runs on plain HTTP without a valid TLS certificate. The NS8 backup module requires HTTPS, so using the LAN IP directly unfortunately doesn’t work here — rclone defaults to HTTPS when no protocol prefix is specified, which causes a silent TLS handshake failure against an HTTP-only endpoint.

The current working solution routes the S3.mydomain.tld endpoint through Traefik on the NS8 node, which handles TLS termination with a valid Let’s Encrypt certificate — which is why DNS resolution of that internal hostname on the host matters.

One small thought for the future: it would be wonderful if the NS8 documentation on DNS configuration could align with the recommendations from the Ubuntu Server docs, which explicitly guide users to place the Samba DC IP in /etc/resolv.conf. I understand the reasoning behind NS8’s current recommendation, but having diverging guidance between upstream Samba/Ubuntu and NS8 can be a source of confusion — especially for users coming from a standard Samba setup. Just a gentle thought, no pressure at all! :blush:

That said, the new custom Rclone configuration feature in 3.20 sounds very promising for this exact scenario, especially with options for accepting self-signed certificates or specifying the protocol explicitly. I’ll wait for the documentation and explore that path. Thanks again to you and Markus for the patience and thorough discussion! :blush:

1 Like
15

The Ubuntu Server documentation applies to provisioning the Samba AD DC itself, and that’s exactly what our Samba DC container already does through print-nameservers. However, those recommendations do not apply to the NS8 host, which has different requirements that are documented in the Administrator’s Manual. The host must remain independent from DNS services provided by NS8 applications.

Considering the current S3/TLS limitations of Core 3.19, they are another reason to use SMB for LAN backups. As already said, for users who need S3, Core 3.20 introduces a fully custom Rclone configuration that should cover scenarios like yours.

Since we cannot implement the proposed DNS change for the reasons discussed above, I’m changing this topic from Bug to Support.

16

Understood, but it hard to explain and what somehow happend - and I really do not understand: It looks like the DNS breaks out - I got multiple instances running on port 53 - here I am to short on explanaition. I had to kill processes which then restarted outside the container … absolutly unclear to me … and why I came to that workarround.

17

That behavior is unexpected. I’d suggest first bringing the node back to the supported DNS configuration and then verifying whether the original backup issue still exists.

  1. Remove any local node IP address(es) from /etc/resolv.conf, leaving only external recursive DNS servers.
  2. Restart the Samba DC so it regenerates its forwarder configuration:
runagent -m sambaXXX restart samba-dc

Replace XXX with your Samba application ID. You can find it with:

runagent -l | grep samba

At that point, the backup may fail if it can no longer resolve the Synology hostname. If that happens:

  • If possible, switch to the SMB backend and use the Synology LAN IP address instead of S3.

  • Otherwise, add the Synology hostname and IP address to the node’s /etc/hosts file. Since you’re routing the traffic through Traefik to work around the TLS certificate issue, I also recommend restarting Traefik during non-working hours:

     runagent -m traefik1 systemctl --user restart traefik

Finally, run the backup again and let us know the outcome. The information about the DNS processes appearing outside the container is interesting, but I’d first like to verify the behavior with the node in a supported configuration.