Ptr запись для почтового сервера


Категория:Виртуальный хостинг -> Домены
Категория:Виртуальный хостинг -> DNS

Содержание

  • PTR
  • in-addr.arpa
  • Использование
  • Как посмотреть:
    • nslookup
    • dig

PTR

PTR-запись (от англ. pointer – указатель) связывает IP хоста с его каноническим именем. Запрос в домене in-addr.arpa на IP хоста в обратной форме вернёт имя данного хоста. Например, (на момент написания), для IP адреса 192.0.34.164: запрос записи PTR 164.34.0.192.in-addr.arpa вернет его каноническое имя referrals.icann.org.

in-addr.arpa

in-addr.arpa — специальная доменная зона, предназначенная для определения имени хоста по его IPv4-адресу, используя PTR-запись. Адрес хоста AAA.BBB.CCC.DDD транслируется в обратной нотации и превращается в DDD.CCC.BBB.AAA.in-addr.arpa. Благодаря иерархической модели управления именами появляется возможность делегировать управление зоной владельцу диапазона IP-адресов. Для этого в записях авторитативного DNS-сервера указывают, что за зону CCC.BBB.AAA.in-addr.arpa (то есть за сеть AAA.BBB.CCC/24) отвечает отдельный сервер.

Использование


В целях уменьшения объёма нежелательной почтовой корреспонденции (спама) многие серверы-получатели электронной почты могут проверять наличие PTR записи для хоста, с которого происходит отправка. В этом случае PTR запись для IP адреса должна соответствовать имени отправляющего почтового сервера, которым он представляется в процессе SMTP сессии.

Как посмотреть:

nslookup

Что бы посмотреть PTR запись в ОС Windows необходимо открыть командную строку (Пуск->Выполнить->cmd) и набрать в ней
nslookup -type=PTR ip-адрес
Например:

 $ nslookup -type=PTR 80.93.62.122 Server: 192.168.192.168 Address: 192.168.192.168#53 Non-authoritative answer: 122.62.93.80.in-addr.arpa name = mx2.z8.ru. 

dig

В unix-подобных системах необходимо открыть командную строку (терминал) и выполнить команду
dig -x ip-адрес

Например:

 $ dig -x 80.93.62.122 ; <<>> DiG 9.6.1-P1 <<>> -x 80.93.62.122 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20049 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;122.62.93.80.in-addr.arpa. IN PTR ;; ANSWER SECTION: 122.62.93.80.in-addr.arpa. 3489 IN PTR mx2.z8.ru. ;; Query time: 0 msec ;; SERVER: 192.168.192.168#53(192.168.192.168) ;; WHEN: Fri Jan 22 18:54:31 2010 ;; MSG SIZE rcvd: 66 


peterhost.ru

Для корректной работы почтового сервера важно иметь правильно настроенную DNS зону, в которой должны присутствовать A, MX и PTR-записи. Если с первыми двумя всё более-менее понятно, то настройка PTR-записи (обратной зоны, когда необходимо проверить имя сервера зная его IP-адрес) не редко вызывает сложности в понимании, где она должна быть прописана и кто за неё отвечает. Без PTR-записи часть почтовых серверов откажется принимать почту с вашего сервера, отправив вам в ответ примерно такую ругань:

550-There is no reverse (PTR) record found for your host or A record does not 550 correspond PTR record (in reply to RCPT TO command) 550-Reverse DNS lookup failed. If you think this is wrong, get in touch with 550 postmaster. (in reply to RCPT TO command) 550 5.7.1 Relaying denied. IP name forged (PTR and A records mismatch) for ###.###.###.### (in reply to MAIL FROM command)


Так в чем, собственно, заключается сложность? Во-первых — недопонимание как устроена и работает DNS, а во-вторых — банальное нежелание некоторых провайдеров выполнять свои прямые обязанности или некомпетентности «технических специалистов», типа сами дураки. К сожалению встречается и такое. Но давайте, попробуем разобраться.

Рассмотрим распространенную ситуацию. По каким-то причинам вам перестало хватать возможностей почтового сервера, предоставляемого хостингом, там где находится ваш сайт (или просто вы зарегистрировали домен и хотите настроить свой почтовый сервер). У своего провайдера вы получили статический ip-адрес (или даже небольшую подсеть) и на хостинге прописали А и MX записи с указанием на ваш почтовик (тот самый, выделенный вам провайдером ip-адрес).

