DNS Einstellungen

Für den erfolgreichen Mailserverbetrieb müssen wir nun ein paar wichtige DNS-Konfigurationen vornehmen.

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.

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

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.

Gemäß unserer Konfiguration setzen wir nun für den Postfix-Mailserver mx1.nausch.org den DNS-Eintrag.

$ 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.

# 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.

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!