Sven Rautenberg: Domains ohne Webspace/ Nameserver-Zugriff - wie und wo?

Beitrag lesen

Moin!

Wie erwähnt: EMail ist eine komplett andere Welt, die du auch komplett eigenständig anmieten mußt - sofern das nicht beim Webspace dabei ist.

das war mir schon klar - nur eben nicht, wie genau dann die verbindung von "DNS-eintrag" zu "email-server bei provider B" funktioniert - welcher der DNS-einträge ist dafür verantwortlich?

Die MX-Einträge bezeichnen den oder die Mailserver. Wobei diese wiederum mit A-Einträgen zusammenhängen.

Kurzer Exkurs ins DNS:

Es gibt A-Einträge, welche einen Namen mit einer IP verbinden.

Dann gibts noch CNAME-Einträge, welche einen Namen mit einem anderen Namen verbinden - das ist sozusagen ein DNS-Redirect (bitte nicht verwechseln mit einem HTTP-Redirect!). Es bedeutet: "Ich selbst hab keine direkte IP, nimm die IP von $name dafür". Der Nameserver muß also eine weitere Abfrage starten. Mit Pech kriegt er dann wieder nur einen CNAME, muß also nochmal fragen, etc... Solange, bis er endlich einen A-Eintrag erhält. Wenn man mit CNAME Mist baut, also beispielsweise Ringe baut (Name A -> Name B -> Name C -> Name A), hat man ein Problem. Lange Kettenbildung ist potentiell böse (kostet Zeit). Es ist eine gute Idee, auf CNAME eher zu verzichten - jedenfalls dann, wenn man einen CNAME auf einen Namen der eigenen Domain setzen würde. Das kann man auch direkt per A-Eintrag mit IP machen.

Die MX-Einträge gelten für den Domain-Anteil einer Mailadresse und verweisen auf einen Namen. Für diesen Namen muß ein CNAME oder A existieren.

Beispiel:
example.com ist die Domain
A: server.example.com = 127.0.0.1
A: smtp.example.com = 127.0.0.2
A: pop.example.com = 127.0.0.2
CNAME: www.example.com = server.example.com (ist zwar typisch, aber idiotisch)
MX: example.com = smtp.example.com, Prio 10

Sinn dahinter:
Logischerweise braucht der Webserver einen Namen. Gerne wird dafür ein CNAME benutzt, dann kann man, wenn das Webangebot auf einen anderen Server wechseln soll, einfach den CNAME ändern, und toll. Es ist in diesem Fall aber schwachsinnig, weil man genausogut ein A für www.example.com benutzen könnte, und dann eben die IP ändern müßte.

Ansonsten: Es macht vielleicht Sinn, smtp und pop auf eigene Namen zu legen, für den Fall, dass diese Dienste mal auf unterschiedliche Server umziehen - dann muß man die Mailprogramme nicht umkonfigurieren. Erst durch den MX-Record aber wissen alle anderen Mailserver, wem sie Mails "@example.com" schicken sollen. Die angegebene Priorität ist wichtig, wenn mehrere Mailserver als MX angegeben sind. Wenn der mit der kleinsten Priorität nicht erreichbar ist, wird der nächstgrößere genommen. Die Zahlen sind absolut willkürlich wählbar, üblich sind die Werte "10, 20, 30" oder "100, 200, 300", aber auch "23, 42" ist denkbar.

Hinweis: Es hat wenig Sinn, einen Secondary MX einzurichten, wenn man über den nicht die volle Kontrolle hinsichtlich Prüfung auf existierende Usernamen etc hat. Denn Spammer senden ihre Mails viel lieber an solche sekundären Mailserver, weil dort die Prüfungen eben viel weniger streng sind. Sobald der primäre Mailserver die Mail vom sekundären Mailserver ablehnt, muß der sekundäre eine Bounce-Mail senden - und die nervt dann den unschuldigen Inhaber der Absenderadresse.

Es lohnt also, obwohl es sich toll anhört, nicht, einen sekundären Mailserver zu haben. Wenn der primäre Mailserver unerreichbar ist, speichern alle Mailsendeserver die Mails in einer Warteschlange. Mit sekundärem MX würde dieser in der Zwischenzeit die Mails alle kriegen und seinerseits in der Warteschlange speichern. In so einer Warteschlange wird, je nach Konfig, fünf bis sieben Tage gewartet, ehe die Mail als unzustellbar zurückgeht. Aber wer sieben Tage keinen Mailserver online hat, der hat sowieso ein Problem, da ist es dann egal, ob die ursprünglichen Mailserver die Mail nicht senden können, oder der sekundäre MX.

nachdem mir der dortige support mitgeteilt hat, dass man - trotz laut phpinfo installiertem modul mod_rewrite - die rewrite engine nicht nutzen könne, "weil die schon von confixx verwendet wird", kann ich mir aber nicht mehr vorstellen, dass die so "great" sind ...

Naja, so ganz stimmt das ja nicht. mod_rewrite kann ja mehr als nur eine Regel verwalten. Bleibt nur die Frage, in wieweit man noch Regeln hinzufügen kann, aber das sollte eigentlich im Grundsatz kein Problem sein.

Also ist entweder das Angebot tatsächlich nicht so "great", oder der Support, weil er keine Ahnung hat.

- Sven Rautenberg