note to myself: RFCs lesen

Ich hatte heute wieder mal eine Erkenntnis: RFCs lesen hilft, dass alles so funktioniert wie es soll.

Szenario: Ein Kunde teilt mir mit, dass eine bestimmte Person ihm keine Mails senden kann. Die mir bekannte Person habe ich nach einem Fehlerbericht des Mailservers gefragt und war erstaunt zu lesen:

domain name system error:
host mail.kundendomain.tld:
mail exchanger has no ip addresses

WTF? Als wenn ich für den Mailserver keine IP eintragen würde, klar!

Eine Quick-Google-Search brachte die Erklärung:

Da ich gerade mit meinem Server umgezogen bin und bei allen Domains die IP einzeln ändern musste (btw: Danke NicDirect!), hatte ich es gleich so eingerichtet, dass ich beim nächsten Mal, so wenig wie möglich ändern muss. Daher machte ich folgende Eintragungen im DNS:

kundendomain.tld in MX 10 mail.kundendomain.tld
mail.kundendomain.tld in CNAME mail.mydomain.tld

Also steht in dem DNS-Eintrag des MX des Kunden ein CNAME für eine andere Domain. Laut RFC1912 soll man aber keine CNAMEs in den MX eintragen.

Meine schöne Erleichterung war also dahin…. naja, nicht ganz. Ich habe es dann eben wie alle großen Hoster (warning: GRÖßENWAHN) gemacht und nicht den MX-Eintrag der Domain auf die Kundendomain sondern gleich auf mail.mydomain.tld zeigen lassen. Ist zwar nicht so schick, aber RFCs sind da nun einmal eindeutig.

PS: Ach ja, der Mailserver, der das Problem gemeldet hat und die Zustellung daher verweigerte von übrigens von Schlund bzw. 1&1. Wie ich lesen konnte, war ich nicht der Einzige, der auf dieses Problem gestoßen bin.

2 Gedanken zu „note to myself: RFCs lesen“

  1. Hallo Stevie, 
    danke für Dein Posting!
    Es gibt (mindestens) zwei Alternativen, die beide bei NIC-Direct funktionieren – eine RFC konforme und eine nicht-RFC-konforme (aber dennoch funktionierende).

    1. RFC-konform
    Es gibt einen kostenfreien Service, der jede “Rootdomain” (= apex zone) per Redirect auf eine entsprechende www-Domain weiterleitet. Man findet ihn unter http://wwwizer.com – mehr dazu unter http://mrooney.github.com/blog/2012/05/01/dns-root-slash-apex-cnames-in-practice/ .
    Ein DNS-Setup damit würde so aussehen:
    kundendomain.tld. 14400 A IN 174.129.25.170*.kundendomain.tld. 14400 CNAME IN mydomain.tld.2. Nicht RFC-konform (aber funktionierend)Bei NIC-Direct ist es in der Tat möglich, CNAME Records für Rootdomains anzulegen. Uns sie funktionieren nach allen meinen Test einwandfrei.Ein DNS-Setup damit würde so aussehen:kundendomain.tld. 14400 CNAME IN mydomain.tld.
    *.kundendomain.tld. 14400 CNAME IN mydomain.tld.

    WICHTIG:
    Bei NIC-Direct muss man die Punkte am Ende des names weglassen – also vorne jeweils nur “kundendomain.tld” statt “kundendomain.tld.”.In beiden Fällen werden auch MX-Anfragen automatisch auf mydomain.tld weitergeleitet. Du benötigst also nichts weiter, um sämtlichen Traffic auf Deine zentrale Domain weiterzuleiten. Ändert sich die IP von mydomain.tld, so ist lediglich eine Änderung im DNS-Eintrag von mydomain.tld nötig – alle Kundendomains folgen durch ihre CNAMEs.Ähnliches funktioniert auch bei Schlundtech! Hier Version 2. für Schlund:
    – “IP-Adresse” und “Email-Server der Domain” leer lassen.
    –  14400 CNAME IN mydomain.tld.
    – * 14400 CNAME IN mydomain.tld.
    Beim ersten Beispiel ist der name leer!

    Gruß, Jörg.

  2. Das Blog hat diverse Umbrüche gelöscht – insbesondere die vor “2.”, vor “In beiden Fällen…” und vor “Ähnliches…”.

    Wäre nett, wenn Du die restaurieren könntest und dann dieses PS löschst.

Schreib einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *