Меню

Настройка dns для почтового сервера exchange



Как правильно настроить DNS для почтового сервера

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

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

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

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

NS ns1.tendence.ru.
NS ns2.tendence.ru.
NS ns3.tendence.ru.

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

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

MX 0 mx1.tendence.ru.
MX 5 mx2.tendence.ru.
MX 10 mx3.tendence.ru.
MX 100 mx4.tendence.ru.

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

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

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

mail A 192.168.0.1

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

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

1 PTR mx1.tendence.ru.

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

Запись типа TXT/SPF — TeXT, текстовый указатель/Sender Policy Framework, структура политики отправителя

Замечательное средство защиты от подделки адреса отправителя, принятое в качестве стандарта RFC с 2006 года. Является эффективным, быстрым и использующим крайне мало ресурсов как со стороны отправителя, так и получателя средством. Остаётся только сожалеть, что за прошедшие годы не все владельцы доменов внедрили у себя SPF-записи. Если бы это произошло, спама в электронной почте стало бы на порядок меньше. SPF заметно уменьшает вероятность ложного определения сообщения с вашего email-сервера как спам. Заключается в явном указании списка IP-адресов/хостов, которые имеют право на отправку электронной почты от имени домена.

TXT «v=spf1 +mx -all»

Строка такого вида указывает используемую версию SPF — 1 (а другой пока и нет, сделано для совместимости с будущими версиями протокола), разрешает приём почты домена со всех адресов, указанных в MX и запрещает приём почты со всех других хостов. Такой настройки будет достаточно в большинстве случаев для предотвращения подделки адресов корпоративной почты и снижения шансов маркировки ваших сообщений как спама.

Читайте также:  Настройка сервер групп в тс3

Запись типа TXT/DKIM — TeXT, текстовый указатель/Domain Keys Identified Mail, электронная почта, идентифицированная доменными ключами

Криптографическая технология, принятая в качестве стандарта с 2007 года. Как и SPF призвана предотвратить подделку адресов отправителя, уникальным образом идентифицировать его, а также подтвердить, что при доставке сообщение электронной почты не было изменено. Требует наличия программного обеспечения для подписания каждого сообщения доменным ключом. Для проверки используется открытый ключ, указанный в зоне DNS:

selector._domainkey TXT «v=DKIM1; p=MIGfMA1CSqGSIb1DQEBAQUAA4GNADCBiQKBgQCnmGN26HP/0oxTdlKSaivGvO0y38tY6RbBbJXHerIE1aHkCk/PTJhnD3hAIEhLobIqWazInJFZMO1W/jqUP2MxH16lU/jzuZvvUH3l8/kq4egAxYiwcya6ksVe0OzTtkF2XHFzhvGxQ/SJD/26PugcDS2NwVIG9PrWL9POXwIDAQAB»
_domainkey TXT «o=-»

Имя selector означает конкретный ключ (их может быть несколько), используемый для подписания сообщения, параметр v — версия DKIM, p — собственно ключ. Политика o=- указывает, что неподписанные/неправильно подписанные сообщения должны отклоняться. Именно такой режим рекомендуется для применения, ведь повсеместное внедрение этой технологии позволило бы навсегда решить проблему спама. Подключение DKIM к корпоративной почте позволит сообщениям сотрудников не быть ложно опознанными как спам у получателей. Более подробную информацию по подключению DKIM к вашему почтовому серверу ищите в документации к нему.

Источник

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

  • Главная
  • Почтовый сервер для начинающих. Настраиваем DNS зону

Почтовый сервер для начинающих. Настраиваем DNS зону

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

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

Что нам понадобиться? Выделенный IP адрес (допустим 11.22.33.44), который вы должны получить у своего провайдера. Доменное имя (например example.com), его можно зарегистрировать у любого регистратора или их партнера. При регистрации у партнера уточняйте, предоставляет ли он доступ к управлению DNS зоной, иначе придется потратить дополнительное время, нервы и деньги на перенос домена к регистратору.

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

Итак, домен у нас есть. Какие записи содержит его DNS зона? Во первых это SOA запись — описание зоны. Мы не будем подробно разбирать все записи, это выходит за рамки нашей статьи, но иметь общее представление о них необходимо. Также должны быть две NS записи, указывающие на сервера имен (DNS сервера) обслуживающие данный домен, это будут сервера регистратора или хостинг провайдера.

Первой записью, которую необходимо добавить будет A запись или запись имени. Она должна указывать на IP-адрес вашего сервера, если вы решите обслуживать все запросы к домену у себя или на IP адрес хостинг провайдера, если решите разместить свой сайт на хостинге. При размещении сайта у хостера домен обычно делегируется на его DNS сервера (прописываются соответствующие NS записи) и A запись будет сделана автоматически при парковке домена.

Чаще всего встречается этот вариант, но при необходимости вы всегда сможете создать A запись сами. Данная запись имеет вид

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

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

Также можно написать просто:

К такому имени (без точки на конце) example.com будет добавлено автоматически. Цифра 10 определяет приоритет сервера, чем она меньше, тем выше приоритет. Кстати, DNS зона уже может содержать MX запись вида:

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

Теперь создадим A запись для mail.example.com

Теперь вся почта для домена example.com будет направляться хосту mail имеющему адрес 11.22.33.44, т.е. вашему почтовому серверу, в то-же время сайт example.com продолжит работать на сервере провайдера по адресу 22.11.33.44.
Может возникнуть вопрос, а почему нельзя сразу указать в MX записи IP адрес почтового сервера? В принципе можно, некоторые так и делают, но это не соответствует спецификациям DNS.

