Möglicher "Fehler" in der Samba DNS Konfiguration

Während meiner Recherche zu diesem Thema hier, bin ich auf folgendes gestoßen.

In der setup_samba_dc.sh

## Setup DNS-Environment ##################################
hostnamectl set-hostname la
# if la.$DOMAIN is not in /etc/hosts, add it
if ! grep -q "la.$DOMAIN" /etc/hosts; then
    echo "$IP la.$DOMAIN la.$SHORTEND_DOMAIN la" >> /etc/hosts # IP of the server itself
fi

Wir tragen uns erstmal selber in die hosts ein, so weit OK.
Dann unsere IP Adresse in die resov.conf, auch noch OK. Bei einem Windows DC nehme ich die localhost IP und die des Sekundären DCs. Dem Kommentar dahinter entnehme ich Docker braucht die host IP, ich schätze die wird an den container durchgereicht und daher würde 127.0.0.1 nicht funktionieren.

echo "nameserver $IP" >> /etc/resolv.conf # This is the IP of the server itself. Needed for docker containers e.g.
# Check if IP is IPv6 and add appropriate entry to resolv.conf
if [[ $IP =~ : ]]; then
    echo "nameserver 2606:4700:4700::1111" >> /etc/resolv.conf # Google DNS IPv6
else
    echo "nameserver 208.67.222.222" >> /etc/resolv.conf # OpenDNS
fi

Warum dann aber die beiden öffentlich DNS Server?

By the way: Anstatt 2 amerikanische DNS Dienste würde ich in einem datenschutzfreundlichen Projekt wie diesem, hier sowas wie quad nine bevorzugen aber das hat mit dem Problem nichts zu tun, zurück zum Thema.

DNS Anfragen erfolgen nicht zwingend sequentiell, also nicht erst mich selber und wenn der nicht auflösen kann, dann den nächsten in der Liste. Wenn ich mehrere DNS Server angebe sollten die immer die gleichen Informationen liefern.
Der NextHop gehört IMHO also eigentlich nur in die Samba Config, so dass der Host auch immer nur den Samba Dienst fragt, nur so können auch zuverlässig andere Domain Members aufgelöst werden. Wie oben beschrieben macht man das unter Windows genau so. NextHop wird auch da immer im DNS Dienst konfiguriert, nie am Host selber.

# DNS Forwarder (OpenDNS)
export SAMBA_DNS_FORWARDER=$IP

Laut Doku versteht die inzwischen wohl auch mehrere Einträge IPv4 und IPv6. Könnte man hier also mehrfach übergeben.

Je nach Umgebung könnten die externen DNS Server die hier fix eingetragen sind aber auch noch zum Problem werden. Ich habe im DNS meiner Firewall z.B. auch noch Split DNS Einträge. Der NextHop müsste bei mir also meine Firewall sein und nicht ein Public DNS Server. Der würde mir meine Nextcloud nämlich falsch auflösen und jeglichen Traffic über meinen Reverse Proxy jagen obwohl die NC in meiner DMZ lokal zu erreichen ist.
Das dürfte je nach Umgebung also stark variieren. Ob ich z.B. eine FritzBox als Next Hop haben möchte die ihrerseits immer den gefilterten DNS des Providers als NextHop nutz, weiß ich auch nicht so recht. Da macht die Konfiguration so wie sie hier aktuell steht, sicher mehr Sinn.

Also hier gibt es vielleicht etwas Verbesserungspotential?

Sicher kann man hier und da noch bessere und sauberere Entscheidungen treffen.

Die zusätzlichen DNS-Server dienen primär den Docker-Containern sowie einer gewissen Ausfallsicherheit von Samba.
Mit Samba-DNS bin ich persönlich gar nicht glücklich, aber es musste zumindest in Debian 12 immer durch die AD-Implementierung mitgenutzt werden. Demnach kommen wir also nicht darum herum.
Mein Wunsch-DNS-Server wäre dnsmasq, aber wie gesagt, Samba-DNS steht dem im Weg.

Der primäre DNS für das gesamte System müsste laut smb.conf

dns forwarder = 208.67.222.222

OpenDNS sein.

Du kannst bei deiner Instanz gerne die Adressen anpassen, wie du möchtest; so etwas wird nur ganz am Anfang bei der Installation einmal festgelegt.
Wenn du mehrere Libre-Workspace-Instanzen betreibst, kann das auch durch beispielsweise ein kleines Add-on automatisiert werden.

Gerne können wir das Thema auch noch einmal etwas genauer behandeln und DNS-technisch zu gegebener Zeit aufräumen. Einen datenschutzfreundlichen DNS packe ich gerne als erste Option hinein; das mache ich direkt ab der nächsten Version.

Ein bisschen Failover schadet bei diesem Thema meiner Ansicht nach nichts, vor allem, weil jedes Environment anders ist und wir immer alle Fälle abdecken müssen.

Mal ein kurzes Update, ich komme leider zeitlich noch nicht so dazu verschiedene Anbindungen zu testen, wie ich mir das wünsche würde.

Ich habe mir mal eine lokale Windows Testdomäne von unserem Azubi geschnappt und versucht eine LWS Installation dort anzubinden. Also wie beschrieben, die minimalste Installation und dann manuell den AD als LDAP hinterlegt. Danach war LWS leider komplett kaputt und warf nur noch Error 500.
Mir fehlte dann leider an der Stelle die Zeit, weiter zu testen.

Da setze ich demnächst™ noch mal mit einer frischen Installation an, wenn ich unsere Proxmox Host-Systeme aktualisiert habe, die möchte ich auch erst auf Trixie haben. Vielleicht dann auch noch mal als virtuelle Maschine und nicht als LXC, manchmal sind LXCs ja doch etwas speziell.