Почему записи MX не могут указать на IP-адрес?
Я понимаю, что Вы не должны указывать на запись MX на IP-адрес непосредственно, но должны вместо этого указать на него на A запись, которая, по очереди, указывает на IP-адрес Вашего почтового сервера.
Но, в принципе, почему это требуется?
Вся идея записи MX состоит в том, чтобы указать хост или хосты , которые могут принимать почту для домена. Как указано в RFC 1035 , запись MX содержит имя домена. Следовательно, он должен указывать на хост, который сам может быть разрешен в DNS. IP-адрес нельзя было использовать, так как он был бы интерпретирован как неквалифицированное доменное имя, которое не может быть разрешено.
Причины этого в 1980-х годах, когда были изначально написаны спецификации, почти такие же, как и причины для этого. сегодня: хост может быть подключен к нескольким сетям и использовать несколько протоколов.
Еще в 80-е годы не было редкостью иметь почтовые шлюзы, которые подключались как к (относительно новому) Интернету, который использовал TCP / IP, так и к другим устаревшим сети, в которых часто используются другие протоколы. Указание MX таким образом разрешило записи DNS, которые могли определить, как достичь такого хоста в сети, отличной от Интернета, такой как Chaosnet . Однако на практике этого почти не происходило; практически все модернизировали свои сети, чтобы вместо этого стать частью Интернета.
Сегодня ситуация такова, что к хосту можно подключиться по нескольким протоколам (IPv4 и IPv6) и по нескольким IP-адресам в каждом протоколе. В одной записи MX не может быть перечислено более одного адреса, поэтому единственный вариант - указать на хост, где затем можно будет найти все адреса этого хоста. (В целях оптимизации производительности DNS-сервер отправит записи адреса для хоста в дополнительном разделе ответа, если у него есть авторитетные записи для них, что позволяет сэкономить время и обратно.)
Также существует ситуация, которая возникает, когда ваша почта обменники предоставляются третьей стороной (например, Google Apps или Office 365). Вы указываете свои записи MX на их имена хостов, но может случиться так, что провайдеру услуг потребуется изменить IP-адреса почтовых серверов. Поскольку вы указали хост, поставщик услуг может сделать это прозрачно, и вам не нужно вносить какие-либо изменения в свои записи.
DNS как протокол имеет несколько различных типов значений, они не взаимозаменяемы.
Важно отметить, что DNS - это двоичный протокол со строгим сопоставлением между типом записи и типом данных, содержащихся в такой записи.
Например:
Запись A содержит адрес IPv4 (4 байта данных, фиксированная длина).
Запись AAAA содержит адрес IPv6 (16 байтов данных, фиксированная длина).
Запись MX , с другой стороны, содержит имя (последовательность меток в формате , переменная длина).
Невозможно для записи MX иметь IP-адрес в качестве данных.
Я выброшу это как предположение. Конечно, я дома с гриппом, так что, возможно, я в замешательстве.
RFC 974 гласит:
Первым шагом для почтовой программы на LOCAL является запрос на запись MX RR. для УДАЛЕННОГО. Настоятельно рекомендуется делать этот шаг каждый раз почтовая программа пытается отправить сообщение. Надеюсь, что изменения в база данных домена будет быстро использоваться почтовыми программами, и, следовательно, домен администраторы смогут перенаправлять сообщения в пути для дефектные хосты, просто изменив свои доменные базы данных.
Требуя имя вместо IP, он настоятельно поощряет эту практику. Имена могут оставаться прежними,а в случае балансировки нагрузки или аварийного восстановления вам не придется беспокоиться об изменении самой записи MX и ожидании распространения DNS.
Запись MX предназначена для того, чтобы приложение (передача почты) могло узнать о хосте. быть использованным. На уровне приложенияправильнее всего использовать имена хостов (а не IP-адреса).
Кроме того, добавление концепции записи вариантного типа в DNS вносит ряд осложнений и, следовательно, точку входа для проблем, ошибок реализации, проблем безопасности.
Например, 1.2.3.4.example.com. является допустимым именем хоста (да, даже в свете RFC1034, 3.5). Указание этого хоста как MX в файле конфигурации привязки для example.com может выглядеть как
. MX 10 1.2.3.4
и, по-видимому, это в точности то же самое, что и запись MX с IP-адресом.
И даже для передачи информации в дейтаграмме DNS требуются некоторые причудливые надстройки; Самый простой способ - ввести новый тип записи ресурса, скажем, MXA , для устранения неоднозначности. Но опять же, зачем вводить такой новый тип записи, когда
. MXA 10 5.6.7.8
всегда можно заменить на
. MX 10 dummy
dummy A 5.6.7.8
(и будет поддерживаться также DNS-клиентами, не знающими о записях MXA )?
Некоторые почтовые серверы (например, exim) специально не разрешают отправку в записи MX, которые указывают на чистый IP-адрес, поэтому вы должны использовать полное доменное имя, чтобы оно соответствовало требованиям. Это связано с тем, что большинство серверов ожидают, что запись MX будет содержать имя хоста, а не IP (это то, для чего нужны записи A).
Изменить: чтобы уточнить, в DNS каждая запись имеет строгие требования к типу данных, которые каждая запись может содержать . В случае записей MX это имя хоста только .
В RFC 1025 записи MX указывают только на RR (запись ресурса) записи A или CNAME.
Таким образом, почтовый сервер, отправляющий почту, запрашивает RR записи MX , запись mx перечисляет A-записи серверов, почтовый сервер выполняет прямой поиск, чтобы получить A-запись, а затем пересылает почту через smtp на хост службы, указанный как почтовый сервер, «желающий» получать почту для этого домена.
Ваш вопрос - почему почта не может быть отправлена на IP-адрес
Ответ - из-за доверия
Многие действующие правила, касающиеся почты, эволюционировали, чтобы поддерживать доверие между доменами, которые отправляются туда и обратно действительно действительны. Все это сделано для того, чтобы в конечном итоге уменьшить количество спама.
- Обратный поиск IP
- Прямой поиск имени, если на то пошло
Все эти важные компоненты для основы, на которой строится почтовый сервер, имеют по крайней мере какой-то небольшой компонент, основанный на создание надежных коммуникаций и сокращение количества ненадежных.