DNS Mailserver

Wie wir in der Postfix Übersichtsskizze bereits gesehen haben, ist ein funktionierendes DNS Voraussetzung, da es so für so gut wie jeder Mailtransport als grundlegender Dienst -Anfrage stellt.

Für den ordnungsgemäßen Betrieb unseres Mailservers ist es daher unabdingbar, dass unser Nameserver richtig konfiguriert wurde und saubere Rückmeldungen liefert.

Vor allem mit Hinblick auf die Teilnahme am eMail-Verkehr mit anderen Mailservern ist hierbei besonders zu achten!

DNS Records

Bevor wir zu den einzelnen MTA1)-Spezifischen 2)-Records kommen, werfen wir kurz noch einen Blick auf die wesentlichen Record-Typen.

A Record

Mit Hilfe eines A Records wird einem FQDN3)-Hostnamen eine oder auch mehrere IPv4-Adressen zugewiesen.

Bei der Suche nach der IP-Adresse des Hosts mx01.nausch.org wird bei der forward-Auflösung die zugehörige IP-Adresse 217.91.103.190 ermittelt.

$ dig A nausch.org +short 
217.91.103.190

AAAA Record

Der AAAA Record ist das IPv6-Pendant zum A Record, sprich der AAAA Record bildet einen FQDN4)-Hostnamen auf eine oder mehrere IPv6-Adressen ab.

$ dig AAAA mail.sys4.de +short 
2001:1578:400:111::7

CNAME Record

Mit Hilfe eines CNAME5) kann man einem bestehenden A- bzw. AAAA-Record einen weiteren Namen zuweisen, also einen Alias damit festlegen.

# dig mysql.dmz.nausch.org
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> mysql.dmz.nausch.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38766
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;mysql.dmz.nausch.org.          IN      A

;; ANSWER SECTION:
mysql.dmz.nausch.org.   86400   IN      CNAME   vml000030.dmz.nausch.org.
vml000030.dmz.nausch.org. 86400 IN      A       10.0.0.30

;; AUTHORITY SECTION:
dmz.nausch.org.         86400   IN      NS      vml000020.dmz.nausch.org.

;; ADDITIONAL SECTION:
vml000020.dmz.nausch.org. 86400 IN      A       10.0.0.20

;; Query time: 0 msec
;; SERVER: 10.0.0.20#53(10.0.0.20)
;; WHEN: Tue Oct 14 14:04:22 2014
;; MSG SIZE  rcvd: 118

MX Record

Ein MX6)-Record definiert einen oder mehrere Hostnamen, derjenigen Mailserver, die für die entsprechende Domain eMails zuständig sind.

$ dig MX +short nausch.org
10 mx01.nausch.org.
20 mx1.tachtler.net.

Mit der Priorität - im obigen Beispiel 10 bzw. 20 wird angegeben, dass der Mailserver mit der höheren Priorität 10 bevorzugt angesprochen werden soll, und erst wenn dieser nicht antwortet auf den Backupmailserver mx1.tachtler.net mit der geringeren Priorität 20 ausgewichen werden soll.

Meist wird jedoch von SPAMern diesem Wunsch nicht entsprochen, da diese sich bevorzugt an den Backup-Mailserver wenden, in der Hoffnung, dieser sei nachlässiger gepflegt und somit geringer geschützt.

Aus diesem Grund werden z.B.

oft auch die Mailserver im als gleichwertig hinterlegt, wie in diesem Beispiel.

$ dig MX sskm.de +short 
10 mx13.sskm.net.
10 mx14.sskm.net.
10 mx11.sskm.net.
10 mx12.sskm.net.

Bei der Definition des MX-Records ist darauf zu achten, dass der MX-Record weder direkt auf eine IP-Adresse zeigt, noch auf einen CNAME-Record verweist!

NS Record

Ein NS7)-Record definiert entweder welche Nameserver offiziell für eine Zone zuständig ist, oder er verknüpft einzelne Zonen einer Domain zu einem Zonen-Baum, auch Delegation genannt.

