Frage, CNAME und Lets Encrypt

D

Domi

Member
Moin... Ich hab da mal eine Frage an die Leute mit Lets Encrypt, E-Mail Server und Herr über DNS :)

Kurz vorweg, meine Domains liegen bei INWX, ich habe Server bei Netcup, Hetzner oder auch Contabo.

Auf einem der Server habe ich seit etwas über einem Jahr Mailcow drauf, mit dem bin ich echt happy... und das obwohl es nur so ein "ich klicke mir schnell was zusammen" Ding ist, aber es tut seinen Dienst.

Bei einem der anderen Server ist ein ISPconfig drauf, so dass der eine oder andere Kunde (wenn sie es dann tun wollen) ihre E-Mail Adressen selbst anlegen oder verwalten können, ohne dass ich dieses immer mache. Nun haben ja Anbieter wie ionos. all-inkl etc., immer als Adresse für Posteingangs- und Postausgangsserver deren Hostnamen angegeben, damit es kein SSL / TLS Problem gibt.

Nun könnte ich ja sagen dass mail.kunden-domain.tld ein CNAME mit dem Ziel zu mein-server.domain.tld ist.

Allerdings würde dann Thunderbird, Outlook (und alle anderen ebenfalls) meckern weil das Lets Encrypt Zertifikat für mein-server.domain.tld ausgestellt ist. Gibt es dafür eigentlich einen eleganten Weg via DNS um das zu umgehen?

An sich verfehlt das wieder den Zweck des SSL / TLS Zertifikates, aber vielleicht gibt es ja doch dafür einen Trick.

Ich würde nämlich gerne einem Kumpel von mir ebenfalls Zugriff auf meinen Mailcow Server anbieten, dann kann er mit den Mails vom ISPconfig System weg, aber er müsste dann bei allen Clients die Adresse für die Server anpassen. Andernfalls könnte ich sonst einen CNAME hinterlegen und umbiegen.

Keine Ahnung ob ich das gut erklären konnte, aber falls es dazu einen Tipp gibt, höre ich mir das gerne an. Falls das generell NICHT geht (sonst würden es wohl die großen Provider schon längst so machen), ist das eben so.

Gruß, Domi
 
Ich meine aber nicht den MX Record... :)

Nachtrag: Ah... du gehst vermutlich davon aus dass MX-Record = mail.kunden-domain.tld und mail.kunden-domain.tld ist ein A-Record auf die IP... aber man kann dieses ja auch separat steuern.
 
Last edited:
Reverse Proxy kenne ich immer nur für Webapplikationen (Port 80, 443), lässt sich so etwas auch für IMAP, POP3 oder SMTP anwenden?
 
Nein, tue ich nicht. Du glaubst es nur. Lass uns aber bitte auf einen Nenner kommen, erhelle mich, warum ich dieses tun sollte :)

Du gehst davon aus, dass z.B. bei mir im Thunderbird, Outlook (what ever) die Adresse hinterlegt ist die auch im MX-Record meiner Domain hinterlegt ist, doch dass ist nicht so.

Nachtrag: Irgendwo konnte man sich ne "analoge" Auswertung (dos like) für die NS Einträge einer Domain anfertigen, nun muss ich das händisch zusammen ferkeln...
Code: 
domain.tld

* A [meine IP]
"" A [meine IP]
mail A [IP von m01.anderedomain.tld]
www A [meine IP]
"" MX m01.anderedomain.tld
 
Last edited:
Um auf deine Ausgangsfrage zurückzukehren: Nein, per DNS geht das nicht. Du brauchst natürlich einen DNS-Eintrag für mail.kunden-domain.de (am besten per A-Record, dann kannst du in auch im MX verwenden) und du musst dein Zertifikat anpassen, dass es mehrere FQDNs enthält - bei certbot mit dem -d Parameter. CNAME würde ich übrigens nur einsetzen, wenn ich nicht kontrollieren kann, wann das Ziel des CNAME die IP wechselt. Außerdem erzeugt ein CNAME eine zusätzliche DNS-Abfrage, die man sich sparen kann.
 
Hallo in die Runde,

vielen Dank für die Info. Es war auch nur so ein Gedanke ob man das umgehen kann. Auf meinem ersten Server, auf dem Webseiten und E-Mails liegen, hab ich sogar mehrere Domains hinterlegt. Jeder Server von mir ist durchnummeriert beim Hostnamen... das heißt,
-> srv01.domain.tld (gesetzt für Hostname, A-Record, MX-Record, PTR / Reverse DNS etc.)
-> srv02.domain.tld (gesetzt für Hostname, A-Record, MX-Record, PTR / Reverse DNS etc.)

