MX Redundanz per DNS incl. Loadbalancing

traced

traced

Registered User
Hi Mädels,

folgendes Szenario:

Code: 
example.com   MX 10  gate1.example.com
example.com   MX 20  gate2.example.com

Code: 
gate1.example.com   A   123.456.789.0
gate1.example.com   A   123.456.789.1

gate2.example.com   A   123.456.789.1
gate2.example.com   A   123.456.789.0

Wenn die .0 ausfällt, probiert der versendende Mailserver ja den nächsten MX Eintrag, wenn aber aber wegen DNS Round-Robin hier auch zufällig wieder die Adresse .0 rausfischt, dann sind ja für den Mailserver beide MX Einträge "down".

Wenn ich das richtig verstehe bleibt der Zustand aber auch so lange, wie der lokale DNS Cache des Mailservers die Adressen im Speicher hat. (OK, kurze TTL, trotzdem doof :) )

Hab ich da einen Denkfehler? Gekommen bin ich da rauf eigentlich nur, weil es viele Firmen gibt die die MX Einträge so gesetzt haben, und ich mir da mmt. auch so meine Gedanken mache wie es am geschicktesten wäre.

Danke,
viele Grüße

Basti
 
Last edited by a moderator:
Diese Konfiguration hat IMHO nicht viel Sinn. Mehrere MX hat man ja gerade, damit man das nicht per DNS lösen muss.

Könnte aber sein, dass die Firmen mit dieser Konfiguration die Server als Cluster betreiben. In diesem Fall wäre 123.456.789.0 auch erreichbar wenn ein Server crasht.
 
Exakt. Beide haben nach aussen die gleiche IP-Adresse. Eine solche Konfiguration würde funktionieren, allerdings sehe ich deren Sinn noch nicht ganz. MX und Backup-MX mit unterschiedlichen IPs und da dann ein Loadbalancer würde ja reichen.
 
Vielen Dank schonmal für Deine Mühe!

Wie würdest Du es denn am besten anstellen, mit zwei Mailservern (incl. Spam- und Virenschutz), und z.B. einem Backup-MX, falls wirklich beide Mailgates vorübergehend nicht erreichbar sind?

lg Basti
 
Falls beide MX nicht erreichbar sind, werden die Mails von den sendenden Servern in der Warteschlange gehalten und zugestellt, sobald einer Deiner Server wieder erreichbar ist. Das ist im Standard so geregelt und funktioniert zuverlässig.
 
Also dann am besten den BackupMX einsparen. Also dann einfach wegen Loadbalancing so:

Code: 
example.com   MX 10  gate.example.com

gate.example.com   A   123.456.789.0
gate.example.com   A   123.456.789.1

oder

Code: 
example.com   MX  10   gate1.example.com
example.com   MX  10   gate2.example.com

gate1.example.com   A   123.456.789.0
gate2.example.com   A   123.456.789.1

Kommt doch im Prinzip aufs selbe raus oder? Gibts Vorteile / Nachteile?

lg Basti
 
traced said:
Kommt doch im Prinzip aufs selbe raus oder?
Click to expand...
hm, wenn ich mir einen MX von livingston ansehe bekomme ich:
Code: 
core:~ # dig mx livingston.de
livingston.de.          45979   IN      MX      20 cluster3a.eu.messagelabs.com.
livingston.de.          45979   IN      MX      10 cluster3.eu.messagelabs.com.
;; ADDITIONAL SECTION:
cluster3a.eu.messagelabs.com. 542 IN    A       216.82.248.45
cluster3a.eu.messagelabs.com. 542 IN    A       85.158.141.190
cluster3a.eu.messagelabs.com. 542 IN    A       216.82.248.44
Es ist m.W. nicht möglich einen MX mit gleicher Prio aufzusetzen, denn wenn beide Online sind - wohin mit der Mail?
Der gleiche A-Rec auf verschiedenen IP ist wohl möglich, entsprechend der Last wird das dann verteilt.
 
Super, danke für Eure Antworten!
Nur stellt sich mir dann noch die Frage, lieber zwei gleichwertige MX Einträge, oder lieber einen MX, dessen A-Record auf zwei Server zeigt? Das zumindest sollte doch dann nur noch geschmackssache sein, oder?

lg Basti
 
Ich würde MX vorziehen da doch hier bei einem Fail automatisch der nächste MX versucht wird bzw. ein anderer bei einem A Record RoundRobin wird der MX ja als tot makiert ich bin mir nicht sicher dass er erkennt dass ers nochmal versuchen soll da für den Sendenden Server ja der einzige MX tot ist.
 
Hmmm... irgendwie hatte ich nen Denkfehler, ich denk auch dass zwei MX besser sind, da er ja die IP des MX Eintrages gespeichert hat, und denke erst nach Ablauf der TTL nochmal die zweite kriegt, wenn überhaupt wegen RR... hmm... ich bleib bei zwei MX.

Vielen Dank an alle!!

lg Basti
 
You must log in or register to reply here.
Back
Top