Check-Host.cc

MF (Mail Forwarder) Legacy DNS Checker

Der MF-Record (Mail Forwarder) ist ein ausgestorbener DNS-Record-Typ, der in den Anfangsphasen des Internet-E-Mail-Routings im Tandem mit dem MD-Record (Mail Destination) arbeitete. Während der MD-Record strikt auf das finale Postfachziel verwies, wurde der MF-Record entwickelt, um die massiven Zuverlässigkeitsprobleme des Internet-Backbones der 1980er Jahre zu lösen. Er wurde entworfen, um einen Zwischen-Host – ein Network-Relay – zu definieren, der eingehende E-Mails im Namen einer Domain annahm, hielt und sie aktiv näher an das finale Ziel weiterleitete, sobald eine Route verfügbar wurde.

Store-and-Forward-Netzwerkarchitektur

In frühen Netzwerktopologien war eine kontinuierliche 24/7-TCP/IP-Konnektivität unglaublich selten. Viele akademische Einrichtungen und Unternehmens-Mainframes waren über Einwahlverbindungen oder zeitweise ARPANET-Brücken mit dem breiteren Netzwerk verbunden. Der MF-Record war für diese "Store-and-Forward"-Umgebungen absolut entscheidend. Wenn bekannt war, dass der primäre Zielserver einer Domain 12 Stunden am Tag offline war, konnte ein Administrator einen MF-Record konfigurieren, der auf einen hochverfügbaren, stets online befindlichen Server einer Partnerinstitution zeigte. Der sendende Server fragte das DNS ab, stellte fest, dass die MD unerreichbar war, und routete den Payload zum MF-Host. Der Forwarding-Server spulte die E-Mails auf die lokale Festplatte und übertrug sie automatisch als Bulk (gesammelt), sobald der finale Zielserver seine Netzwerkverbindung wiederhergestellt hatte.

Die Komplexität getrennter Zonen

Obwohl konzeptionell solide, erwies sich die Aufrechterhaltung separater, unterschiedlicher DNS-Records für Endziele (MD) und Zwischen-Relays (MF) als zu komplex und extrem fehleranfällig für Netzwerkadministratoren. Die Verwaltung von DNS-Zonen erforderte die sorgfältige manuelle Bearbeitung von reinen Textdateien, und die Forwarder-Mappings mit den Ziel-Mappings synchron zu halten, führte häufig zu Routing-Schleifen und verworfenen Payloads. Da es zudem an einem Prioritäten-Ranking-System mangelte, konnten Administratoren nicht ohne Weiteres mehrstufige Backup-Forwarder konfigurieren.

Die Vereinigung unter MX-Records

Die starre MF-Architektur wurde nach der Veröffentlichung von RFC 973, der den wesentlich dynamischeren MX-Record (Mail Exchanger) einführte, komplett aufgegeben. Das MX-Protokoll absorbierte die Funktionalität des MF-Records vollständig. Indem man einem bestimmten Host einfach eine höhere Prioritätsnummer (was einer geringeren Verbindungspräferenz entspricht) zuweist, können moderne Administratoren jeden Standard-MX-Record sofort in einen De-facto-Mail-Forwarder oder ein Spooling-Relay verwandeln. Der primäre Server bekommt Priorität 10, der Backup-Spooling-Server bekommt Priorität 50. Dieser einheitliche Ansatz machte den dedizierten MF-Record dauerhaft obsolet, und moderne DNS-Parsing-Software verwirft MF-Abfragen komplett.