In dem Zertifikat für srv01.domain.tld habe ich auch mail.kunde1.tld, mail.kunde2.tld etc. hinterlegt.

Natürlich kann ich bei der Domain kunde1.tld einen A-Record "mail.kunde1.tld" auf meine IP einrichten und den MX-Record dann auf mail.kunde1.tld zeigen lassen. Das wird auch dass sein, was @Joe User meint (hoffe ich). Bei einigen Domains ist das auch so, bei andere Domains zeigt der MX-Record aber auf srv01.domain.tld, der wiederum ein A-Record und AAAA-Record auf die IP des Servers ist :)

Natürlich gibt es auch ein A-Record "mail.kunde1.tld", die auch auf diesen Server zeigt, aber das eine oder andere ist historisch so entstanden.

Daher kam der Gedanke,
- MX-Record = srv01.domain.tld
- CNAME-Record = mail.kunde1.tld -> srv01.domain.tld

um das SSL / TLS Debakel zu umgehen.

War aber halt nur ein Gedanke... als IT'ler versucht man ja immer gerne einen Trick um etwas "leichter" zu machen ;)
 
Ein CNAME-Record ist nur ein DNS-Alias, d.h. die Auflösung zur IP ist hier umfangreicher (zusätzliche Abfrage, um an die IP zu kommen). Es ist nicht sowas wie eine HTTP-Weiterleitung, die ein Webserver an den Browser schickt.
 
Domi said:
In dem Zertifikat für srv01.domain.tld habe ich auch mail.kunde1.tld, mail.kunde2.tld etc. hinterlegt.
Click to expand...
Aber das ist doch imho datenschutztechnisch schon sehr bedenklich. Da weiß ja dann jeder Kunde welche Kunden Du noch hast. Und alle die einem Deiner Kunden was schicken auch.

Keep it simple: verwende EINEN DNS Namen für alle MX Records. z.B. mail.ichbinderhoster.de. Der wird dann als MX Record für kunde1.tld, kunde2.tld, etc. eingetragen. Dann brauchst Du auch genau EIN Zertifikat. Und fertig.
 
Joa, Komfort hört da auf wo Sicherheit anfängt etc. auch wenn es "Kunden" sind, sind das zu 80% Bekannte / Verwandte und die machten gerne "mi mi mi" und fragten, wieso sie denn nicht smtp.domain.tld oder pop.domain.tld nutzen könnten und SSL immer meckert. So kam ich dann auf die Idee, ich biege die mail.domain.tld zum korrekten Ziel.

Was ich aber erst im Nachhinein erfahren habe, man kann wohl einen "Autodiscover" (oder ähnliches) hinterlegen. Den kann nicht nur Outlook auslesen, Thunderbird und Co können wohl auch damit umgehen. So könnte ich denen dann für deren Domain den korrekten Eintrag hinterlegen lassen.

Dann brauche ich am Ende wirklich nur noch eine Domain / Subdomain im Zertifikat hinterlegen :)

Dieses "Spektakel" hatte ich sogar auf den Web-Adressen... mein Server ist mit ISPconfig bestückt und hier muss man am Ende auch noch mal Hand anlegen, damit es eine Default Domain für SSL gibt und damit Directory Listing deaktiviert ist. Entweder bei mir oder bei meinem Kumpel auf seinem Server war es nämlich so, dass mal einer eine Domain mit https öffnen wollte, dieses aber für diese Domain nicht aktiv war und somit landete er auf der ersten Domain die via SSL abgesichert war.

Aber lange Rede kurzer Sinn... Für die Zukunft hinterlege ich nur eine Domain im LE Zertifikat und gucke ob es der Autodiscover war, dann wird der hinterlegt und hoffentlich zieht sich dann der Client (das Endgerät) die korrekte URL selbst.
 
Domi said:
Joa, Komfort hört da auf wo Sicherheit anfängt etc. auch wenn es "Kunden" sind, sind das zu 80% Bekannte / Verwandte und die machten gerne "mi mi mi" und fragten, wieso sie denn nicht smtp.domain.tld oder pop.domain.tld nutzen könnten und SSL immer meckert. So kam ich dann auf die Idee, ich biege die mail.domain.tld zum korrekten Ziel.
Click to expand...
Ich erinnere mich an eine Folge von Star Trek TNG:

Problem: Wie können wir verhindern, dass der Mond auf den von Ihm umkreisten Planeten stürzt?
Antwort von Q - der vorübergehend seine Kräfte verloren hat: Ganz einfach: Wir verändern einfach die Gravitationskonstante des Universums!

