TIPP: Backup-MX von Schlund nutzen

[jp]

Falls die verwendeten Domains über Providerdomain registriert worden sind, kann man für diese als Backup-MX den Schlund Mail-Cluster verwenden:

Beispiel:

Code: Select all

example.com.  IN  MX  100 mx00.example.com.
example.com.  IN  MX  200 mx00.kundenserver.de.
example.com.  IN  MX  210 mx01.kundenserver.de.

funktioniert bei mir ohne Probleme. ;-)

[wirsing]

Hast du es auch schon mal probiert während dein Mailserver down ist?

[jp]

ja selbstverständlich. ist aber auch nicht notwendig, denn du kannst es ja auch manuell über "telnet mx00.kundenserver.de 25" testen (händisch eine mail generieren). wenn die mail akzeptiert wird, läufts.

[dodolin]

Und, kam die Mail dann auch auf deinem Server an?

Ich habe Einwände dagegen:
Auf einem Backup-MX werden meist keine oder zumindest keine so scharfen Anti-Spam-Massnahmen wie auf einem Primary MX gefahren, außerdem kann dieser nicht die Emfänger auf Gültigkeit prüfen und wird sämtliche localparts für die jeweiligen Domains annehmen. Genau aus diesem Grund stellen Spammer sehr häufig absichtlich direkt an den Secondary MX zu, obwohl der Primary MX erreichbar ist. Das ist extrem Sch.eiße.

Andererseits hat man durch einen Backup-MX keinerlei wirkliche Vorteile:
Wenn der Primary MX down ist, erhält man durch den Backup-MX die Mails auch nicht schneller, da man so oder so warten muss, bis der Primary MX wieder oben ist und der Backup MX die Mails an diesen weitergeleitet hat. Standardkonforme MTAs werden die Mails im Falle eines Ausfalls des Primary MX aber so oder so bis zu 4 Tagen queuen, ehe sie endgültig gebounced werden. D.h. auch ohne Backup MX kommen die Mails alle an, sobald der Primary MX wieder erreichbar ist.

Nur mal so zum nachdenken... ich selbst habe jedenfalls keinen Backup MX und das bewusst (siehe oben).

[jp]

Und, kam die Mail dann auch auf deinem Server an?

ja natürlich, was dachtest du denn?

Ich habe Einwände dagegen:
Auf einem Backup-MX werden meist keine oder zumindest keine so scharfen Anti-Spam-Massnahmen wie auf einem Primary MX gefahren, außerdem kann dieser nicht die Emfänger auf Gültigkeit prüfen und wird sämtliche localparts für die jeweiligen Domains annehmen.

das ist sicherlich korrekt. jedoch behandle ich bei mir den backup-mx ja nicht anders als andere SMTP-server auch. folglich wird hier dann die prüfung vorgenommen. wird die mail von meinem server geblockt, wird sie auch auf dem backup-mx entsprechend gebounced.

Andererseits hat man durch einen Backup-MX keinerlei wirkliche Vorteile:
Wenn der Primary MX down ist, erhält man durch den Backup-MX die Mails auch nicht schneller, da man so oder so warten muss, bis der Primary MX wieder oben ist und der Backup MX die Mails an diesen weitergeleitet hat.

das ist auch korrekt - in diesem fall. aber _grundsätzlich_ ist der Einsatz mehrerer MX-Einträge durchaus sinnvoll. beispiel lastverteilung und/oder hochverfügbarkeitsszenarien...

Standardkonforme MTAs werden die Mails im Falle eines Ausfalls des Primary MX aber so oder so bis zu 4 Tagen queuen, ehe sie endgültig gebounced werden. D.h. auch ohne Backup MX kommen die Mails alle an, sobald der Primary MX wieder erreichbar ist.

richtig, normalerweise schon. aber von fall zu fall kann das auch ganz unterschiedlich sein. es gibt genug "deppen", die ihre mailserver z.b. so konfigurieren, dass der user sofort eine nachricht bekommt, dass seine nachricht noch in der queue ist und später versucht wird, diese zuzustellen. auch kann jeder admin ja die wartezeiten für einen erneuten zustellversuch verändern. es dauert also unter umständen sehr viel länger, bis die mail bei mir eintrifft.

sicherlich ist das alles auch eine frage des geschmacks und/oder der philosophie...

