FreeBSD + mehrere Jails / PF

[rudelgurke]

Hallo,

kurz der Überblick :)

Es laufen 2 Jails - ein Apache / ein Mail Jail in denen die jeweiligen Dienste installiert sind und alles soweit funktioniert.

Das Problem ist nur dass die Jails untereinander nicht kommunizieren können (über TCP) - vermute mal ein Problem mit der PF Konfiguration.

ifconfig

Code: Select all

lo1 = 127.0.10.1 / 255.255.255.255
lo2 = 127.0.20.1 / 255.255.255.255

Die beiden Jail Interfaces.

pf

Code: Select all

....
int="em0"
int_www="lo1"
int_mail="lo2"
master="123.456.789.321"
www="127.0.10.1"
mail="127.0.20.2"

rdr on $int proto tcp from any to $master port 80 -> $www port 80
rdr on $int proto tcp from any to $master port 25 -> $mail port 25

usw. für Ports 465, 995 ...

nat on $int from $www to any -> $master
nat on $int from $mail to any -> $master

set block-policy return
...

pass out quick on $int proto tcp from $www port 80 to any
pass out quick on $int proto tcp from $mail port 25 to any

Mit weiteren RDR's wie z. Bsp.

rdr on $int_www from any to $www port 25 -> $mail port 25

habe ich es schon probiert, was aber nicht will. Auch auf der Testkiste ein "finales"

pass in all
pass out all

Wollte nicht helfen wie etwas:

pass in quick on $int_mail from $mail to $www port 80

Denke mal das Problem dürften die NAT Regeln sein, nur möchte ich ungern damit auf dem Produktionssystem "spielen".

[Joe User]

127.0.20.1 != 127.0.20.2

[daemotron]

Die Regeln können so nicht funktionieren (Begründung siehe Inline-Kommentare). Der richtige (sinnvollere) Regelsatz würde so aussehen:

Code: Select all

# Definitionen
if_ext="em0"
if_www="lo1"
if_mail="lo2"
master="123.456.789.321"
www="127.0.10.1"
mail="127.0.20.1"

# Tabellen für häufig genutzte Adressbereiche
table <dns> { 12.34.56.78, 23.45.67.89 }
table <bogus> persist     # Persistente Tabelle für Hosts, die man zwischendrin mal blocken möchte

# Generelle Voreinstellungen
set block-policy return
scrub in all

# NAT/MASQ Regeln
rdr pass on $if_ext proto tcp from any to $master port 25 -> $mail port 25
rdr pass on $if_ext proto tcp from any to $master port 80 -> $www port 80

nat pass on $if_ext from $mail to any -> $master
nat pass on $if_ext from $www to any -> $master

# Filter-Regeln
# erst mal darf nix durch
block in all
block out all

# Localhost wollen wir nicht behindern
pass quick on lo0 all

# IP-Header auf Spuren von Spoofing-Versuchen untersuchen
antispoof log quick for $if_ext inet

# Hosts in <bogus> dürfen hier gar nix, die fliegen unkommentiert raus!
block in log quick from <bogus> to any

# SSH-Zugriff auf der Master-IP erlauben
# Verbindungen sollen über pflog aufgezeichnet werden
# Durch stateful wird keine Regel für den an der Verbindung hängenden ausgehenden Traffic benötigt
pass in log quick on $if_ext proto tcp from any to $master port 22 flags S/SA keep state

# Zugriff auf DNS-Server erlauben
pass out quick on $if_ext proto udp from $master to <dns> port 53

# Interner Zugriff: Webserver zu Mailserver
# Es muss eine in- und eine out-Regel für jedes der beteiligten Interfaces existieren
# Man kann das auch kürzer schreiben, aber so wird es besser deutlich:
pass in quick on $if_www proto tcp from $www to $mail port 25
pass out quick on $if_www proto tcp from $www to $mail port 25
pass in quick on $if_mail proto tcp from $www to $mail port 25
pass out quick on $if_mail proto tcp from $www to $mail port 25

# Für den umgekehrten Zugriff sieht der Regelsatz so aus:
pass in quick on $if_www proto tcp from $mail to $www port 80
pass out quick on $if_www proto tcp from $mail to $www port 80
pass in quick on $if_mail proto tcp from $mail to $www port 80
pass out quick on $if_mail proto tcp from $mail to $www port 80

