MF (Mail Forwarder) Legacy DNS Checker
Запись MF (Mail Forwarder) — это вымерший тип DNS-записи, который работал в тандеме с записью MD (Mail Destination) на зарождающихся этапах интернет-маршрутизации электронной почты. Если запись MD строго указывала на конечный пункт назначения почтового ящика, то запись MF была разработана для решения масштабных проблем надежности магистрали Интернета 1980-х годов. Она предназначалась для определения промежуточного хоста — сетевого реле (relay) — который принимал бы входящую почту от имени домена, удерживал ее и активно пересылал ближе к конечному пункту назначения, когда становился доступен маршрут.
Сетевая архитектура Store-and-Forward
В ранних топологиях сетей непрерывное подключение TCP/IP в режиме 24/7 было невероятной редкостью. Многие академические учреждения и корпоративные мейнфреймы подключались к более широкой сети через коммутируемые (dial-up) каналы связи или прерывистые мосты ARPANET. Запись MF была абсолютно критичной для этих сред «store-and-forward» (сохранить и переслать). Если было известно, что первичный целевой сервер домена находится в автономном режиме по 12 часов в день, администратор мог настроить запись MF, указывающую на высокодоступный, всегда активный сервер в партнерском учреждении. Отправляющий сервер запрашивал DNS, понимал, что MD недоступен, и направлял Payload на хост MF. Сервер пересылки буферизировал (spool) электронные письма на локальный диск и автоматически передавал их пакетом (bulk), когда конечный целевой сервер восстанавливал сетевое соединение.
Сложность разделенных зон (Split Zones)
Хотя концептуально идея была разумной, поддержка раздельных, отдельных DNS-записей для конечных пунктов назначения (MD) и промежуточных реле (MF) оказалась чрезмерно сложной и крайне подверженной ошибкам для сетевых администраторов. Управление зонами DNS требовало тщательного ручного редактирования плоских текстовых файлов, а поддержание синхронизации сопоставлений (mappings) пересыльщиков с сопоставлениями адресатов приводило к частым циклам маршрутизации (routing loops) и потере Payloads. Кроме того, отсутствие системы ранжирования приоритетов означало, что администраторы не могли легко настроить несколько уровней резервных пересыльщиков.
Унификация в MX-записи
Жесткая архитектура MF была полностью отброшена после публикации RFC 973, который ввел гораздо более динамичную запись MX (Mail Exchanger). Протокол MX полностью поглотил функциональность записи MF. Просто назначив более высокий номер приоритета (что эквивалентно более низкому предпочтению подключения) определенному хосту, современные администраторы могут мгновенно превратить любую стандартную запись MX в де-факто почтовый пересыльщик или реле промежуточного хранения (spooling relay). Первичный сервер получает приоритет 10, а резервный spooling сервер получает приоритет 50. Этот унифицированный подход навсегда сделал выделенную запись MF устаревшей, и современное программное обеспечение для парсинга DNS полностью отбрасывает запросы MF.