Также можно сделать алиасы для почтового сервера типа pop.example.ru и smtp.example.ru. Зачем это надо? Это позволит клиенту не зависеть от особенностей вашей инфраструктуры, один раз прописав настройки. Допустим, что ваша компания разрослась и выделила для обслуживания внешних клиентов отдельный почтовый сервер mail1, все что вам понадобиться, это изменить две DNS записи, клиенты и не заметят того, что работают с новым сервером. Для создания алиасов используются записи типа CNAME:

Читайте также:  Gta samp настройка своего сервера

На этом настройку прямой DNS зоны можно считать законченной, остается самое интересное — обратная зона. Обратная зона управляется провайдером, выдавшим вам IP адрес и самостоятельно управлять ей вы не можете (если только вы не владелец блока IP адресов). Но добавить как минимум одну запись в обратную зону необходимо. Как мы писали в прошлой статье, многие почтовые сервера проверяют PTR записи (записи обратной зоны) для отправляющего сервера и при их отсутствии или несовпадении с доменом отправителя такое письмо будет отклонено. Поэтому попросите провайдера добавить для вас запись вида:

Немного странный вид, не правда ли? Разберем структуру PTR записи более подробно. Для обратного преобразования имен используется специальный домен верхнего уровня in-addr.arpa. Это сделано для того, чтобы использовать для прямого и обратного преобразования имен одни и те же программные механизмы. Дело в том, что мнемонические имена пишутся слева направо, а IP адреса справа налево. Так mail.example.com. означает что хост mail находится в домене example, который находится в домене верхнего уровня com., 11.22.33.44 означает что хост 44 находится в подсети 33, которая входит в подсеть 22, принадлежащую сети 11. Для сохранения единого порядка PTR записи содержат IP адрес «задом наперед» дополненный доменом верхнего уровня in-addr.arpa.

Проверить MX и PTR записи также можно командой nslookup используя дополнительный параметр -type=MX или -type=PTR

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

Источник

DNS для Exchange 2013

DNS записи Exchange 2013 использует прежде всего для обмена сообщениями с внешними почтовыми серверами. Речь конечно же идет о публичных записях DNS основных доменов организаций .

Найти больше информации по настройке и администрированию Exchange 2013 на моем блоге вы сможете в основной статье тематики — Exchange 2013 — Установка, настройка, администрирование.

DNS записи Exchange 2013

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

Базовый минимум

Для начала на сервере вашего DNS-провайдера необходимо создать минимальный набор записей, с помощью которых мы дадим знать всему миру о нашем почтовом сервере и домене/ах, который он обслуживает. Без этого наш сервер не будет иметь возможности принимать почту из вне, но, тем не менее, сможет выполнять роль изолированного почтового сервера. Конечно последний вариант устроит далеко не всех.

Окружение

Моя тестовая инфраструктура была развернута по статьям, которые доступны по тегу Exchange 2013 Configuring. На данный момент есть три домена — bissquit.com, corp.bissquit.com, tech.bissquit.com.

Итак, для домена bissquit.com созданы следующие записи:

FQDN Тип DNS-записи Значение
bissquit.com MX mail.bissquit.com
mail.bissquit.com A 178.162.51.81
owa.bissquit.com CNAME mail.bissquit.com
autodiscover.bissquit.com CNAME mail.bissquit.com

Запись owa.bissquit.com создана на будущее, если вдруг захочется на неё пересадить веб-клиент Outlook, но в данный момент она не используется.

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

DNS записи для поддоменов

Кто внимательно читал мои статьи по настройке сервера Exchange 2013 помнит, что в своей инфраструктуре я использовал домены третьего уровня как обслуживаемые (Подробнее в моей статье 1 ). Поэтому стоит упомянуть также о создании для них необходимых DNS-записей.

FQDN Тип DNS-записи Значение
corp.bissquit.com MX mail.corp.bissquit.com
mail.corp.bissquit.com A 178.162.51.81
FQDN Тип DNS-записи Значение
tech.bissquit.com MX mail.tech.bissquit.com
mail.tech.bissquit.com A 178.162.51.81

Если кому-то вдруг интересно что будет, если вы не создадите необходимые записи для доменов, смотрите скриншот ниже:

В этом примере Mail.ru отклонил сообщение, отправленное с домена corp.bissquit.com. Конечно тут многое зависит от настроек самого сервера и многие это сообщение приняли бы, но ответить на него не смогли бы из-за неправильной настройки или отсутствия необходимых публичных DNS-записей.

Ну и чтобы не быть голословным, проверим доставку писем со всех ящиков на любой публичный сервер (у меня это mail.ru):

Читайте также:  Настройка днс сервера байфлай

Сверху на скрине часть веб-интерфейса mail.ru, снизу — список почтовых ящиков пользователей на моем сервере Exchange. Письма на ящик mail.ru отправлял с каждого из созданных в Exchange пользователя (Сергей, Елена, bissquit).

Также проверим как ходит почта в обратную сторону — от mail.ru до моего сервера:

На каждое тестовое сообщение я написал ответ со своего публичного ящика на mail.ru — например на сообщение от lena@corp.bissquit.com — «test 02 ok».

В завершение хочу сказать, что не каждый провайдер DNS предоставляет возможность создания mx-записей к поддоменам. В моем случае это было возможно, но в виду «дружелюбной» админки DNS пришлось даже связываться с техподдержкой провайдера и спрашивать что и как сделать, чтобы получить желаемое. Кроме этого, у моих доменов отсутствуют ptr-записи в связи с тем, что я пользуюсь услугами интернет от «домашнего» провайдера. Для тестовой инфраструктуры и написания этой статьи вполне достаточно и такого минимума.

Источник

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

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

Если вам интересна тематика почтовых серверов, рекомендую обратиться к соответствующим тегам на моем блоге — Postfix и Exchange Server.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Adblock
detector