P. S. kurzer Nachtrag: in der /etc/rc.conf muss ein Eintrag gateway_enable="YES" drinstehen. Dabei werden bei einem Neustart zwei Sysctl-Werte für Forwarding und Redirect gesetzt. So kannst Du prüfen, ob sie gesetzt sind:

Code: Select all

sysctl -a | grep -e 'net.inet.ip.[fr][oe]'
net.inet.ip.forwarding: 1
net.inet.ip.redirect: 1

[rudelgurke]

127.0.20.1 != 127.0.20.2

Sorry - ein Tippfehler.

Die Regeln können so nicht funktionieren (Begründung siehe Inline-Kommentare). Der richtige (sinnvollere) Regelsatz würde so aussehen

...

P. S. kurzer Nachtrag: in der /etc/rc.conf muss ein Eintrag gateway_enable="YES" drinstehen. Dabei werden bei einem Neustart zwei Sysctl-Werte für Forwarding und Redirect gesetzt. So kannst Du prüfen, ob sie gesetzt sind:

Code: Select all

sysctl -a | grep -e 'net.inet.ip.[fr][oe]'
net.inet.ip.forwarding: 1
net.inet.ip.redirect: 1

Also doch die Gateway Funktion - die reine Kommunikation (RDR + NAT) hat ohne IP Forwarding funktioniert.

Besten Dank :)

War etwas schwierig da Docu's zu finden - Jails einrichten, kein Problem - nur wenn die miteinander sollen hört dann meist ein FAQ / HOWTO / Wiki auf :(

[daemotron]

Die Gateway-Funktion brauchst Du, da bei der Konstellation mail <=> www die Verbindung über zwei (virtuelle) NICs läuft, und zwar ohne NAT oder RDR. Damit dieses stinknormale Forwarding auch stattfindet, braucht's halt die entsprechenden sysctl-flags... (und wegen der zwei beteiligten NICs hätten Deine pass-Regeln von oben auch nicht gereicht... da du aber gar nicht erst geblockt hattest, waren die in Deiner Konfiguration ohnehin obsolet).

War etwas schwierig da Docu's zu finden - Jails einrichten, kein Problem - nur wenn die miteinander sollen hört dann meist ein FAQ / HOWTO / Wiki auf

Hinweis verstanden. Hab das den Wiki-Artikel zu Jails noch mal um einen Hinweis auf gateway_enable ergänzt. Wenn ich wieder mehr Zeit habe, werde ich die Artikelserie auch fortführen und zeigen, wie Jails auch untereinander kommunizieren (hab das bei mir so produktiv im Einsatz, z. B. mit einem reverse proxy).

Wenn Du Doku zu pf suchst, solltest Du direkt an die Quelle gehen - Das OpenBSD-Projekt pflegt ein hervorragendes Handbuch zu pf, das es auch in einer guten deutschen Übersetzung gibt.

[rudelgurke]

Mit PF habe ich kein Problem bisher gehabt, da gibt es auch schon gute Beispiele an denen man sich etwas "ziehen" kann + die Docu auf der OpenBSD Seite.

Zum Wiki - war nicht so gemeint - ich könnte aber speziell zu Apache etwas beitragen. Apache + SSL + PHP in einer abgespeckten Jail Umgebung - dass "make installworld" unnötig wird.

Gleiches zu Pure-Ftpd / Postfix + Dovecot in einer Jail falls da Bedarf besteht

[daemotron]

Zum Wiki - war nicht so gemeint - ich könnte aber speziell zu Apache etwas beitragen. Apache + SSL + PHP in einer abgespeckten Jail Umgebung - dass "make installworld" unnötig wird.

Klar... immer gerne. Wir sollten uns nur vorher kurz absprechen, wie wir das in die bestehende Struktur integrieren, damit wir Joe User hinterher nicht zu oft mit "benenn mal bitte Artikel xy in yx um" nerven müssen

Mal rein aus Interesse und Neugier: Baust Du die Jails manuell mit ldd & Co. auf? Falls ja, wie hälst Du dann die Libs in den Jails auf Stand?

Gleiches zu Pure-Ftpd / Postfix + Dovecot in einer Jail falls da Bedarf besteht

Immer rein damit! Postfix + Dovecot können wir gerne abgleichen, hab ich bei mir auch am rennen (mit PostgreSQL-Backend und policyd-weight), außerdem noch Mailman incl. Web-Interface.

