Hallo,
eine Frage zur Best Practices bei einem Kunden.
Der Kunde hat eine Webdomäne: "kunde.de" und seit einigen Tagen einen dritten Internetzugang mit fester IP (ff. PIP).
EX 2019 läuft on premise. Er möchte gern, dass bei Ausfall egal welche PIP, über die anderen kommuniziert werden kann (E-Mail ein/ausgehend)
Nun braucht er ja mit seinem Zertifikat den klassischen "Tripple": autodiscover.kunde.de, mail.kunde.de, download.kunde.de
Wie optimieren wir nun seine Zugänge samt Zertifikate?
autodiscover.kunde.de, mail.kunde.de, download.kunde.de -> auf PIP1
autodiscoverPIP2.kunde.de, mailPIP2.kunde.de, downloadPIP2.kunde.de ->auf PIP2
autodiscoverPIP3.kunde.de, mailPIP3.kunde.de, downloadPIP3.kunde.de -> auf PIP3
Oder reicht nur ein autodiscover.kunde.de, weil der eh dann auf den MX-Record verweist? Die MX-Record sind dann mit Pro z.B. 10/20/30 versehen.
Für die autodiscover.kunde.de, mail.kunde.de, download.kunde.de haben wir bisher immer einen DNS Eintrag im Zertifikat. Also auch für PIP1 und PIP2
Somit wären dass 7 (ohne mehrfach autodiscover) bzw. 9 DNS Einträge im Zertifikat.
Wie macht man dies optimal?
Vielen Dank für Eure Tipps.
Danke und liebe Grüße.
Ergänzung:
Was mache ich mit dem SMTP Banner vom Exchange? Der kann doch nur auf einen Host verweisen - also "mail.kunde.de"?
Danke und liebe Grüße.
Für die Zertifikate sind die IP-Adressen und MX-Records völlig irrelevant, hier wird nur auf die korrekten Namen geschaut. Bei einem solchen Konstrukt gibt es aber meiner Meinung nach ganz andere Thematiken. Zum einen müssen die Namen und der MX-Record im DNS natürlich immer auf die korrekte IP verweisen. Und dann kommen so Sachen wie SPF, IP-Reputation usw. ins Spiel, die bei einem Wechsel der sendenden IP ein Problem werden können.
Genau, nur weil man drei Leitungen hat, wird so ein Konstrukt nicht einfach höher verfügbar, sondern erstmal deutlich komplexer. Wenn man es wirklich mit der Verfügbarkeit ernst meinst, wird man nicht um loadbalancer mit geoloadbalancing herumkommen, damit man das sinnvoll abbilden kann. Alle anderen Varianten mit alias usw. Wird bei round robin zwangsweise bei Ausfall einer Leitung zu Ausfällen einiger Zugriffe führen.
Danke für das Feedback.
Was wäre denn hier eine zu empfehlende Lösung beim Kunden?
Es ist ein kleinerer Mittelstandskunde mit ca. 35 Postfächer OnPremise.
Es müsste dann ja quasi in der Cloud der Loadbalancer vorgeschaltet sein, der dann von sich aus auf die lokalen IPs beim Kunden verteilt.
Wobei natürlich so ein Loadbalancer wieder den Abwurf bei Greylisting erhöht.
Danke und liebe Grüße.
Es ist ein kleinerer Mittelstandskunde mit ca. 35 Postfächer OnPremise.
Wäre ja die Frage, ob man unbedingt in-prem bleiben will oder muss.
und zum Thema loadbalancing, ich sag ja, es wird erstmal komplexer und ob sich der Aufwand lohnt, hängt dann eben von den Anforderungen ab.
keine Ahnung, was jetzt das greylisting damit zu tun hat, denn das kann man regeln und beim greylisting zählt ja Sende-ip, Absenderadresse und empfängeradresse. Die Ziel ip ist aber egal.
variante 1: alle drei ips mit eigenen relay Servern betreiben und alle haben die selbe greylisting db.
gibt bestimmt auch andere Lösungen.
bye
norbert
Hallo,
eine einfache Idee:
MX auf mail.kunde.de (oder 3 MX-Records auf die 3 Leitungen)
CNAME autodiscover.kunde.de auf mail.kunde.de
Den A-Record mail.kunde.de als dyndns abbilden und in der Firewall, die alle 3 Internetzugänge mit festen IPs zur Verfügung hat, den dyndns-client so auf die Gateway-Gruppe konfigurieren, dass immer die IP der aktiven Leitung hinter mail.kunde.de gesetzt wird
Das erlaubt dann allerdings kein Loadbalancing, sondern nur Umschaltung bei Ausfall. Läuft bei einem Kunden so mit primär FTTH + DSL als Backup.
Alternativ:
3x A-Record mail.kunde.de auf die jeweils festen IPs der 3 Leitungen
Dann greift simples DNS-Round-Robin. Hatte ich bei dem besagten Kunden vorher im Einsatz, war aber durch die sehr langsame ADSL-Leitung blöd - die sollte dort wirklich nur genutzt werden, wenn nichts anderes da ist.
Gruß
Jens
PS: ausgehend könnte man einen Smarthost im Rechenzentrum / Providerdienst dazwischenschalten, falls man Probleme befürchtet.