Lektion: Es gibt einfach ein paar Sachen, die muss man hinnehmen so wie sie sind. Und wenn Deine Bekannten und Verwandten einen Wunsch-Mail-Server-Namen haben und den richtigen nicht eintragen wollen, dann ist das IMHO erst mal deren Problem, weil dann Ihr E-Mail nicht geht.

Aber natürlich kannst Du Dir da auch die extra Mühe machen und noch autodiscover einrichten. Ich weiss nicht ob ispconfig das direkt selbst kann oder ob Du da u. a. noch automx2 (https://github.com/rseichter/automx2) dafür bemühen musst, samt der DNS-Konfiguration für Deine ganzen Domains. Sei Dir aber bewusst, dass autodiscover ein zusätzlicher Dienst ist, der immer laufen muss. Ich bin mir nicht ganz sicher, aber ich meine dass z. B. Outlook autodiscover bei jedem Start des Programms geprüft wird und eine entsprechende Fehlermeldung erzeugt, wenn autodiscover nicht erreichbar ist.
 
Last edited:
Ich hoste auch einen Mailserver. Und da wird bei allen Domains drauf mein vorgegebener DNS Record für deren MX verwendet. Punkt.
 
greystone said:
Aber natürlich kannst Du Dir da auch die extra Mühe machen und noch autodiscover einrichten.
Click to expand...
Es gibt fertige Scripte, mit denen man einen Autodiscover-Dienst bereitstellen kann. Bei den meisten dürfte ohnehin auch irgendwo ein Webserver laufen, der diese Information auch mit ausliefern kann. Wenn man das nur für ein paar Kumpels hostet, hat man die Zeit schnell wieder raus, weil die beim Einrichten am neuen PC nicht mehr anrufen und nachfragen: "Was muss ich denn da eintragen?" Und als Provider natürlich weniger Anrufe beim Support.
 
Hallo in die Runde,

der Ansatz mit dem Reverse Proxy gefällt mir übrigens sehr gut, dass werde ich demnächst in die Tat umsetzen. Ich hatte mich nämlich bei einer Sache etwas gefragt.

Angenommen ich habe nur einen einzigen Server... ob der nun bei Netcup, Hetzner, OVP, PHPfriends etc. steht, ist ja erst einmal egal.

Den Namen des Anbieters übernehme ich nicht, ich hab meine eigene Macke und nenne ihn srv01.domain.tld :)

Für die Domain kunde1.tld kann man ja nun im DNS zig Wege wähle (viele Wege führen nach Rom) und ich hab es dann immer wie folgt gemacht (wie oben),
Code: 
*     A   [IP von srv01.domain.tld]
""    A   [IP von srv01.domain.tld]
mail  A   [IP von srv01.domain.tld]
www   A   [IP von srv01.domain.tld]
""    MX  m01.kunde1.tld

Ich glaube irgendwann hier im Forum meinte sogar mal einer, dass der MX-Record doof sei, besser wäre es dann wie folgt die NS Einstellungen zu hinterlegen,
Code: 
*     A   [IP von srv01.domain.tld]
""    A   [IP von srv01.domain.tld]
mail  A   [IP von srv01.domain.tld]
www   A   [IP von srv01.domain.tld]
""    MX  srv01.domain.tld

klingt auch cool, kann man ja machen. Aber was ist, wenn man jetzt einen neuen Server aufsetzt... gesetzt der Logik wäre dieses ja nun srv02.domain.tld, was noch kein Thema ist. Aber nun kommt der Punkt an dem man sagt "ich löse Server 01 ab", da macht doch der Reverse Proxy am meisten Sinn. Oder sehe ich das falsch?

So könnte man am Reverse Proxy dann nämlich die Abfragen für IMAP, POP3 und SMTP die sonst immer auf srv01.domain.tld liefen, auf den neuen Server 02 umleiten und den Leuten mitteilen, dass sie doch bitte bei Gelegenheit die Einstellungen anpassen möchten, ODER man lässt es so laufen.

Das Video vom Apfelcast sowie von René Fürst bezüglich Nginx hab ich mir nämlich mal angeschaut und das war echt cool. Ob das über den via Docker zu installierenden Nginx Proxy Manager so zu steuern geht, hab ich noch nicht geschaut, aber wenn man mal einen Server Wechsel vor hat, kann man das darüber steuern lassen und die Domains / Subdomains (z.B. mail.kunde1.tld) via Lets Encrypt absichern.
 