[rudelgurke]

Baust Du die Jails manuell mit ldd & Co. auf? Falls ja, wie hälst Du dann die Libs in den Jails auf Stand?

Yup. Eine "Chroot" Umgebung zum testen und dann wird alles in eine Jail verfrachtet. Aktuell gehalten wird dort alles mit einem kleinen Script dass die "lib / libexec / sbin" Verzeichnisse durchgeht und falls neuere Versionen auf dem Basissystem installiert sind, diese aktualisiert.
Das Start Kommando der Jail ist dann ein weiteres kleines Script dass via "rc" Apache oder Pure-Ftpd / Postfix / Dovecot startet.
Außerhalb der Jail liegen dann in /usr/local/etc/rc.d/ noch RC Scripte die via jls / jexec einen Neustart / Reload erlauben falls Bibliotheken aktualisiert werden sollen.

Werde ich alles dokumentieren - gibt vielleicht hier oder noch etwas zu verbessern

[irie]

Die Gateway-Funktion brauchst Du, da bei der Konstellation mail <=> www die Verbindung über zwei (virtuelle) NICs läuft, und zwar ohne NAT oder RDR. Damit dieses stinknormale Forwarding auch stattfindet, braucht's halt die entsprechenden sysctl-flags... (und wegen der zwei beteiligten NICs hätten Deine pass-Regeln von oben auch nicht gereicht... da du aber gar nicht erst geblockt hattest, waren die in Deiner Konfiguration ohnehin obsolet).

War etwas schwierig da Docu's zu finden - Jails einrichten, kein Problem - nur wenn die miteinander sollen hört dann meist ein FAQ / HOWTO / Wiki auf

Hinweis verstanden. Hab das den Wiki-Artikel zu Jails noch mal um einen Hinweis auf gateway_enable ergänzt. Wenn ich wieder mehr Zeit habe, werde ich die Artikelserie auch fortführen und zeigen, wie Jails auch untereinander kommunizieren (hab das bei mir so produktiv im Einsatz, z. B. mit einem reverse proxy).

Wenn Du Doku zu pf suchst, solltest Du direkt an die Quelle gehen - Das OpenBSD-Projekt pflegt ein hervorragendes Handbuch zu pf, das es auch in einer guten deutschen Übersetzung gibt.

Hallo Jesco,

mich würde jetzt mal interessieren wie bei dir die PF Regeln für deinen Reverse Proxy aussehen.
Gerade das breitet mir zurzeit erhebliche Kopfschmerzen.
Bekomm die Anfrage an den Proxy Port 80 einfach nicht an die interne Backend IP mit Port: 8080 weitergeleitet.
Vom Proxy Jail aus lässt sich das Backend jedoch schon direkt ansprechen.
Wenn von Extern eine Verbindung an den Proxy eingeht, unterscheidet dann die PF-Weiterleitungsregel vom Proxy zu Backend auch ob die Externe IP auch zum Backend darf???
Ich dachte, dass diese Aktion der Proxy mit dem Backend direkt/intern aushandelt und über Proxy wieder an die ext IP redirected und somit auch nur die Regeln zwischen Proxy und Backend zugelassen werden müssen.

[daemotron]

Deine Vermutung ist soweit korrekt - pf kümmert sich nur darum, dass eingehende Pakete auf dem externen Interface/Port 80 an die interne IP des Proxy weitergeleitet werden. Um den Zugriff auf das Backend kümmert sich Apache mit mod_proxy; pf darf dabei nur den Verkehr zwischen Apache-Proxy und Backend nicht blockieren. Wenn mehrere (virtuelle) NICs beteiligt sind, muss forwarding aktiviert sein. Bitte bei pf-Regeln bedenken, dass es immer Regeln für ein- (Backend) und ausgehende (Proxy) Verbindungen geben muss, und das je beteiligtem Interface!

Btw. funktioniert denn der Zugriff auf den Proxy, wenn pf nur mit den rdr-Regeln arbeitet, ohne Filter? Falls nein, ist wahrscheinlich auch das Proxy-Setup verschraubt und muss überarbeitet werden.

[irie]

Der Proxy (pound) Zugriff funktioniert mit den RDR Regeln auch wunderbar ohne Filter rules.
Die Kommunikation von Pound zum anderen Jail (Lighttpd) scheint aber irgendwie gestört zu sein.