fazit für mich: ich nutze das schlund-mailcluster gern. die mails die ich hab, hab ich (dieser satz ist wohl auch generell grund für die mehrzahl aller backup-mx). denn schließlich gehört in meinem fall mein primary-mailserver zum selben autonomen system, wie der backup-mx. dass die kommunikation unter primary und secondary nicht funktioniert, ist daher relativ unwahrscheinlich. optimal wäre es nun natürlich, _zusätzlich_ zu meinen einträgen noch einen sehr niedrig priorisierten mailserver außerhalb des autonomen systems von schlund zu haben. falls es mal nicht erreichbar sein sollte ;-) aber ich denke in dieser hinsicht kann man sich schon sehr auf die mehrfach redundante und wirklich durchdachte netzstruktur und -anbindung verlassen.

[dodolin]

jedoch behandle ich bei mir den backup-mx ja nicht anders als andere SMTP-server auch.

Alle IP-basierten und andere Checks versagen, z.b.:

DNS Blacklists, Verify des Reverse DNS, Verify des HELO's, Verify, dass die SMTP-Spezifikationen eingehalten werden (open Proxies, ...), lokale Blacklists (IP-basiert oder Hostnamen-basiert), usw. usf. Das ist schon einiges.

aber _grundsätzlich_ ist der Einsatz mehrerer MX-Einträge durchaus sinnvoll. beispiel lastverteilung und/oder hochverfügbarkeitsszenarien...

Ja, das ist für mich der einzige Sinn dafür. Allerdings ist das E-Mail-Protokoll selbst bereits dafür ausgelegt (Queue-/Retry-Strategien, etc.), dass das nicht unbedingt "hochverfügbar" sein muss.

die mails die ich hab, hab ich (dieser satz ist wohl auch generell grund für die mehrzahl aller backup-mx).

Kommt wohl drauf an, wie stark man von Spam geplagt ist. Bei mir gilt da nämlich gerade das umgekehrte: Was ich nicht hab, hab ich nicht. ;)

Ansonsten noch nen Disclaimer: Ich will hier keinen bekehren oder behaupten, meines wäre die alleinig richtige Lösung. Abwägen was jeweils in der Situation besser ist, muss nach wie vor jeder selbst... :)
Ich wollte hier lediglich der Diskussion willen mal ein paar andere Aspekte/Gesichtspunkte/Sichtweisen aufzeigen...

[jp]

Ansonsten noch nen Disclaimer: Ich will hier keinen bekehren oder behaupten, meines wäre die alleinig richtige Lösung. Abwägen was jeweils in der Situation besser ist, muss nach wie vor jeder selbst... :)
Ich wollte hier lediglich der Diskussion willen mal ein paar andere Aspekte/Gesichtspunkte/Sichtweisen aufzeigen...

:lol: okay. ich wollte ja auch nur das hier weitergeben, weil ichs rausgefunden habe. wer was mit der info anstellt, bleibt jedem selbst überlassen. schließlich ist dieses forum auch nicht nur dafür da, um konfigurationen vorzukauen. selbst ein bischen den kreativen grips beschäftigen dürfen die leser schon auch mal

[eyestorm]

Falls die verwendeten Domains über Providerdomain registriert worden sind, kann man für diese als Backup-MX den Schlund Mail-Cluster verwenden:

Beispiel:

Code: Select all

example.com.  IN  MX  100 mx00.example.com.
example.com.  IN  MX  200 mx00.kundenserver.de.
example.com.  IN  MX  210 mx01.kundenserver.de.

funktioniert bei mir ohne Probleme. ;-)

Hallo,

wo muss ich das eintragen? Bind läuft, aber ich wüsste jetzt nicht sicher, wo die Zeilen hinmüssen.

cu eyestorm

[jp]

wo muss ich das eintragen? Bind läuft, aber ich wüsste jetzt nicht sicher, wo die Zeilen hinmüssen.

selbstverständlich gehören diese Zeilen in das jeweilige Zonen-File der entsprechenden Domain.

[eyestorm]

Ich habe nur ein Zone-File für die ganze IP..

Code: Select all

# cat 217.160.200.zone
$TTL 1W
@               IN SOA  ns.domain.de.    root.domain.de. (
                        2002022501      ; serial
                        8H              ; refresh
                        2H              ; retry
                        1W              ; expiry
                        12H)            ; minimum

                IN NS   ns
                IN NS   ns.schlund.de.
000              IN PTR domain.de.

cu eyestorm

[captaincrunch]

So sieht dein Zonefile nicht wirklich aus, oder ? Der nächste "Sicherheitsfanatiker" ? ;)

[eyestorm]

Falls du die Daten darin meinst: Nein ;)
Falls etwas falsch konfiguriert ist, und der Sicherheitsfanatiker in Anführungsstrichen bedeutet, ich könnte eine Sicherheitslücke haben, würde ich gerne darauf hingewiesen.