А вот дальше бывают непонятки кто же должен разместить у себя PTR-запись о вашем почтовом сервере — хостер (тот в чьём ведении находятся DNS-сервера, ответственные за ваш домен) или провайдер (тот, кто выдал вам статический ip-адрес). Для определения имени узла по его ip-адресу предусмотрена особая доменная зона in-addr.arpa.

Так вот, кто выдал вам статический ip-адрес, тот и прописывает на своем DNS-сервере PTR-записи для вашего почтового сервера в зоне in-addr.arpa. Для этого необходимо послать запрос тому, кто выдал вам статический ip-адрес с просьбой зарегистрировать PTR запись для вашего домена.

DNS-запись in-addr.arpa для почтового сервера mail.mydomain.ru с адресом 123.45.67.89 выглядит так:

123.45.67.89.in-addr.arpa. IN PTR mail.mydomain.ru.


Проверить наличие PTR записи на сервере DNS можно с помощью команды nslookup или аналогичного онлайн-сервиса (к примеру http://www.nslookup.su). В командной строке вызываем nslookup и пишем:

> set type=PTR <-- установили тип ресурсной записи > 93.158.134.89 <-- интересующий ip-адрес ----- полученный ответ ----- Не заслуживающий доверия ответ: 89.134.158.93.in-addr.arpa name = mx.yandex.ru 134.158.93.in-addr.arpa nameserver = ns1.yandex.net 134.158.93.in-addr.arpa nameserver = ns2.yandex.net ns1.yandex.net internet address = 213.180.193.1 ns2.yandex.net internet address = 93.158.134.1 >

В поле `name` видим имя одного из почтовых серверов яндекса. При правильной настройке обратной зоны, данное поле должно отобразить имя вашего почтового сервера по соответствующему ip-адресу.

mdex-nn.ru

ptr-spf-antispam-000.jpg

В наших прошлых материалах мы уже рассматривали настройку DNS-зоны для правильной работы почтового сервера, а также роль отдельных DNS-записей. Однако, как показывает практика, не все администраторы правильно понимают механизм работы систем электронной почты с DNS-записями. Поэтому мы решили посвятить этому вопросу отдельную статью, в которой разберем его более глубоко и расскажем о сравнительно новой технологии SPF.


Основная проблема современных почтовых систем — спам. Существует много разных методик борьбы с ним, но основная — анализ отправителя, учитывая что вся необходимая информация в письме имеется.

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

Допустим вы получили на почте крайне подозрительного вида посылку, якобы от любимого дедушки Константина Макаровича, но почему то штемпель отправителя указывает не на почтовое отделение села Макаровки, а на хутор Гадюкино совсем в другом конце страны. Будете вы открывать такую посылку, рискуя обнаружить вместо банки варенья из райских яблочек споры сибирской язвы, или отправите ее назад, от греха подальше?

Точно также и в системах электронной почты. Если вам пришло письмо от дедушки konstantin-makarovich@example.com, но сервер отправитель почему-то mail.spam.com, то это повод не принимать такое письмо, так как оно с большой долей вероятности является спамом.


Каким образом мы осуществили данную проверку? Очень просто, посмотрели на штемпель почтового отделения отправителя и сравнили его с обратным адресом. Например на конверте написано, что отправитель находится в городе Москва, однако на штемпеле отделения-отправителя стоит индекс 683000, который указывает на Петропавловск-Камчатский. Следовательно такое письмо мы принимать не будем, так как оно не прошло проверку отправителя.

Аналогично обстоит дело и с электронным письмом, только вместо индекса отделения-отправителя используется PTR-запись. Так получив письмо от дедушки, мы сделаем PTR-запрос и выясним, что сервер отправитель у нас mail.spam.com, в то время как согласно переданной при соединении информации должен быть mail.example.com. Все понятно, письмо падает в спам.

Однако если в заголовке будет указано, что сервер отправитель у нас mail.spam.com, то такое письмо успешно пройдет проверку по PTR-записи, не смотря на то, что домен сервера отправителя не совпадает с почтовым доменом письма.

Почему так происходит? Потому что проверка по PTR-записи позволяет определить лишь то, что сервер-отправитель действительно тот, за кого себя выдает. Но никоим образом не определяет подлинность самого отправителя. Т.е. обращаясь к примеру обычной почты мы проверяем лишь то, что обратный адрес и индекс отделения отправителя совпадают, если место отправления Москва, а индекс указывает на Петропавловк-Камчатский, то проверку по PTR такое письмо не прошло, а если место отправления и индекс совпадают, то все нормально и теперь уже ваша задача думать, что делает ваш любимый дедушка в Петропавловске-Камчатском.


Непонимание этого момента приводит к тому, что PTR-запись оказывается настроена неправильно и, как результат, большая часть отправляемой почты не доходит до адресата. Особенно важно это понимать при настройке серверов обслуживающих несколько доменов. В этом случае PTR-запись должна указывать на имя почтового хоста (которое он передает в рамках SMTP-сессии), даже если он расположен в другом домене.

Разберем простой пример.

ptr-spf-antispam-001.jpgСервер mail.example.com отправляет письмо для обслуживаемого им домена eхample.org. Сервер-получатель делает запрос PTR-записи и убеждается, что по адресу 123.123.123.123 действительно находится mail.example.com, следовательно такое письмо будет принято, хотя домен отправителя письма и домен сервера-отправителя не совпадают.

А теперь иная ситуация.

ptr-spf-antispam-002.jpgАдминистратор неправильно настроил DNS-зону, указав неправильный хост в PTR-записи. Cервер-получатель, проверив PTR-запись отклонит наше письмо, так как сервер отправитель не совпадает с результатом обратного DNS-запроса.


Отсутствие PTR-записи практически всегда ведет к отклонению письма, потому как существует негласное соглашение о том, что добросовестный отправитель имеет правильно настроенную обратную зону.

Вернемся к нашему дедушке. Допустим он сообщил вам, что летом собирается выезжать из села Макаровки в соседнее село Ивановка, к некой Марфе Васильевне и намерен оттуда посылать вам корреспонденцию. В таком случае вы без опаски будете принимать письма от дедушки как из Макаровки, так и из Ивановки, но откажетесь от якобы дедушкина письма из Петропавловска-Камчатского.

Подобная технология в системах электронной почты реализуется с помощью технологии SPF. Если коротко, то данная технология позволяет создать специальную DNS-запись, которая будет указывать, кто именно имеет право отправлять почту от имени вашего домена. В самом простом варианте запись будет иметь вид:

example.com. IN TXT "v=spf1 +a +mx -all"

Что она означает? То, что для домена example.сom почту могут отправлять узлы указанные в А-записи (+а) и MX-записях (+mx), всю остальную почту следует отклонять (-all).


Однако не все так радужно. Во первых, поддержка SPF все еще не является стандартом де-факто и отсутвие SPF-записи у домена отправителя не повод отклонять письмо. Вторая проблема — сервера пересылки или случаи когда почту отправляют сервера не указанные в А или MX записях, а то и вообще находящиеся в других доменах. Это может быть обусловлено как архитектурой IT-системы предприятия, так и использованием для отправки чужих серверов, когда вы привязываете свой домен к провайдерскому или публичному сервису. В последнем случае нужно быть особо осторожным и крайне желательно проконсультироваться с поддержкой сервиса.

Рассмотрим еще одну ситуацию.

ptr-spf-antispam-003.jpgВаша компания, кроме своего основного почтового сервера mail.example.com, использует услуги сторонних сервисов, которые могут отправлять почту клиентам компании от ее имени. Это может быть сервис экспресс-почты, который от вашего имени будет уведомлять клиентов о статусе доставки и т.п.

В нашем примере такая почта будет отправляться от имени zakaz@example.com с сервера mail.web-service.com, так как данный сервер не указан в MX-записях домена example.com, то, согласно указанному нами в SPF-записи правилу, такое письмо будет получателем отклонено.

Причем поведение сервера-получателя будет однозначным, так как мы сами вполне однозначно указали, что почту от иных отправителей принимать не следует. Поэтому если вы не уверены, что вся почта будет идти исключительно с ваших серверов, то следует указать более мягкое правило:

example.org. IN TXT "v=spf1 +a +mx ~all"  

В отличие от -all (fail), ~all (soft fail) обозначает, что отправители, кроме указанных явно, не имеют права отправлять почту, но не содержит требования отклонять такие письма. Чаще всего такая почта принимается, помечаясь как нежелательная.

Можно также использовать нейтральный префикс:

example.org. IN TXT "v=spf1 +a +mx ?all"

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

Как быть в нашем случае? Самым правильным решением будет добавить в SPF-запись еще одно правило:

example.org. IN TXT "v=spf1 +a +mx +mx:web-service.com -all"

или

example.org. IN TXT "v=spf1 +a +mx +a:mail.web-service.com -all"

в первом случае мы разрешим прием почты также от всех серверов, перечисленных в MX-записях домена web-service.com, во втором случае только для сервера mail.web-service.com.

В завершение рассмотрим случай, когда почта для вашего домена обслуживается сервером находящимся в другом домене. Например mail.example.com отправляет также почту для домена example.org. В этой ситуации будет правильно использовать для домена example.org те же самые правила, что и для example.com. Для этого используйте специальный вид записи:

example.org. IN TXT "v=spf1 redirect=example.com"

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

interface31.ru

Как настроить почтовый сервер, этапы настройки и PTR записи.

Для корректной отправки почты с вашего сервера на внешний IP адрес должна быть прописана PTR запись (прописывается в reverse зоне провайдера, владеющего этим IP — грубо говоря звоним провайдеру и говорим чтобы он прописал требующуюся PTR запись).

(RFC1912 п. 2.1) PTR’ы не имеющие соответствующих им пар (A-record) в зоне прямого просмотра НЕ  ДЕЙСТВИТЕЛЬНЫ.

PTR

PTR-запись (от англ. pointer – указатель) связывает IP хоста с его каноническим именем. Запрос в домене in-addr.arpa на IP хоста в обратной форме вернёт имя данного хоста. Например, (на момент написания), для IP адреса 192.0.34.164: запрос записи PTR 164.34.0.192.in-addr.arpa вернет его каноническое имя referrals.icann.org.

in-addr.arpa

in-addr.arpa — специальная доменная зона, предназначенная для определения имени хоста по его IPv4-адресу, используя PTR-запись. Адрес хоста AAA.BBB.CCC.DDD транслируется в обратной нотации и превращается в DDD.CCC.BBB.AAA.in-addr.arpa. Благодаря иерархической модели управления именами появляется возможность делегировать управление зоной владельцу диапазона IP-адресов. Для этого в записях авторитативного DNS-сервера указывают, что за зону CCC.BBB.AAA.in-addr.arpa (то есть за сеть AAA.BBB.CCC/24) отвечает отдельный сервер.

Использование

В целях уменьшения объёма нежелательной почтовой корреспонденции (спама) многие серверы-получатели электронной почты могут проверять наличие PTR записи для хоста, с которого происходит отправка. В этом случае PTR запись для IP адреса должна соответствовать имени отправляющего почтового сервера, которым он представляется в процессе SMTP сессии.

Как посмотреть:

nslookup

Что бы посмотреть PTR запись в ОС Windows необходимо открыть командную строку (Пуск->Выполнить->cmd) и набрать в ней
nsloopup -type=PTR ip-адрес
Например:

dig

В unix-подобных системах необходимо открыть командную строку (терминал) и выполнить команду
dig -x ip-адрес

Например:  

Развернутый ответ про этапы настройки почтового сервера

Вопрос:
Какие атрибуты должен иметь почтовый сервер, чтобы почта отправлялась напрямую (по MX) без проблем на ВСЕ сервера получателей ?

Ответ:

В нынешней обстановке, в услових, когда объем SPAMа порой в десятки-сотни раз превышает объем полезной почты и буйствуют
почтовые вирусы, администраторы почтовых серверов совершенно законно фильтруют входящий почтовый траффик своих серверов
средствами Reverse lookup (обратый просмотр) и общедоступных блокировочных баз.

Чтобы почта БЕЗ ПРОБЛЕМ отправлялась без посредничества других серверов нужно:
——————————-
1. Иметь честный статический IP с постоянным подключением к интернет.

2. Ваш IP НЕ должен быть одним из типов — Dialup, PPP, Modem/Cable modem, xDSL, Dynamic, DHCP. Эти типы IP «not trusted»
и являются источником 90% спама, наврядли вы сможете что-то отправить имея такой IP. Кроме того провайдеры таких IP сами
сознательно вносят их в блокировочные базы и требуют отправки ВСЕЙ исходящей от них почты через свои релаи.

3. На Ваш внешний IP должен быть прописан PTR (прописывается в reverse зоне провайдера, владеющего этим IP). Он должен
указывать на FQDN хоста (см. п.4). Если Ваш IP multi-homed то PTR’ы должны быть прописаны ДЛЯ ВСЕХ имен хостов,
использующих этот IP. (RFC1912 п. 2.1) PTR’ы не имеющие соответствующих им пар (A-record) в зоне прямого просмотра НЕ
ДЕЙСТВИТЕЛЬНЫ.

4. Должен быть прописан hostname для внешнего IP сервера (A-запись в зоне домена, чьим MX является Ваш почтовый сервер).
Его полное имя есть Fully qualified domain name (FQDN) (т.е. хост в официально зарегистрированном домене
имеет FQDN=). (RFC1912)

5. Строка HELO сервера должна содержать FQDN хоста. FQDN разрешается поиском в глобальном DNS во внешний IP этого хоста.
(см. п.4) (RFC2821)

6. ВСЕ имена должны быть доступны в любой точке интернет и однозначно разрешаться поиском в глобальном DNS (от root).
Все имена, которые не разрешаются поиском от root являются локальными алиасами. Использование локальных алиасов и локальных
имен, а также усеченных (не полных) имен в SMTP сессиях — ЗАПРЕЩЕНО. (RFC2821)

7. Имена в зонах прямого и обратного просмотра и IP должны взаимно и однозначно указывать друг на друга. (RFC1912).

см. также:
Что такое RFC?
http://www.faqs.org/rfcs/rfc1912.html
http://www.faqs.org/rfcs/rfc2821.html
Как прописать PTR для моего IP ?
———————————
Например:
Есть общедоступный домен mydomain.ru, хочется иметь почтовый сервер, который будет напрямую принимать и отправлять почту,
назовем хост именем mx1 (FQDN=mx1.mydomain.ru) и будет установлен на внешний IP=1.2.3.4, тогда

В зоне провайдера (зона <3.2.1.in-addr.arpa>, возможны варианты зависит от класса сети…):
Код:

В зоне родительского домена (зона )
Код:

В HELO сервера (см. настройки Primary domain в MDaemon)
Код:

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

IP=1.2.3.4 —> PTR=mx1.mydomain.ru = HELO = mx1.mydomain.ru —> A=1.2.3.4=IP
Кольцо замкнулось — 100% совпадение. Нет НИКАКИХ причин для отказа в приеме почты (если конечно Вы лично не насолили кому-то…)

ОТСУТСТВИЕ ИЛИ НЕСООТВЕТСТВИЕ ХОТЯ БЫ ОДНОГО ЭЛЕМЕНТА ЭТОЙ ЦЕПОЧКИ МОГУТ ПОСЛУЖИТЬ ПРИЧИНОЙ ОТКАЗА В ПРИЕМЕ ПОЧТЫ.
 

sudo.in

Базовые DNS-записи для почтового сервера

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

Рекомендую к прочтению перечень статей ниже:

  • Технология DKIM для почтового сервера
  • SPF-запись для почтового сервера
    • 10 DNS-запросов для одной SPF-записи

Ну а теперь начнем разбираться что нужно сделать перед созданием записей.

 

Покупка доменного имени

Начать необходимо с покупки доменного имени. Это не так сложно, как кажется и не так дорого. Новый домен в .ru-зоне может стоить не больше 100-200 рублей.

Как только домен куплен, можно приступать к созданию записей. У всех регистраторов разные админки, но зная теорию, в специфике добавления записей разобраться проще простого.

Хочу сразу предупредить, что распространение только что созданных записей занимает некоторое время, обычно это от 15 минут и до нескольких часов (или в теории даже суток, но мне такое не встречалось).

A

Первым делом создайте основную A-запись, которая будет указывать на внешний адрес вашего почтового сервера. Допустимы любые варианты, но обычно выбирают что-то похожее на mail.domain.tld или mx1.domain.tld. Если вы используете собственный DNS-сервер bind, то A-запись внутри зоны может выглядеть так:

На эту запись в последствии будет указывать MX.

MX

Эта запись переводится как mail-exchanger и, собственно, она и является основной для почтовых серверов. Таких записей может быть несколько и каждая из них обязательно имеет значение приоритета — чем оно меньше, тем приоритет выше. Для чего это используется? Главным образом для определения очередности обращения к MX-записям, если их несколько.

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

Если углубляться в архитектуру почтовых решений, то очень часто запись MX указывает на mail-relay или сервер антиспама (spamassasin, например, или Exchange Server Edge), а не на конечный почтовый сервер, сохраняющий входящие/исходящие письма. Это вполне разумный подход, когда отдельный сервер выступает в качестве пограничного шлюза, а другой — с критически важными данными для бизнеса — своеобразным бэкэндом. Я скажу больше — это даже best practice.

Сколько MX надо для счастья

Сообразительному читателю может прийти в голову очень интересная мысль: «А что лучше — две записи MX или одна запись MX, но ссылающаяся на две одинаковые A-записи?». Визуально это выглядит вот так:

Базовые DNS-записи для почтового сервера 02

В случае b. получается своеобразный Round Robin. Но, если отбросить нюансы, вариант a. аналогичен! Ведь одинаковый приоритет MX-записей обеспечивает такую же функцию.

Тем не менее, и в этом случае у многих возникают сомнения. Главным образом они обуславливаются мнением, что в случае b., если отправляющий сервер в первой попытке отправки попадет на неработающий сервер, то он отложит отправку и попробует в следующий раз, спустя таймаут. Но это в корне неверно — он попробует отправить на второй сервер из выдачи RR сразу же. Это демонстрирует наглядный эксперимент.

Когда на запросы отвечают оба сервера из варианта b., мы видим следующую запись в smtp-сессии при попытке отправки на них письма (Queued mail for delivery — письмо принято к доставке):

Если же по каким-то причинам один из серверов отключился и отправляющая сторона попала в первую попытку на него, сразу же пойдет вторая попытка отправить почту на второй сервер из выдачи (после Connection timed out в первый раз идет удачная вторая попытка):

А теперь вернемся от теории к практике и посмотрим как же обстоят дела у крупных публичных почтовых сервисов:

Mail и Yandex используют для своих сервисов именно вариант с RR для A-записей, а вот Google — нет:

Поэтому именно вам решать какой вариант выбрать.

PTR

С PTR нет такого пространства для творчества, как в случае с MX и от этого только легче. PTR-запись принадлежит обратной зоне и призвана сопоставить ip-адрес с DNS-именем (то есть, адрес должен разрешаться в имя).

В самом идеальном случае должно происходить «круговое» разрешение записей. Что это такое, легко понять на примере: из MX получаем A-запись, из A-записи получаем ip-адрес, от этого адреса берем PTR-запись, которая в идеале должна разрешиться в A-запись, на которую указывала MX изначально. И так по кругу:

Базовые DNS-записи для почтового сервера 03

Но в реальности это явно избыточный перфекционизм. К тому же, что вы будете делать, если ваш сервер будет обслуживать несколько доменов одновременно (а ведь это очень частая ситуация)?

Ради интереса давайте проверим тех же публичных провайдеров:

Но! ведь этот же сервер обслуживает и другие домены mail.ru, например list.ru, bk.ru:

Ну и, разумеется, их адреса будут иметь PTR абсолютно не связанную с именем, например, bk.ru. Таким образом, по сути жесткое соответствие не обязательно и вы можете использовать PTR с любым вашим доменным именем. Главное, чтобы запись существовала, ведь очень много серверов проверяют наличие PTR и, если её нет, резко повышают спам-рейтинг ваших сообщений.

И, самое главное, PTR-запись создается на стороне владельца ip-адреса. То есть, если адреса вам предоставляет интернет-провайдер, запрашивать создание записи вы должны именно у него (в админке или через менеджера).

TXT

TXT — обычная текстовая запись. Она применяется достаточно широко — от подтверждения владения доменом и до использования самыми разными механизмами фильтрации нежелательных/вредоносных сообщений (DKIM, DMARC).

В контексте изучения базовых записей DNS, TXT нас интересует прежде всего с точки зрения использования SPF (Sender Policy Framework).

Назначение SPF очень простое — определить список серверов, которые имеют право отправлять почту от указанных доменов. Не вникая в особенности самого расширения, вы можете легко сгенерировать подходящую SPF для вашего домена, в этом вам помогут многочисленные онлайн-генераторы 2.

Ваша запись может иметь следующий вид:

Ничего сложного. Не так ли? На стороне сервера ничего делать не нужно, в этом ещё один плюс SPF.

Никогда не игнорируйте возможность создания записи, даже если имеете дело с тестовой инфраструктурой. Например вот что может вам ответить принимающий сервер, если засомневается в вашей «чистоте» как отправителя:

Это кусок лога SMTP-сессии с сервером Mail.ru. Абсолютно неинформативная ошибка и ответ — 451 Try again later — могут легко ввести в ступор, а безрезультатная гуглежка заставит сильно приуныть. Тем не менее, после создания SPF все стало хорошо и статус вновь отправляемых сообщений изменился на Queued mail for delivery.

blog.bissquit.com

Понадобилось как-то настроить обратную DNS зону (Reverse DNS) для почтового сервера, так как некоторые сервера не хотели принимать от него почту.

Допустим наш домен mail.example.com находящийся на IP адресе 192.168.1.100, а 192.168.1.1 — сервер интернет провайдера.

Проверить из Windows можно командами (где 192.168.1.100 например адрес нашего почтового сервера, а 192.168.1.1 DNS на который шлем запрос):

nslookup mail.example.com  nslookup 192.168.1.100  nslookup 192.168.1.100 192.168.1.1

В ответ первой команды будет 192.168.1.100, а в ответ второй ничего (должно mail.example.com), так как в DNS не настроена PTR запись.

Из Linux проверять можно так:

dig -x 192.168.1.100

У регистратора доменных имен в DNS добавим дочерний NS-сервер интернет провайдера ns1.example.com 192.168.1.1.

На сервере провайдера (на тесте использую Bind9 на Ubuntu Server) откроем конфигурационный файл DNS сервера например в редакторе nano (CTRL+X для выхода, y/x и Enter для сохранения или отмены изменений):

sudo nano /etc/bind/named.conf

И добавим следующие строки:

zone "1.168.192.in-addr.arpa" {  type master;  file "/etc/bind/1.168.192.in-addr.arpa";  };

Первая строка указывает какой зоной будем управлять, вторая тип — главный (этот DNS и будет ею управлять), третья — в каком файле будет прописана конфигурация для этой зоны.

Откроем новый файл для настроек зоны:

sudo nano /etc/bind/1.168.192.in-addr.arpa

И добавим в него:

$TTL 3600  @ IN SOA ns1.example.com. admin.example.com. (   2016112301 ; Serial   21600 ; refresh   3600 ; retry   3600000 ; expire   86400 ) ; minimum     IN NS ns1.hosting.com.   IN NS ns2.hosting.com.    $ORIGIN 1.168.192.in-addr.arpa.  100 IN PTR mail.example.com.

admin.example.com — контактный адрес человека отвечающего за зону, символ @ не указывается.
Serial это серийный номер версии файла зоны, должен изменяться в большую сторону при каждом изменении, обычно пишется в виде год месяц число номер изменения, по нему другие DNS определяют что нужно обновить у себя информацию.
Refresh — интервал времени в секундах, через который вторичный сервер будет проверять необходимость обновления информации.
Retry — интервал времени в секундах, через который вторичный сервер будет повторять обращения при неудаче.
Expire — интервал времени в секундах, через который вторичный сервер будет считать имеющуюся у него информацию устаревшей.
Minimum — интервал времени жизни информации на кэширующих серверах.
ns1.hosting.com и ns2.hosting.com это DNS домена.
Цифра 100 в последней строке означает окончание IP адреса 192.168.1, аналогично можно указывать записи для других доменов, например 101 IN PTR … для 192.168.1.101 и т.д.

Перезапустим DNS сервер чтобы применить изменения.
Bind9 можно командой:

sudo /etc/init.d/bind9 restart

Смотрите также:
Настройка Reverse DNS (PTR) в Hetzner

ixnfo.com

Если у вас есть свой почтовый сервер, то необходимо, чтобы ваш провайдер (а точнее тот, кто выдал вам статические ip-адреса) зарегистрировал на своем DNS-сервере PTR записи для вашего почтового сервера (MX-записи). Иначе, подавляющая часть почтовых серверов интернета откажется принимать почту от вашего почтового сервера.
Так же, многие почтовые сервера отвергают письма, если при проверке адреса отправителя в строке им выдается "dynamicip" или "dsl" или подобные слова означающие, что ваш адрес не статический или не совпадает с именем вашего домена.
Если в ответе сервера на ваше отправленное письмо вы видите что-то типа:

это значит, что вам необходимо корректно зарегистрировать PTR запись на DNS-сервере для вашего доменного имени.

Для этого необходимо послать запрос тому, кто выдал вам статические ip-адреса (обычно, это ваш провайдер) с просьбой зарегистрировать PTR запись для вашего домена.

Например, для домена mydomain.ru с адресом 215.54.54.54, необходимо зарегистрировать следующую запись:

Код: Выделить всё
54.54.54.215.in-addr.arpa name=mydomain.ru

А если почтовый сервер сидит на отдельном адресе, например, mail.mydomain.ru имеет адрес 215.54.54.55, то необходимо зарегистрировать еще одну PTR запись:

Код: Выделить всё
55.54.54.215.in-addr.arpa name=mail.mydomain.ru

Проверить наличие PTR записи на сервере DNS можно с помощью интерфейса команды NSLOOKUP:

Код: Выделить всё
nslookup

теперь подключаемся к DNS-серверу провайдера:

Код: Выделить всё
server 215.54.54.1

устанавливаем тип ресурсной записи:

Код: Выделить всё
set type=PTR

делаем запрос на интересующий нас адрес:

Код: Выделить всё
215.54.54.54

в ответ мы должны получить имя своего домена mydomain.ru

Примечание:

PTR запись должна быть создана именно для MX записи. То есть, если адреса домена и почтового обменника не совпадают, то PTR создаем именно для MX записи.

Например, если домен mydomain.ru находится по адресу 22.11.33.44, а почтовый обменник (MX запись) создана для хоста mail.mydomain.ru, расположенного по адресу 11.22.33.44, то и PTR запись нужно создавать для mail.mydomain.ru:

Код: Выделить всё
44.33.22.11.in-addr.arpa  mail.mydomain.ru

Естественно, можно "до кучи" создать обратную запись и для самого домена mydomain.ru:

Код: Выделить всё
44.33.11.22.in-addr.arpa  mydomain.ru

Она так же не помешает.

manaeff.ru

Запись типа NS— Name Server, сервер имён

В записях типа NS указываются имена DNS-серверов, которые будут поддерживать доменную зону. По требованиям регистраторов доменных имён в целях доступности и отказоустойчивости их должно быть не менее двух и они должны быть расположены в различных подсетях класса C. Имя должно заканчиваться точкой иначе DNS-сервер интерпретирует имя как поддомен текущей зоны.

Запись типа MX — Mail eXcanger, сервер обмена электронной почтой

Основная запись в доменной зоне, указывающая на имена почтовых серверов этого домена, без которой невозможны приём и отправка (косвенно) почты. Невозможность отправки почты указана как косвенная потому, что подавляющее большинство почтовых серверов перед приёмом сообщения в целях защиты от спама обязательно проверит наличие в DNS-зоне MX-записей и их соответствие IP-адресу отправителя. В случае отсутствия такой записи и/или её несоответствия удалённым почтовым сервером с вероятностью чуть менее 100% в приёме электронной почты будет отказано. Указание MX-записи отличается от синтаксиса рассмотренной ранее A-записи тем, что MX поддерживает приоритеты. Приоритет MX-записи — целое число от нуля включительно, указывающее несколько возможных почтовых серверов для этого домена, и определяющее порядок их перебора почтовым сервером отправителя в случаях недоступности некоторых из них. Обратите внимание, адресом почтового сервера в MX-записи не может быть IP-адрес, только доменное имя.

В примере выше наибольшим приоритетом (0) в приёме почты обладает хост mx1.tendence.ru Именно к нему в первую очередь будут обращаться для отправки сообщений на ваш корпоративный почтовый сервер все другие почтовые серверЫ. Если по каким-то причинам в соединение с этим почтовым сервером будет отказано, отправитель перейдёт к попытке оправки почты на почтовый сервер с следующим приоритетом — 5, mx2.tendence.ru и так далее. Таким образом, MX-записи дают возможность гибкой настройки балансировки нагрузки (можно указать несколько записей с один и тем же приоритетом) и отказоустойчивости хостинга почты.

Запись типа A — Address, IP-адрес, соответствующий доменному имени

Необходима для преобразования доменного имени непосредственно в IP-адрес. Должна соответствовать внешнему статическому маршрутизируемому IP-адресу, выделенному провайдером.

Запись типа PTR — PoinTeR, указатель в обратной зоне DNS

Исключительно важная запись, значение rDNS-записи в работе хостинга почты невозможно переоценить! Удалённые почтовые серверы проверяют наличие и содержимое этой записи при попытке отправить им почту и их системы антиспама придают очень веское значение результатам проверки. Рекомендуется давать им осмысленное имя, которое соответствует имени, данному почтовому серверу к MX и A-записях. Почтовые серверы Mail.Ru, например, вообще не принимают электронную почту от почтовых серверов с неправильными с их точки зрения PRT/rDNS-записями. Так, почта от хоста 4-3-2-1.dsl-pool.prodiver.ru будет отклонена из-за исчезающей вероятности наличия у серьёзного корпоративного почтового сервера такого имени. Как правило запись в эту зону вносится вашим хостером или провайдером, если вы не обладаете собственной автономной системой (AS).

www.tendence.ru


You May Also Like

About the Author: admind

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.