eine rdr regel vom internen interface des Proxys (vif_proxy) zum internen interface (vif_www) des backends muss man aber nicht noch zusätzlich legen oder???

Die Pass in und Out Regeln die du hier geposted hast, habe ich auch schon ausprobiert..

[daemotron]

OK, dann müssen wir uns Deine Konfiguration genauer ansehen. Bitte folgendes posten:

• Error Log von pound (was wird protokolliert, wenn der Zugriff fehlschlägt?)
• Ausgabe von sysctl -a | grep -e 'net.inet.ip.[fr][oe]'
• Deine pf.conf
• Auszug aus der rc.conf, in dem die beiden betroffenen NICs definiert und konfiguriert werden

Nächste Diagnoseschritte: pflog aktivieren und alle relevanten Regeln mal um ein log statement erweitern. Vom Proxy-Jail aus per netcat oder telnet eine Verbindung zum Backend-Jail herstellen - wenn das fehlschlägt, schauen was pflog denn so protokolliert hat. Wenn telnet gehen sollte, liegt es ggf. doch an pound oder lighttpd.

[irie]

na da wolle ma mal loslegen mit dem Bugtracking:

Code: Select all

Pound sagt: proxy pound: (801102a80) e503 no service "GET / HTTP/1.1" from 9x.xx.xx.xx
lighttpd sagt:  [01/Apr/2009:18:27:32 +0200] "GET / HTTP/1.1" 301 0 "-" "Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.0.8) Gecko/2009032609 Firefox/3.0.8 FirePHP/0.2.4"
Syscontrol sagt:
net.inet.ip.forwarding: 1
net.inet.ip.redirect: 1

Auszug aus meiner pf.conf

Code: Select all

set fingerprints "/etc/pf.os"
set limit { frags 16384, states 32768 }
set timeout { udp.first 15, udp.single 5, udp.multiple 30 }
set block-policy return
tcp_bruteforce = "{ 21, 22, 53, smtp, pop3, imap }"
icmp_types = "{ echoreq, echorep, timex, unreach }"
scrub in all

if_ext = "bge0"
vif_application = "lo4"
vif_proxy = "lo7"
master_ip = "wirdnichtverraten"
application_ip = 127.0.40.10
proxy_ip = 127.0.70.10
table <bruteforce> persist
table <blacklist> persist file "/var/db/blacklist.pf"

# Pound Redirect
rdr pass on $if_ext proto tcp from any to $master_ip port 80 -> $proxy_ip port 80

# Application Internet
nat pass on $if_ext from $application_ip to any -> ($if_ext)

# Proxy Internet
nat pass on $if_ext from $proxy_ip to any -> ($if_ext)

block log all
pass quick on lo0 all
block log quick on $if_ext proto tcp from any os "Linux" to any port ssh
block log quick on $if_ext proto tcp from any os "Windows 2000" to any port ssh
block log quick on $if_ext proto tcp from any os "Windows 98" to any port ssh
block quick from <bruteforce>
block quick from <blacklist>
antispoof log quick for $if_ext inet

pass in on $if_ext proto tcp from any to any port $tcp_bruteforce 
flags S/SA keep state (max-src-conn 20, max-src-conn-rate 5/10, 
overload <bruteforce> flush global)

pass in log quick on $if_ext proto tcp from any to $master_ip port 22 flags S/SA keep state
pass out on $if_ext proto icmp from ($if_ext) to any keep state

#Pound zu lightttpd & lighttpd zu Pound
pass in quick on $vif_application proto tcp from $application_ip to $proxy_ip port 80
pass out quick on $vif_application proto tcp from $application_ip to $proxy_ip port 80
pass in quick on $vif_proxy proto tcp from $application_ip to $proxy_ip port 80
pass out quick on $vif_proxy proto tcp from $application_ip to $proxy_ip port 80
pass in quick on $vif_application proto tcp from $proxy_ip to $application_ip port 8080
pass out quick on $vif_application proto tcp from $proxy_ip to $application_ip port 8080
pass in quick on $vif_proxy proto tcp from $proxy_ip to $application_ip port 8080
pass out quick on $vif_proxy proto tcp from $proxy_ip to $application_ip port 8080

Auszug aus meiner rc.conf:
application jail:
lighttpd_enable="YES"

proxy jail:
pound_enable="YES"


Zugrifftests von den Jails aus:

application# telnet 127.0.70.10 80
Trying 127.0.70.10...
Connected to 127.0.70.10.
Escape character is '^]'.

proxy# telnet 127.0.40.10 8080
Trying 127.0.40.10...
Connected to 127.0.40.10.
Escape character is '^]'.

Wenn ich von der Proxy Jail mit lynx zur application ip connecte seh ich auch die Webseite die auf lighttpd liegt
Von aussen nur die Fehlerseite des Proxys: The service is not available. Please try again later.

Ich kann dir noch ein tcpdump von pflog machen wenn das nicht reicht........

[daemotron]

Das beweist für mich dass Pound hier der Übeltäter ist - Netzwerk-Zugriff zwischen den Jails funktioniert, und Lighttpd reagiert auf auf Anfragen aus dem Proxy-Jail mit Status 301.
Kannst Du bei Pound den Loglevel noch weiter hochschrauben? 503 bedeutet normalerweise, dass er vom App-Server keine Antwort erhalten hat...

Was mir jetzt noch dazu einfällt:

• Anstelle von Pound mal Lighty + mod_proxy probieren
• Mit wireshark oder tcpdump mal aufzeichnen, was da zwischen den beiden virtuellen NICs hin und her geht

[irie]

Hier das TCPDUMP:
23. 568310 rule 38/0(match): pass out on lo4: 127.0.70.10.53336 > 127.0.40.10.8080: S 3315890274:3315890274(0) win 65535 <mss 16344,nop,wscale 3,sackOK,timestamp[|tcp]>
000180 rule 37/0(match): pass in on lo4: 127.0.70.10.53336 > 127.0.40.10.8080: S 3315890274:3315890274(0) win 65535 <mss 16344,nop,wscale 3,sackOK,timestamp[|tcp]>
25. 169775 rule 38/0(match): pass out on lo4: 127.0.70.10.50342 > 127.0.40.10.8080: S 2650692267:2650692267(0) win 65535 <mss 16344,nop,wscale 3,sackOK,timestamp[|tcp]>
000174 rule 37/0(match): pass in on lo4: 127.0.70.10.50342 > 127.0.40.10.8080: S 2650692267:2650692267(0) win 65535 <mss 16344,nop,wscale 3,sackOK,timestamp[|tcp]>
41. 218857 rule 38/0(match): pass out on lo4: 127.0.70.10.54485 > 127.0.40.10.8080: S 1621291919:1621291919(0) win 65535 <mss 16344,nop,wscale 3,sackOK,timestamp[|tcp]>
000177 rule 37/0(match): pass in on lo4: 127.0.70.10.54485 > 127.0.40.10.8080: S 1621291919:1621291919(0) win 65535 <mss 16344,nop,wscale 3,sackOK,timestamp[|tcp]>
10. 749428 rule 38/0(match): pass out on lo4: 127.0.70.10.49308 > 127.0.40.10.8080: S 3147571965:3147571965(0) win 65535 <mss 16344,nop,wscale 3,sackOK,timestamp[|tcp]>
000165 rule 37/0(match): pass in on lo4: 127.0.70.10.49308 > 127.0.40.10.8080: S 3147571965:3147571965(0) win 65535 <mss 16344,nop,wscale 3,sackOK,timestamp[|tcp]>
7. 347377 rule 38/0(match): pass out on lo4: 127.0.70.10.58280 > 127.0.40.10.8080: S 601256164:601256164(0) win 65535 <mss 16344,nop,wscale 3,sackOK,timestamp[|tcp]>
000031 rule 37/0(match): pass in on lo4: 127.0.70.10.58280 > 127.0.40.10.8080: S 601256164:601256164(0) win 65535 <mss 16344,nop,wscale 3,sackOK,timestamp[|tcp]>

die loglevels in der pound config scheinen nix zu bewirken. habs schon mit 2 und 3 probiert. das logoutput bleibt:
Apr 1 19:50:31 proxy pound: (801102a80) e503 no service "GET / HTTP/1.1" from 93.x.x.x

[irie]

ohmann. hat sich erledigt.
hab ein bisschen mit der pound config rumgetüftelt. dem hat wohl der HeadRequire "Host:.*www.domain.de.*" in der config nicht gefallen. requests kommen immer von domain.de also ohne www. muss noch mal meinen nameserver checken.
Jetzt klappt es endlich juhuu
aber danke trotzdem für deine hilfreichen eingebungen. sonst hätte ich wohl an falscher stelle geprüft ;-)

