Wie wir in der Postfix Übersichtsskizze bereits gesehen haben, ist ein funktionierendes DNS Grundvoraussetzung, da es so für so gut wie jeder Mailtransport als grundlegender Dienst DNS-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!

Bevor wir zu den einzelnen MTA¹⁾-Spezifischen DNS²⁾-Records kommen, werfen wir kurz noch einen Blick auf die wesentlichen Record-Typen.

Mit Hilfe eines A Records wird einem FQDN³⁾-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

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

 $ dig AAAA mail.sys4.de +short 

 2001:1578:400:111::7

Mit Hilfe eines CNAME⁵⁾ 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

Ein MX⁶⁾-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 DNS 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.

Ein NS⁷⁾-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 nausch.org +short 

ns1.core-networks.de.
ns3.core-networks.com.
ns2.core-networks.eu.

Ein PTR⁸⁾-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 DNS 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.

Mit Hilfe von SPF¹⁰⁾ 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 MTA¹¹⁾ 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¹²⁾ oder auch auf der Webseite von openspf.org.

 $ dig TXT nausch.org +short

 "v=spf1 ip4:217.91.103.190/32 mx ?all"

Mit Hilfe eines SRV¹³⁾-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-MDAs¹⁴⁾ automatisch zu übermitteln

Mit Hilfe eines TXT¹⁵⁾-Records kann man einen frei definierbarern Text in einer DNS-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¹⁶⁾-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 ADSP¹⁷⁾ kann ein (Mail)-Domaininhaber definieren, was ein Mailserver mit einer zu Annahme anstehenden eMail passieren soll, sofern dessen DKIM¹⁸⁾-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¹⁹⁾ 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.

Für den erfolgreichen Mailserverbetrieb müssen wir nun ein paar wichtige DNS-Konfigurationen vornehmen. Wir benötigen dabei mindestens folgende Einträge:

• A bzw. AAAA-Record
• PTR-Record
• MX-Record

Die folgenenden Records sind optional:

• SPF-Record
• SRV-Record
• TXT-Records:
  • SPF-Records
  • DKIM-Record
  • ADSP-Record
  • DMARC-Record

Bei den Einzelnen Anwendungen und Lösungen werden wir auf ggf. nötige Anpassungen im DNS zurückkommen.

• ⇐ Zurück zum Kapitel „Installation und Basiskonfiguration von Postfix 2.11 bzw. 3.x unter CentOS 7“
• ⇒ Weiter zum Kapitel „Konfiguration unseres MTAs Postfix 2.11 bzw. 3.x unter CentOS 7“
• Zurück zum Kapitel >>Mailserverinstallation unter CentOS 7<<
• Zurück zu >>Projekte und Themenkapitel<<
• Zurück zur Startseite