Und weisst du, ob ich die Zeilen aus dem ersten Beitrag dort einfach hinzufügen kann?

cu eyestorm

[jp]

Und weisst du, ob ich die Zeilen aus dem ersten Beitrag dort einfach hinzufügen kann?

jedenfalls nicht in die reverse DNS-Zone, die du hier anführst, sondern in die kanonische Zone. (Tipp: DNS & Bind, OReilly-Verlag -> kaufen, aufmerksam lesen)

[eyestorm]

Ich habe mal nach der "kanonischen Zone" gesucht und habe dazu auch hier und hier etwas gefunden, nur leider bestätigen die Texte nur das, was ich schon aus dem ersten Beitrag wusste.. kein Beispiel wie ich das in der Datei notieren muss.. kann mir das jemand sagen?

Danke!

cu eyestorm

[jp]

nimm die richtigen Suchbegriffe:

http://www.google.de/search?sourceid=na ... l+dns+zone

[eyestorm]

Code: Select all

$ORIGIN 200.160.217.in-addr.arpa.
example.com.  IN  MX  100 mx00.example.com.
example.com.  IN  MX  200 mx00.kundenserver.de.
example.com.  IN  MX  210 mx01.kundenserver.de. 

So?

Finde leider nirgendwo ein Beispiel, wie die kanonische Zone "drumherum" aufgebaut ist.. bin aber vielleicht auch zu blöd ;)

[jp]

kinder! dass man euch doch immer wieder die einfachsten sachen zeigen muss...

http://www.rootforum.org/faq/index.php? ... rubrik=004

wo ist diese seiten von der jetzigen auf deinem bildschirm denn bitte schwer zu finden? oben steht groß F A Q

[eyestorm]

Die hatte ich mir alle schon angesehen, nur leider steht dort nichts von dieser kanonischen Zone.. die MX Angaben stehen einfach darunter:

Code: Select all

$TTL 1W
@               IN      SOA     ns.scha.biz.    hostmaster.scha.biz. (
                                2002123001      ; serial
                                8H              ; refresh
                                2H              ; retry
                                1W              ; expiry
                                11h )           ; minimum
;
; Zone name server records
;
                IN      NS      ns
                IN      NS      ns.schlund.de.
;
; Zone mail exchange records
;
                IN      MX      10      mx
;
;  Zone records
;
                IN      A       217.160.92.19
*               IN      A       217.160.92.19

So wollte ich's auch die ganze Zeit machen, nur sicher war ich mir nicht.

cu eyestorm

[jp]

das ist eine canonische zone, ja.

warum diese bezeichnung da nicht steht, kann ich dir nicht beantworten. hat der autor vermutlich unterschlagen.

und dass die angaben einfach darunter stehen, hat auch seinen grund. es geht natürlich aber auch mit expliziter angabe.
wie gesagt: kauf dir ein gutes DNS/BIND buch und finde die syntax selbst heraus...

[eyestorm]

Gerne, nur jetzt wollte ich erstmal mein Mailsystem absichern ;) Danke für die Hilfe, werde dann aber nur die MX-Zeilen hinzufügen, oder brauche ich den Rest auch?

cu eyestorm

[eyestorm]

Hat scheinbar geklappt :-D musste aber in default.hosts

[jp]

Hat scheinbar geklappt :-D musste aber in default.hosts

8O
....

:roll:

[eyestorm]

Code: Select all

cat default.hosts
$TTL 1W
@               IN SOA  ns   hostmaster (
                        2003063000
                        8H
                        2H
                        1W
                        12H )

@               IN NS   ns
@               IN NS   ns.schlund.de.

@               IN A    217.160.200.000
*               IN A    217.160.200.000

@               IN MX   100 mail
*               IN MX   100 mail

@               IN MX   200 mx01.schlund.de.
*               IN MX   200 mx01.schlund.de.

@               IN MX   210 mx02.schlund.de.
*               IN MX   210 mx02.schlund.de.

Naja, also in 200.160.200.zone hat's nie geklappt, also habe ich default.hosts erweitert bis dig die richtige Antwort bekommen hat ;) Falsch?

[jp]

*haarerauf* :twisted:

nee, ich helf dir nicht mehr!
sämtliche RFCs verletzt - und du weißt ja nichtmal im geringsten, wovon du redest - geschweige denn was du da tust...

[eyestorm]

nee, ich helf dir nicht mehr!

Schade!

sämtliche RFCs verletzt - und du weißt ja nichtmal im geringsten, wovon du redest - geschweige denn was du da tust...

Korrekt, kenne mich damit überhaupt nicht aus, aber versuche es nochmal mit dem IP-Zone-File.

cu eyestorm