wie kann man denn die pass in / pass out regeln verkleinern für den zwischen jail talk? ;-)

[daemotron]

wie kann man denn die pass in / pass out regeln verkleinern für den zwischen jail talk? ;-)

Die Regeln für Port 80 sind schon mal überflüssig - oder läuft im Application Jail auch ein Dienst auf Port 80, auf den vom Proxy aus zugegriffen wird?

Ansonsten kann man die Direction noch weglassen (die Interfaces kann man aber AFAIK nicht zusammenfassen, höchstens weglassen):

Code: Select all

pass quick on $vif_application proto tcp from $proxy_ip to $application_ip port 8080
pass quick on $vif_proxy proto tcp from $proxy_ip to $application_ip port 8080

# oder noch kürzer:
pass quick proto tcp from $proxy_ip to $application_ip port 8080

[irie]

achsooo. das hab ich jetzt mal wieder total falsch verstanden.
ich dachte die 80er regeln dienen als rückkanal. aber der rücklauf find ja auch schon über die erste regel statt verstehe.

wie würe das ganze dann eigentlich korrekterweise aussehen wenn wir einen notify request vom nameserver jail zum externen nameserver schicken wollen und darauf ein zonetransfer query von einem externen nameserver erwarten würden.

wären diese regeln korrekt:
rdr pass on $if_ext proto tcp from any to $if_ext port 53 -> $ns1_ip port $ns1_port
rdr pass on $if_ext proto udp from any to $if_ext port 53 -> $ns1_ip port $ns1_port

pass out on $vif_ns1 proto { udp, tcp } from $ns1_ip to $ns2_ip keep state
pass in on $if_ext proto { udp, tcp } from $ns2_ip to $ns1_ip keep state

[daemotron]

achsooo. das hab ich jetzt mal wieder total falsch verstanden.
ich dachte die 80er regeln dienen als rückkanal. aber der rücklauf find ja auch schon über die erste regel statt verstehe.

Zur Ergänzung: pf nimmt automatisch flags S/SA keep state hinter jeder Regel an, das muss man also nicht zwingend hinschreiben (es sei denn, man möchte es ändern). Damit sind per default alle pf-Regeln stateful und Regeln für den Rückfluss sind nicht erforderlich.

wie würe das ganze dann eigentlich korrekterweise aussehen wenn wir einen notify request vom nameserver jail zum externen nameserver schicken wollen und darauf ein zonetransfer query von einem externen nameserver erwarten würden.

wären diese regeln korrekt:
rdr pass on $if_ext proto tcp from any to $if_ext port 53 -> $ns1_ip port $ns1_port
rdr pass on $if_ext proto udp from any to $if_ext port 53 -> $ns1_ip port $ns1_port

pass out on $vif_ns1 proto { udp, tcp } from $ns1_ip to $ns2_ip keep state
pass in on $if_ext proto { udp, tcp } from $ns2_ip to $ns1_ip keep state

Irgendwie verstehe ich Dein Anliegen noch nicht ganz - Deine Regeln machen jetzt folgendes: Jede eingehende Verbindung von extern auf Port 53 wird annn ns1 (ein Jail?) weitergeleitet. Deine Filterregeln erlauben die Kommunikation zwischen ns1 und ns2, wobei ein virtuelles und ein externes Interface involviert sind. Ist eine der beiden ns-IPs denn an das externe Interface gebunden?

[irie]

Ich versuchs mal zu erklären,

ns1.domain.de schickt NOTIFYs an ns2.domain.de
ns1.domain.de akzeptiert AXFR-Zonetransfers von ns1.domain.de

auf meinem Server läuft ein Primärer authoritative Nameserver (NSD) ns1.domain.de in einer eigenen Jail (ns1 auf Port 5353)
Der Sekundäre Nameserver ns2.domain.de befindet sich bei einem externen Anbieter.
An diesen müssen sogenannte Notifys geschickt werden, sprich mein Primärer Nameserver (ns1.domain.de) schickt dem Sekundären externen Nameserver (ns2.domain.de) über Port 53 ein Signal, die neuen Zonefiles von meinem Nameserver abzuholen um diese auf den gleichen Stand zu bringen.

Anfrage vom externen Nameserver werden per rdr pass regel an das interne Jail auf Port 5353 weitergereicht.