DNS Einstellungen
DNS "MX-Beispiele"
Für den erfolgreichen Mailserverbetrieb müssen wir nun ein paar wichtige DNS-Konfigurationen vornehmen.
Zwei gleichberechtigte MXer
Nehmen wir mal als Beispiel die Domäne omni128.de. Dort haben wir zwei gleichberechtigte Mailserver stehen:
$ dig omni128.de MX ; <<>> DiG 9.3.4-P1 <<>> omni128.de MX ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3017 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 10 ;; QUESTION SECTION: ;omni128.de. IN MX ;; ANSWER SECTION: omni128.de. 81640 IN MX 10 mx01.schlund.de. omni128.de. 81640 IN MX 10 mx00.schlund.de.
Beide Mailserver haben die Priorität 10 und werden daher im round-robin Betrieb angesprochen.
MXer mit unterschiedlichen Prioritäten
Im Gegensatz dazu haben wir bei tachtler.net zwei Mailserver mit unterschiedlicher Priorität:
$ dig tachtler.net MX ; <<>> DiG 9.3.4-P1 <<>> tachtler.net MX ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4317 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 5 ;; QUESTION SECTION: ;tachtler.net. IN MX ;; ANSWER SECTION: tachtler.net. 3600 IN MX 10 mx00.udag.de. tachtler.net. 3600 IN MX 20 mx01.udag.de.
als erstes wird immer der mx00 angesprochen und sollte dieser nicht reagieren, dann der Backupmailserver mx01
MX als Cluster-/Einzelserverbetrieb
Im Gegensatz zu den beiden vorgenannten Varianten gibt es noch eine weitere dritte Option. Wie kucken uns dazu mal die Konstellation bei den Lokalisten an.
$ dig lokalisten.de MX ; <<>> DiG 9.3.4-P1 <<>> lokalisten.de MX ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53167 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 7 ;; QUESTION SECTION: ;lokalisten.de. IN MX ;; ANSWER SECTION: lokalisten.de. 295 IN MX 10 smtp.lokalisten.de.
Ob hier nun ein cluster oder „nur“ ein Mailserver im Einsatz ist, kann man sonicht ermitteln.
DNS-Konfiguration für nausch.org
Gemäß unserer Konfiguration setzen wir nun für den Postfix-Mailserver mx1.nausch.org den DNS-Eintrag.
DNS Forward Auflösung
$ dig @212.18.0.5 nausch.org MX ; <<>> DiG 9.3.4-P1 <<>> @212.18.0.5 nausch.org MX ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54013 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;nausch.org. IN MX ;; ANSWER SECTION: nausch.org. 78155 IN MX 10 mx1.nausch.org.
Somit ist unser Mailserver schon mal für den ankommenden gewappnet.
DNS Forward Auflösung mit Backupmailserver
# dig @212.18.0.5 nausch.org MX ; <<>> DiG 9.2.4 <<>> @212.18.0.5 nausch.org MX ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29032 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;nausch.org. IN MX ;; ANSWER SECTION: nausch.org. 86400 IN MX 20 mx1.tachtler.net. nausch.org. 86400 IN MX 10 mx1.nausch.org.
Unsere Domäne nausch.org hat also nun zwei Mail-Exchanger, einen Hauptserver mit der höheren Priorität 10 und einen Bachup-Mailserver mit der Prio 20.
DNS Reverse Auflösung
Da unser Mailserver auch direkt Mitteilung an andere Mailserver absetzen soll, müssen wir nun darauf achten, dass die reverse-Auflösung unserer Mailserver-IP-Adresse auf den richtigen Namne zurückverweist.
$ dig -x 88.217.187.21 ; <<>> DiG 9.3.4-P1 <<>> -x 88.217.187.21 ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7274 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 6 ;; QUESTION SECTION: ;21.187.217.88.in-addr.arpa. IN PTR ;; ANSWER SECTION: 21.187.217.88.in-addr.arpa. 7200 IN PTR mx1.nausch.org.
Andererseits würden wir nämlich mit sehr sehr hoher Wahrscheinlichkeit extreme Schwierigkeiten haben, wenn wir bei anderen Mailserver Post abliefern wollten, die zur SPAM-Abwehr greylisting-Mechanismen einsetzen.
Reverse-Auflösungen, ala
$ dig -x 88.217.83.134 ; <<>> DiG 9.3.4-P1 <<>> -x 88.217.83.134 ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15144 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 6 ;; QUESTION SECTION: ;134.83.217.88.in-addr.arpa. IN PTR ;; ANSWER SECTION: 134.83.217.88.in-addr.arpa. 7200 IN PTR ppp-88-217-83-134.dynamic.mnet-online.de.
wären demnach zum Scheitern verurteilt und sollten, wie bereits angesprochen, tunlichst vermieden werden!