Я понимаю , что вы не должны указывать запись MX на IP - адрес непосредственно, но должен вместо этого направить его на A
запись, которая, в свою очередь, указывает на 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 - это двоичный протокол со строгим отображением между типом записи и типом данных, которые содержит такая запись.
Например: записи держит адрес IPv4 (4 байта данных, фиксированной длины). Запись занимает IPv6 - адреса (16 байтов данных, фиксированной длины). A
AAAA
MX
Запись, с другой стороны, имеет имя (последовательность меток на формате <int number of bytes> <label> <int number of bytes> <label> <int 0>
, переменная длиной).
Это не возможно для MX
записи , чтобы иметь IP - адрес в качестве своих данных.
NXDOMAIN
).
MX
записи или записи, которые действительно существуют в мире, могут или должны использоваться.
Я выброшу это как предположение. Конечно, я дома с гриппом, так что, может быть, я сумасшедший.
RFC 974 заявляет:
Первым шагом для почтовой программы в LOCAL является выдача запроса для MX RR для REMOTE. Настоятельно рекомендуется делать этот шаг каждый раз, когда почтовый клиент пытается отправить сообщение. Надежда состоит в том, что изменения в базе данных домена будут быстро использоваться почтовыми программами, и, таким образом, администраторы домена смогут перенаправлять транзитные сообщения для дефектных хостов, просто изменяя свои базы данных домена.
Требуя имя вместо IP, оно настоятельно поощряет эту практику. Имена могут остаться прежними, и в случае балансировки нагрузки или аварийного восстановления вам не придется беспокоиться об изменении самой записи MX и ожидании распространения DNS.
Некоторые почтовые серверы (например, exim) специально не разрешают отправлять в MX записи, которые указывают на чистый IP-адрес, поэтому вам необходимо использовать для этого полное доменное имя, чтобы быть совместимым. Это связано с тем, что большинство серверов ожидают, что запись MX будет содержать имя хоста, а не IP (для этого предназначены записи A).
Редактировать: для уточнения, в DNS каждая запись имеет строгие требования к типу данных, которые может содержать каждая запись. В случае записей MX это только имя хоста .
MX
запись не может иметь IP-адрес в качестве значения.
В RFC 1025 записи MX указывают только на RR (запись ресурса) записи A или CNAME.
Таким образом, почтовый сервер, отправляющий почту, запрашивает RR записи MX, запись mx перечисляет записи серверов A, почтовый сервер выполняет прямой просмотр, чтобы получить запись A, а затем пересылает почту через smtp на хост службы, указанный как почтовый сервер, «желающий» получать почту для этого домена.
Многие из действующих правил, касающихся почты, эволюционировали, чтобы поддерживать доверие между доменами к тому, что сообщения, отправляемые туда и обратно, действительно действительны. Все это должно в конечном итоге уменьшить СПАМ.
Все эти важнейшие компоненты для основы, на которой строится почтовый сервер, имеют, по крайней мере, небольшой компонент, созданный для создания надежных коммуникаций и сокращения ненадежных коммуникаций.
Целью MX
записей является то, что приложение (передача почты) может узнать об используемом хосте. На уровне приложения имена хостов являются правильными (не IP-адреса).
Кроме того, добавление концепции DNS-записи в 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
записях)?