$ dig NS mailserver.guru +short 
ns1.core-networks.de.
ns3.core-networks.com.
ns2.core-networks.eu.

PTR Record

Ein PTR8)-Records weist einer IP-Adresse einen oder mehrere Hostnamen zu.

Dieser Eintrag stellen somit das Gegenstück zu den beiden Record-Typen A un AAAA dar.
Beim sogenannten reverse lookup wird beim angefragt, welcher Name bzw.
welche Namen zu einer genannten IP-Adresse bekannt ist. * IPv4:
$ dig -x 88.217.171.167 +short
mx1.tachtler.net.
IPv6:
$ dig -x 2001:1578:dead:beef::7 +short
mail.sys4.de.

Obwohl es keine 100%ige Definition in einem betreffenden 9), der vorschreibt, dass die IP-Adresse eines Mailservers auf dessen im A-/AAAA-Record definierten Namen zeigen muss, wird diese Forward-/Reverse-Auflösung von vielen Mailservern verwendet um bei negativem Ergebnis dieser Anfragen den einliefernden Host mit einem Malus zu belegen.

Wir sind also gut bedient, wenn wir uns an diese Spielregeln halten und dies bei der Definition der -Einträge unseres Mailservers berücksichtigen.

SPF Record

Mit Hilfe von SPF 10) kann definiert werden, welche Mailserver für welche Domains eMails verschickt werden (können), oder nicht, oder anders ausgedrückt, soll das Fälschen von Absender-Angaben mit Hilfe von SPF erschwert werden.

Genauer gesagt schreibt das SPF fest, welcher MTA11) abgehend für den Versandt von e-Mails einer Domain zugelassen ist.
Wichtige Hinweise zu SPF findet man bei Bedarf in der überarbeiteten Version RFC 6652 12) oder auch auf der Webseite von openspf.org.

$ dig TXT nausch.org +short
"v=spf1 ip4:217.91.103.190/32 mx ?all"

SRV Record

Mit Hilfe eines SRV13)-Records können IP-basierte Dienste, die eine Domain zur Verfügung gestellt werden, veröffentlicht werden.

Je Service werden dabei die nötigen Informationen geliefert, die ein Client/Server benötigt, der diesen Dienst nutzen möchte.
Jeder dieser Dienste wird durch einen Namen und dessen Protokolls, abgetrennt mit einem Punkt ., repräsentiert.
Damit es zu keinen Verwechslungen mit anderen Sub-Domains gibt, wird den beiden vorgenannten Werten ein „_“ vorangestellt.

Beispiel

$ dig -t SRV _autodiscover._tcp.it-ignorant.org +short
10 0 443 autodiscover.nausch.org.

Ein Client der diese Anfrage stellt erhält folgende Informationen:

10 Priorität des angebotenen Dienstes.
Hat man mehr als einen Host, der diesen Dienst anbieten soll, kann somit festgelegt werden, welcher Host bevorzugt angesprochen werden sollte.
0 Will man bei gleicher Priorität mehrere Hosts, so kann man für die Lastverteilung über die Gewichtung definieren, welcher Host gewählt werden soll.
443 Der Dienst wird über Port 443 angeboten
autodiscover.nausch.org Definition des Hostsnamens, der den Dienst anbietet

Dieses Beispiel wir unter anderem dazu verwendet um M$-Outlook die Konfigurationsdaten unseres Dovecot-MDAs14) automatisch zu übermitteln

TXT Record

Mit Hilfe eines TXT15)-Records kann man einen frei definierbarern Text in einer -Zone abgelegen.

