Почему записи MX не могут указывать на IP-адрес?

Я понимаю, что вам не следует указывать запись MX непосредственно на IP-адрес, а вместо этого указывать на A запись, которая, в свою очередь, указывает на IP-адрес вашего почтового сервера.

Но в принципе зачем это нужно?

6 ответов

Решение

Основная идея записи 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 запись, с другой стороны, содержит имя (последовательность меток в формате <int number of bytes> <label> <int number of bytes> <label> <int 0>, переменной длины).

Это невозможно для MX запись, чтобы иметь IP-адрес в качестве своих данных.

Я выброшу это как предположение. Конечно, я дома с гриппом, так что, может быть, я сумасшедший.

RFC 974 заявляет:

Первым шагом для почтовой программы в LOCAL является выдача запроса для MX RR для REMOTE. Настоятельно рекомендуется делать этот шаг каждый раз, когда почтовый клиент пытается отправить сообщение. Надежда состоит в том, что изменения в базе данных домена будут быстро использоваться почтовыми программами, и, таким образом, администраторы домена смогут перенаправлять транзитные сообщения для дефектных хостов, просто изменяя свои базы данных домена.

Требуя имя вместо IP, оно настоятельно поощряет эту практику. Имена могут остаться прежними, и в случае балансировки нагрузки или аварийного восстановления вам не придется беспокоиться об изменении самой записи MX и ожидании распространения DNS.

Некоторые почтовые серверы (например, exim) специально не разрешают отправлять в MX записи, которые указывают на чистый IP-адрес, поэтому вам необходимо использовать для этого полное доменное имя, чтобы быть совместимым. Это связано с тем, что большинство серверов ожидают, что запись MX будет содержать имя хоста, а не IP (для этого предназначены записи A).

Изменить: для уточнения, в DNS каждая запись имеет строгие требования к типу данных, которые может содержать каждая запись. В случае записей MX это только имя хоста.

В RFC 1025 записи MX указывают только на RR (запись ресурса) записи A или CNAME.

Таким образом, почтовый сервер, отправляющий почту, запрашивает RR записи MX, запись mx перечисляет записи серверов A, почтовый сервер выполняет прямой просмотр, чтобы получить запись A, а затем пересылает почту через smtp на хост службы, указанный как почтовый сервер, "желающий" получать почту для этого домена.

Ваш вопрос - почему почта не может быть отправлена ​​на IP-адрес

Ответ - из-за доверия

Многие из действующих правил, касающихся почты, эволюционировали, чтобы поддерживать доверие между доменами к тому, что сообщения, отправляемые туда и обратно, действительно действительны. Все это должно в конечном итоге уменьшить СПАМ.

  • Обратный IP-поиск
  • Предварительный поиск имени по этому вопросу

Все эти важнейшие компоненты для основы, на которой строится почтовый сервер, имеют, по крайней мере, небольшой компонент, созданный для создания надежных коммуникаций и сокращения ненадежных коммуникаций.

Ссылка - RFC 1035 и 974

https://www.ietf.org/rfc/rfc1035.txt35

https://www.ietf.org/rfc/rfc974.txt

Цель MXЗаписи в том, что приложение (передача почты) может узнать об используемом хосте. На уровне приложения имена хостов являются правильными (не IP-адреса).

Кроме того, добавление концепции DNS-записи в DNS вводит множество сложностей и, следовательно, является точкой входа для проблем, неудач реализации, проблем безопасности. Например, 1.2.3.4.example.com. является допустимым именем хоста (да, это так, даже в свете RFC1034, 3.5). Указание этого хоста как MX в файле конфигурации bind для 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 записи)?

Другие вопросы по тегам