Das Problem

Du hast einen Multi-DC Samba4 Active Directory aufgebaut. DNS-Auflösung funktioniert, DRS-Replikation zeigt “0 consecutive failures” auf allen Partitionen. Alles grün.

Dann legst du einen neuen DNS-Record an:

# Auf dem Primary DC - funktioniert
dig @192.168.66.1 srv-falcon.deathstar.lan +short
192.168.66.42

# Auf dem Replica DC - nichts
dig @192.168.66.2 srv-falcon.deathstar.lan +short
(keine Ausgabe)

Wie kann das sein? DRS repliziert doch alles?

TL;DR

Statische Bind-Zonen in /etc/bind/local.conf.samba4 werden nicht via DRS repliziert. Die Samba4 DLZ (Dynamic Loadable Zone) lädt nur AD-integrierte Zonen aus CN=MicrosoftDNS,CN=System.

Lösung: DNS-Records als AD-integrierte Einträge in der bestehenden Zone anlegen, nicht als separate statische Zonen.

Ursache

Viele Anleitungen zeigen, wie man schnell eine DNS-Zone anlegt:

# /etc/bind/local.conf.samba4
zone "infra.deathstar.lan" {
    type master;
    file "/etc/bind/db.infra";
};

Das funktioniert - auf diesem einen Server. Aber:

  1. Statische Zonen sind lokal — sie existieren nur in der Bind-Config und Zonendatei
  2. DRS repliziert nur LDAP-Daten — /etc/bind/* ist kein LDAP
  3. Die DLZ ignoriert neue Zonen — sie lädt nur beim Start existierende Zonen aus CN=System

Das perfide: DRS zeigt keine Fehler, weil es seine Arbeit korrekt macht. Es gibt einfach nichts zu replizieren.

Die Samba4 DLZ verstehen

Wenn Bind9 mit Samba4 DLZ startet, passiert folgendes:

samba_dlz: trying partition 'CN=MicrosoftDNS,CN=System,DC=deathstar,DC=lan'
samba_dlz: configured writeable zone 'deathstar.lan'
samba_dlz: configured writeable zone '66.168.192.in-addr.arpa'

Die DLZ liest nur aus CN=MicrosoftDNS,CN=System — die sogenannte “Legacy-Partition”. Die moderneren Partitionen DomainDnsZones und ForestDnsZones werden für normale Zonen ignoriert.

Und hier kommt der Haken: Neue Zonen, die du nach dem Start anlegst, werden nicht automatisch geladen. Selbst wenn du sie korrekt in CN=System erstellst.

Lösung: AD-integrierte Records statt Zonen

Statt eine neue Zone infra.deathstar.lan anzulegen, erstelle einen A-Record srv-falcon in der bestehenden deathstar.lan Zone:

1. Template von bestehendem Record holen

ldbsearch -H /var/lib/samba/private/sam.ldb \
  -b 'DC=deathstar.lan,CN=MicrosoftDNS,CN=System,DC=deathstar,DC=lan' \
  '(name=dc-vader)' dnsRecord

Ausgabe:

dnsRecord:: BAABAAXwAAAQAAAAAAADhAAAAAAAAAAAwKhCAQ==

Das ist der Base64-kodierte DNS-Record. Die letzten Bytes sind die IPv4-Adresse.

2. IP-Adresse anpassen

import base64
# Original: 192.168.66.1 (letztes Byte 0x01 = 1)
orig = base64.b64decode("BAABAAXwAAAQAAAAAAADhAAAAAAAAAAAwKhCAQ==")
# Neue IP: 192.168.66.42 (letztes Byte 0x2A = 42)
new = orig[:-1] + bytes([42])
print(base64.b64encode(new).decode())
# Ausgabe: BAABAAXwAAAQAAAAAAADhAAAAAAAAAAAwKhCKg==

3. Record via ldbadd anlegen

cat > /tmp/srv-falcon.ldif << EOF
dn: DC=srv-falcon,DC=deathstar.lan,CN=MicrosoftDNS,CN=System,DC=deathstar,DC=lan
objectClass: top
objectClass: dnsNode
dc: srv-falcon
name: srv-falcon
dnsRecord:: BAABAAXwAAAQAAAAAAADhAAAAAAAAAAAwKhCKg==
EOF

ldbadd -H /var/lib/samba/private/sam.ldb /tmp/srv-falcon.ldif

4. Sofort verfügbar — und repliziert automatisch

# Primary DC
dig @192.168.66.1 srv-falcon.deathstar.lan +short
192.168.66.42

# Replica DC (nach DRS-Replikation)
dig @192.168.66.2 srv-falcon.deathstar.lan +short
192.168.66.42

Der Record wird via DRS automatisch auf alle DCs repliziert. Kein manuelles Kopieren, kein Bind-Restart nötig.

Bonus: Ohne Admin-Passwort arbeiten

samba-tool dns add braucht Kerberos-Auth oder ein Admin-Passwort. Für Automation ist das unpraktisch.

Die ldbadd/ldbdel Befehle arbeiten direkt auf der lokalen SAM-Datenbank — ohne Authentifizierung (als root). Das ist sicher, weil:

  1. Du musst bereits root auf dem DC sein
  2. Die Änderung wird via DRS signiert und repliziert
  3. Die LDAP-ACLs bleiben intakt

Verifikation

Nach dem Anlegen prüfen:

# DNS-Auflösung
dig @<primary-dc> hostname.domain.lan +short
dig @<replica-dc> hostname.domain.lan +short

# Record im LDAP
ldbsearch -H /var/lib/samba/private/sam.ldb \
  -b 'DC=domain.lan,CN=MicrosoftDNS,CN=System,DC=domain,DC=lan' \
  '(name=hostname)' dn

# DRS-Replikation (auf Replica)
samba-tool drs showrepl | grep -A3 "DC=domain,DC=lan"

Aufräumen: Statische Zonen entfernen

Falls du bereits statische Zonen hast:

# 1. Eintrag aus local.conf.samba4 entfernen
sed -i '/zone "subdomain/,/^};$/d' /etc/bind/local.conf.samba4

# 2. Zonendatei löschen
rm /etc/bind/db.subdomain

# 3. Bind neu laden
rndc reload

# 4. AD-integrierten Record anlegen (siehe oben)

Lessons Learned

1. DRS repliziert nur was im AD ist

Statische Bind-Zonen existieren nur im Dateisystem von dc-vader. DRS weiß nichts davon. Nur AD-LDAP-Daten werden repliziert.

2. Nicht annehmen dass Replikation automatisch funktioniert

DRS zeigt “Success” auch wenn keine Daten zum Replizieren da sind. Du musst prüfen ob die Daten selbst existieren, nicht nur ob DRS läuft.

3. Diagnose: Filesystem vs LDAP trennen

# Filesystem-Check (lokal)
ls /etc/bind/db.*

# LDAP-Check (repliziert)
ldbsearch -H /var/lib/samba/private/sam.ldb 'dnsRecord=*' | grep dn:

Wenn ls Dateien zeigt aber ldbsearch leer ist → falsche Methode genutzt.

4. Warum so viele Tutorials statische Zonen empfehlen

Historische Gründe: Frühe Samba4-Versionen hatten DNS-Bugs. Statische Zonen waren der Workaround. Heute nicht mehr nötig.

5. Edge Cases beachten

  • Subzones (infra.deathstar.lan): Funktionieren genauso, nur mit angepasstem dnsZoneName
  • Reverse Zones (PTR Records): Brauchen andere objectClass (dnsNode statt dnsZone)
  • Nicht-Standard-Ports: Wenn DNS auf anderem Server als AD läuft, prüfe Firewall-Regeln

Fazit

  • Statische Bind-Zonen = lokal, manuell, fehleranfällig
  • AD-integrierte Records = repliziert, automatisch, sauber

Wenn du einen Multi-DC Samba4 AD betreibst, vergiss statische Zonen. Alles gehört ins AD.

Referenzen