Запись MX в обратной зоне
Я прохожу курс DNS в Linux Academy. В одной из лабораторий определяют обратную зону. В этой зоне добавляют записи MX. Имеет ли смысл определять MX-запись в обратной зоне?
Подробности:
Для этого они делают
vim /etc/named.conf
zone "1.0.10.in-addr.arpa" {
type master;
file "/var/named/1.0.10.db";
};
А содержимое /var/ named/1.0.10.db :
TTL 86400
@ IN SOA nameserver.myserver.com. root.myserver.com. (
10030 ; Serial
3600 ; Refresh
1800 ; Retry
604800 ; Expiry
86400 ; Minimum TTL
)
; Name Server
@ IN NS nameserver.myserver.com.
; PTR Record Definitions
240 IN PTR nameserver.myserver.com.
241 IN PTR mailprod.myserver.com.
242 IN PTR mailbackup.myserver.com.
; which is last octet of my IP
; Mail Exchange Records
@ IN MX 10 mailprod.myserver.com.
@ IN MX 20 mailbackup.myserver.com.
Точно так же я пытаюсь добавить запись A в обратном порядке, но это не актуально, потому что поиск можно было бы выполнить, выполнив:
nslookup <dns-name>.1.0.10.in-addr.arpa localhost
Выполнение
ns lookup <dns-name>.mylabserver.com localhost
не будет работать (или, если это так, это не авторитетный ответ, рекурсия DNS). Я прав?
Я понимаю из https://en.wikipedia.org/wiki/MX_record , что для определения записи MX требуется запись A. Как следствие, мы можем выполнить обратный поиск MX с помощью PTR?
Таким образом, мне интересно, имеет ли смысл добавление записей MX в обратную зону, как тогда мы будем получать этот MX?
Что я пропустил?
Это будет иметь смысл только в том случае, если вы хотите получать почту, например, на (скрытую) (что кажется более чем необычным).
dig 1.0.10.in-addr.arpa MX должен работать для получения записи MX (с учетом зоны в вопросе).
Я предполагаю, что это может быть случай, когда они используют один и тот же шаблон для каждой зоны, или что-то в этом роде. Это, конечно, нетипично в обратной зоне.
Я считаю, что вы, вероятно, пропустили распространенный трюк с обработкой спама, который довольно широко применяется.
Когда устанавливается соединение с SMTP-сервером, некоторые серверы будут выполнять обратный поиск на IP-адрес, который к нему подключен, а затем прямой поиск по этому адресу и проверка совпадения прямого и обратного DNS.
Я сомневаюсь, насколько эффективен этот метод, но идея состоит в том, что если имя домена действительно не имеют обратного DNS или обратного и прямого DNS не совпадают, отправляющий IP-адрес, вероятно, не является легитимным почтовым сервером, и почта должна считаться спамом. Этот метод описан в RFC2505, раздел 1.4 (который относится к февралю 1999 г.). Данная причина:
Когда мы предлагаем использовать FQDN, а не IP-адреса, это потому, что Полные доменные имена интуитивно проще использовать. Однако все такое использование сильно зависит от информации DNS и .IN-ADDR.ARPA (PTR). С тех пор довольно легко подделать это либо с помощью ложной информации из кеша введены в DNS-серверы или спамеры, использующие собственный DNS-сервер с ложным информация в них, имена хостов и доменов должны использоваться с осторожностью, например проверено, так что адрес перевода-> имя соответствует имя-> адрес. "