Nachfolgend gehen wir kurz auf entsprechende TXT-Records im Mailserverumfeld ein.
SPF: So wird z.B.
bei einem SPF-Record definiert, welche Server Mails einer Domäne verschicken darf, und welcher nicht.
$ dig TXT nausch.org +short
"v=spf1 ip4:217.91.103.190/32 mx ?all"
DKIM: Ein weiterer Anwendungsfall eines TXT-Records im Bezug auf Mailserver ist die Veröffentlichung eines DKIM 16)-Schlüssels.
$ host -t TXT 140224._domainkey.nausch.org
;; Truncated, retrying in TCP mode.
140224._domainkey.nausch.org descriptive text "v=DKIM1\; p=" "MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAuJ3/CruOs3fCU0ujOStc" "NN85TJh+5HvMa9m99C5XuRBlxOr+fp5BeIEtiPO0szKvvPojwrueCq0oOuEzjR/i" "2ObpRkzKRUXmAa0qVezUZwQIbKeiuKII0PnpQclDrmQrzSXcQWPT57tkPg17Q9Wa" "mFUUaHeN3+pVGtMyjYekRaAoRlV+a1gD111kXMPhiaFTMIncoRBS/gYN8FjfekH+" "ezqbLHLB8DLJQBZEGUILvJjAHX0722XyqYtkn1qfv63nPRGw/qqAW1072Gchq4ZS" "4ZPQ89SrK4KcHt/XptSlztXMWtmRFQriHdvbjr1Fx7ZwXdTQ+ik2AUZLMdhMrQe6" "/1GujQiMD6po81NpYbrjnfd+QF4sUbus4wPQKVNzsctiuzGlWsFexSHP4dAZtKnI" "mJhVDnzZODQy0nSafedlr5g4VR36vgm0YPWjSyRNnC/APHyw0DtHIrzTqfKuDeGv" "80uMPbEdujrw9gLbK3H8ow42iTicmgPgT3J5j70ZOo4o4FMtpZ/AEQw+VnWpSfw7" "bkMjufLc29XHbtp22wfgq2Lmarr3+psaHokFaQrImkMbzdSL9CdabkLptanAilLS" "cvq8UaKVC+G1+vHDgaweq3BhXD5+YcJnJlp4msUqqxGYlnx4RSvv8PipMU2DsVFb" "NJSH5NJuS7GuzplNg+f20ysCAwEAAQ=="
ADSP: Über ADSP17) kann ein (Mail)-Domaininhaber definieren, was ein Mailserver mit einer zu Annahme anstehenden eMail passieren soll, sofern dessen DKIM18)-Signatur nicht gültig ist.
Für ADSP wird dazu ein eigener Qualifier _adsp benutzt.
Am Beispiel der Domain sec-mail.guru ergibt sich der Name _adsp._domainkey.sec-mail.guru.
$ host -t TXT _adsp._domainkey.sec-mail.guru
_adsp._domainkey.sec-mail.guru descriptive text "dkim=discardable\;"
Der (TXT)-Datensatz hat dabei folgende Struktur „dkim=<WERT>“. Über den <WERT> kann der Domaininhaber folgendes festlegen:
- unknown Der Domaininhaber signiert einige oder alle Nachrichten.
- all Alle Nachrichten der Mail-Domäne werden mit einer DKIM-Signatur versehen.
- discardable Alle Nachrichten der Mail-Domäne werden mit einer DKIM-Signatur versehen.
Darüber hinaus empfiehlt der Domain-Inhaber alle Nachrichten deren DKIM-Signatur gebrochen wurde, bei der die Nachricht also manipuliert wurde, zu Verwerfen (REJECT).
DMARC: Bei DMARC 19) kann definiert werden, wie ein empfangender Mailserver Nachrichten behandeln und verarbeiten soll, insbesondere mit Hinblick auf die Bewertung der Versandberechtigung des einliefernden Mailservers (SPF) und der nicht veränderten Nachricht (DKIM).
Fällt eine oder beide Überprüfungen negativ aus, definiert DMARC, ob die eMail in Quarantäne gestellt, die Annahme der eMail abgelehnt (reject) oder eben dennoch zugestellt werden soll.
$ dig -t TXT _dmarc.nausch.org +short
"v=DMARC1\; p=none\; pct=100\; rua=mailto:dmarc-reports@nausch.org,mailto:pv27ekln@ag.dmarcian.com\; ruf=mailto:dmarc-fails@nausch.org,mailto:pv27ekln@fr.dmarcian.com\;"
Eine Beschreibung der einzelnen Parameter findet man hier im Wiki im Kapitel DMARC - Domain-based Message Authentication, Reporting & Conformance.