Ich weiß wie du dich fühlst.
Eine schnelle Lösung, die vielleicht funktioniert:
Ich würde der zweiten Domain einen MX-Record anlegen, der auf den A/AAAA-Record von domain-eins.tld zeigt. Wenn dein Mailserver bereits läuft, sollte das funktionieren. Sollte. Bei DNS kann man viel falsch machen. Wenn du bei der zweiten Domain die Einstellungen "verkackst" dürfte nichts passieren. Die erste Domain lässt du so wie sie ist.
Hier mal ein Beispiel wie ich das machen würde:
Das Zertifikat für den Webserver ist auf domain-eins.tld ausgestellt. Ein zweites Zertifikat für den Mailserver ist auf mail.domain-eins.tld ausgestellt (commonName).
Der A-Record zeigt auf Web-/Mailserver. Angenommen dein Mailserver hat die IP 192.168.0.1. IPv6 möchte ich mal vernachlässigen. Wir legen jetzt mail.domain-eins.tld als A-Record für deinen Mailserver an.
Für domain-eins.tld ist dann weiter unten der MX mail.domain-eins.tld eingetragen:
user@
domain-eins.tld -> MX-Record: mail.domain-eins.tld -> A/AAAA-Record für mail.domain-eins.tld > IPv(4|6)-Adresse des Mailservers.
domain-eins.tld
Code:
domain-eins.tld. A 192.168.0.1
mail.domain-eins.tld. A 192.168.0.1
domain-eins.tld. MX mail.domain-eins.tld.
Die domain-zwei.tld wird etwas einfacher. Dort wird lediglich ein MX-Record angelegt, der auf den A/AAAA-Record des Mailservers zeigt. Also in diesem Beispiel mail.domain-eins.de.
domain-zwei.tld
Code:
domain-zwei.tld. A 192.168.10.1
domain-zwei.tld. MX mail.domain-eins.tld.
Sollte der Mailserver mal eine andere IP bekommen, weil du diesen z.B. getrennt hosten möchtest, musst du nur den A/AAAA-Record für mail.domain-eins.tld ändern.
Wenn der MX-Eintrag lediglich auf die Domain zeigt, ist es z.B. nicht möglich den Mailserver auf einem anderen Host in Betrieb zu nehmen.
Also du schränkst dich mit der Konfiguration selbst ein. Hier mal ein paar MX-Einträge zu anderen Domains mit einem Mailserver auf einem anderen Host als der Webserver:
Code:
Domain: heise.de -> 193.99.144.80, MX: relay.heise.de -> MX-IP: 193.99.145.50
Domain: golem.de -> 109.68.230.138, MX: kms.syseleven.de -> MX-IP: 176.74.58.26
Domain: gmx.de -> 82.165.229.87, MX: mx00.emig.gmx.net -> MX-IP: 212.227.15.9
Domain: hetzner.de -> 213.133.107.227, MX: mail.hetzner.company -> MX-IP: 213.133.106.242
Domain: ovh.net -> 213.186.33.6, MX: mx2.ovh.net -> MX-IP: 137.74.125.139
Domain: strato.de -> 192.67.198.33, MX: post12.in.strato.de -> MX-IP: 192.166.201.40
Serversupportforum hostet z.B. den Mailserver auf der gleichen IP wie den Webserver, hat aber den MX-Record mail.serversupportforum.de.
Der A-Record löst die gleiche IP auf, wie der A-Record von serversupportforum.de.
Am besten versteht man das, in dem man sich mal mit nslookup ein paar Domains selbst ansieht und die Schritte, die ein Mailserver bei der Namensauflösung macht, manuell nachvollzieht.
Code:
nslookup -query=MX heise.de:
Server: 192.168.178.1
Address: 192.168.178.1#53
Non-authoritative answer:
heise.de mail exchanger = 10 relay.heise.de.
MX = relay.heise.de
Code:
nslookup -query=A relay.heise.de.
Server: 192.168.178.1
Address: 192.168.178.1#53
Non-authoritative answer:
Name: relay.heise.de
Address: 193.99.145.50
IP des Mailservers:
193.99.145.50
commonName = CN = relay.heise.de
Zertifikat
Code:
!openssl s_client -connect relay.heise.de:25 -starttls smtp
CONNECTED(00000003)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = relay.heise.de
verify return:1
---
Certificate chain
0 s:/CN=relay.heise.de
i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
=ENTFERNT=
-----END CERTIFICATE-----
subject=/CN=relay.heise.de
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3170 bytes and written 466 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: BBCBBE9F212E03927A4A2AFC66FEE2B3C0FAC7D2A6273338608676B4493D73FD
Session-ID-ctx:
Master-Key: AD87C11C1B5C783BB1DC6C11EE2E4A0517324D7871D1E3AB026FAD0006E7898D600A0CF703E56BE4B8F0F6B6A70FBB22
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1487157866
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
250 HELP
quit
221 relay.heise.de closing connection
closed
Wie man erkennen kann, stimmt der CN (commonName) mit dem MX-Eintrag überein. Stimmt er nicht überein, beendet die Gegenstelle hoffentlich die Verbindung. Es wird auch geprüft ob das Zertifikat gültig ist, ob es durch einen bekannten CA ausgestellt worden ist und ob es innerhalb des gültigen Zeitraums ist. (Stell die Uhr mal um 2 Jahre zurück und schau dann mal welche Internetseiten noch funktionieren)
Schau dir ein paar gute Tutorials über SSL + Postfix + DNS an. Dort wirst du überall das gleiche Muster sehen. Das ist wichtig, dass du das verstehst.
Du musst auch acht geben, dass deine Zertifikate erneuert werden. Bei Let's Encrypt sind die nur für 3 Monate gültig und können nur für eine Domain ausgestellt werden.
Daumen Hoch!
