DNS Einstellungen

Für den ordnungsgemäßen Betrieb unseres Mailservers ist es natürlich unabdingbar, dass unser Nameserver richtig konfiguriert wurde und saubere Rückmeldungen liefert. Vor allem mit Hinblick auf die Teilnahme am eMailverkehr mit anderen Mailservern ist hierbei gesondert zu achten!

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 so nicht 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.

Betreiben wir unterschiedliche Zonen/Netzsegmente, so weisen wir diesen entsprechende MailGateWays zu. So können wir später auch recht einfach die oben genannten Möglichkeiten zur Lastverteilung und/oder Backupvarianten beim Verkehsfluss unserer eMails nutzen.

Beispiel DMZ:

 $ nslookup -querytype=MX dmz.nausch.org

Server:         10.10.0.120
Address:        10.10.0.120#53

dmz.nausch.org  mail exchanger = 10 vml000080.dmz.nausch.org.

Beispiel Intranet:

 $ nslookup -querytype=MX intra.nausch.org

Server:         10.20.0.120
Address:        10.20.0.120#53

intra.nausch.org        mail exchanger = 10 pml000080.intra.nausch.org.

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 SPAM-Abwehr-Mechanismen, wie z.B. greylisting oder ähnliches einsetzen.

Nachfolgendes Beispiel eine Reverse-Auflösungen, wären demnach zum Scheitern verurteilt und sollten, wie bereits angesprochen, tunlichst vermieden werden!

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

Inhaltsverzeichnis