Du kannst natürlich den ganzen Aufwand betreiben und einen Reverse-Proxy installieren. Das erhöht aber auch die Komplexität des Systems und ist eine zusätzliche Fehlerquelle. Da in deinem Beispiel als einziges der MX im DNS anders ist, ist der Wechsel auf einen neuen Server relativ einfach - einfach srv02.domain.tld im DNS bei allen Kunden-Domains eintragen. Der MX-Eintrag ist ja rein für andere Mailserver da, die Mails an diese Domains versenden.
Für die Mailclients verwendest du mail.domain.tld (oder von mir aus auch smtp.domain.tld, imap.domain.tld und pop.domain.tld, ist Geschmacksache) und nicht mail.kunde1.tld, mail.kunde2.tld usw. und musst auch da nur den einen DNS-Eintrag ändern. Warum keine Kundendomains? Das ist eher ein Thema bez. TLS-Zertifikaten des Mailservers. Im Browser hat sich SNI mittlerweile durchgesetzt, da ist der verwendete FQDN ja auch ein wichtiges Unterscheidungsmerkmal, welche Webseite präsentiert werden soll. Bei IMAP/POP/SMTP ist das nicht der Fall, dort entscheidet der Benutzername. Und für viele Mailclients gibt es mittlerweile Autoconfig-Methoden, damit diese anhand der eMail-Adresse den richtigen FQDN im Mailclient eintragen (z.B. Outlook, Thunderbird).
WIr reden hier von einer Übergangszeit, bis DNS-Änderungen sich rumgesprochen haben - wenn man die TTL für die DNS-Records geschickt setzt, sind das nur wenige Minuten.
 
danton said:
Da in deinem Beispiel als einziges der MX im DNS anders ist, ist der Wechsel auf einen neuen Server relativ einfach - einfach srv02.domain.tld im DNS bei allen Kunden-Domains eintragen.
Click to expand...
Genau, dass macht es ja auch super einfach. Bei INWX gibt es dafür sogar super simple ein "Find & Replace", wobei... wenn es jetzt nicht zu viele Domains sind, kann man das ja auch "mal eben" per Hand umstellen.

danton said:
Für die Mailclients verwendest du mail.domain.tld
Click to expand...
Ich muss ehrlich gestehen, mail.domain.tld fand ich irgendwie sympathischer also diese vielen Abkapselungen wie smtp.domain.tld, imap.domain.tld etc. :)

Spannend wird es allerdings, wenn der E-Mail Client (z.B. Outlook) auf mail.domain.tld eingerichtet ist und der Endanwender unbedingt SSL/TLS verwenden möchte, diese "alternativen" Domains nicht im Zertifikat hinterlegt ist, da dieses ja nur auf srv01.domain.tld läuft.

Und darum hatte ich mir angewöhnt in das Zertifikat welches auf srv01.domain.tld läuft, auch die ganzen mail.kunde1.tld, mail.kunde2.tld zu hinterlegen.

Hier kommt dann folgende Aussage von weiter Oben zu tragen...
Thunderbyte said:
Aber das ist doch imho datenschutztechnisch schon sehr bedenklich. Da weiß ja dann jeder Kunde welche Kunden Du noch hast.
Click to expand...

Und somit kam ich dann auf die Idee einen Reverse Proxy dazwischen zu schalten.

Ich hoffe ich konnte es relativ gut erklären... :)
 
1. Reverse Proxy wird nur für HTTP/HTTPS verwendet, nicht für POP3, IMAP(S), SMTP(S).
2. Eine sinnvolle DNS Konfiguration benötigt genau 3 (wesentliche) Sachen:

DNS Server der Domain:
- einen A Record, der für den Mailserver verwendet wird. Z.B. mail.domain.tld (mail.domain.tld -> 1.2.3.4 ->)
- Einen MX Record, der den Namen des A Records verwendet, also mail.domain.tld (bei Dir anders, die "mail" Zeile ist zudem zu * redundant.

Beim "Eigentümer" der IP Adresse (z.B. Serverprovider, Internetprovider, etc.):
- reverser PTR Record , der der IP des Mailservers einen DNS Namen zuordnet, also 1.2.3.4 -> mail.domain.tld

Für andere Domains als domain.tld, also z.B. wasweissich.tld wird dann halt auch als MX Record mail.domain.tld verwendet.

Zusätzlich dann noch Dinge wie SPF etc etc. Aber die ersten drei Sachen lassen den Mailserver schon mal funktionieren.
 
You must log in or register to reply here.
Back
Top