Обновить ptr запись в dns

Обновлено: 04.07.2024

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

Для простоты и сокращения количества букв мы рассмотрим простейшую (и наиболее распространенную) ситуацию:

Касательно почты, в DNS нас интересует четыре типа записей.

A-запись

mail IN A 127.127.127.127

Где:
mail — домен.
IN A — тип записи.
127.127.127.127 — IP нашего почтового сервера.

MX-записи.

MX (Mail eXchange) — основная DNS-запись для электопочты. Она указывает, какими серверами обрабатывается почта для нашего домена.

MX-запись должна указывать именно на A-запись почтового сервера. Ставить MX указателем на IP или CNAME — не правильно.

Приоритет MX-записи нужен тогда, когда существует больше одного почтового сервера для одного домена (например у Google Mail их шесть). Он указывает, к какому серверу идет обращение в первую очередь, во вторую и так далее (если первый (второй, десятый) сервер недоступен или перегружен или по другим причинам не может принять письмо). Логика простая — приоритетнее тот, цифра которого меньше. Порядок цифр — не ограничен, хоть 10-20-30, хоть 1000-2000-3000.

Если у домена нет ни одной MX-записи, либо ни один из MX-серверов не доступен, сервер отправителя попытается доставить почту на IP, указанный в A-записи домена. Это назвается А-доставкой, но в принципе не кошерно и не используется многими серверами — нужно указывать MX, даже если он всего один.

PTR-запись.

PTR (PoinTeR) — так называемая «обратная запись». Она позволяет обратное разрешение (reverse resolving) IP-адреса в FQDN-хост.

Наш IP в виде reverse будет выглядеть так: 127.127.127.127.in-addr.arpa. В данном примере видно плохо, но адрес инвертируется в обратной зоне. Т.е. IP 192.168.0.1 будет выглядеть как 1.0.168.192.in-addr.arpa.

Для корректного распознования хоста, запись IP-адреса, с которого отправляется должна соответсовать hostname почтового сервера, отправляемому в HELO\EHLO.

PTR-запись в нашем случае, соответственно:

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

TXT-запись и SPF.

TXT (TeXT) — текстовая запись DNS. Нам она интересна только тем, что может (и в современном мире — должна) содержать в себе SPF.

SPF (Sender Policy Framework) — запись, позволяющая вам указать, какие сервера имеют право отправлять почту от имени вашего домена (представившись вашим сервером, либо с обратным адресом в вашем домене).

SPF-запись выглядит так:

v=spf1 ip4:1.1.1.1 +a +mx -all (пример).

v=spf1 — версия протокола.
(+\-)a — разрешение или запрет отправки почты с IP, соответствующего A-записи домена.
(+\-)mx — разрешение или запрет отправки почты с IP, соответствующего MX-записи домена.
ip4:IP — явное указание IP, с которого можно принимать почту от имени домена.
(

\-all) — отвергать или принимать почту от IP, не перечисленных в списке и не указанных явно.

В нашем случае TXT SPF запись будет такой:

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

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

Буду рад комментариям, готов ответить на вопросы.
В следующих статьях я напишу об SMTP, Greylisting-е и RBL.
А еще вы можете вступить в блог и тоже о чем-то рассказать.

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

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

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

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

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

Примечание: если адреса домена и почтового сервера не совпадают, то PTR-запись должна создаваться именно для MX-записи.

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

Яндекс.Дзен и узнавайте первыми о новых материалах, опубликованных на сайте.

Если считаете статью полезной,
не ленитесь ставить лайки и делиться с друзьями.

У нас проблема возникла с дублированием записей в обратной зоне PTR DNS. Но для нас не было проблем что они там дублируются . Но после того как внедрили fortigate. Начались проблемы с интернетом. Он там хитро трафик делит. И смотрит в днс.

Решили настроить динамическое обновление dns через DHCP.

Сначала создали учётку srv.dnsupd для доступа dns. И добавили её в группу DnsUpdateProxy.

Включить автоматическую очистку устаревших записей. Оставим по умолчанию 7 дней так как у нас dhcp аренда 8 дней.

Войдите в клиентскую среду и нажмите Пуск > Программы > Администрирование > DNS > Диспетчер DNS .
Щелкните правой кнопкой мыши соответствующий DNS-сервер и выберите « Установить устаревание / очистку для всех зон» .
Убедитесь, что выбрано Очистить устаревшие записи ресурсов .
Установите интервал без обновления и интервал обновления, чтобы общая продолжительность была равна или меньше срока аренды DHCP, и нажмите кнопку ОК .
Например, если срок аренды DHCP составляет 8 дней , значение по умолчанию для каждого поля может составлять 4 дня или меньше.
Выберите Применить эти параметры к существующим зонам, интегрированным в Active Directory , и нажмите ОК .
Щелкните правой кнопкой мыши соответствующий DNS-сервер и выберите « Очистить записи ресурсов состояния», чтобы начать немедленную очистку .

В заданный период времени сервер выполняет поиск записей DNS и удаляет устаревшую информацию.

Также обратите внимание, что рекомендуется настроить параметры «Интервал без обновления» и «Интервал обновления», меньший, чем период аренды DHCP.
Теперь настраиваем DHCP что бы записи в DNS сами обновлялись.

Чтобы настроить динамическое обновление DNS для DHCP-сервера под управлением Windows Server 2003, выполните следующие действия:

Со всеми настроенными здесь вещами мы фактически настроили DHCP-сервер на владение всеми его клиентскими записями на DNS-сервере. Однако мы все еще далеки от завершения, поскольку нам нужно сделать несколько дополнительных шагов.

Добавьте DHCP-сервер в группу безопасности DnsUpdateProxy.

В документации пишут :Если DHCP-сервер находится на другом компьютере, чем контроллер домена, убедитесь, что DHCP-сервер включен в группу DnsUpdateProxy в Active Directory . В противном случае DHCP-сервер не сможет обновлять записи на DNS-сервере.
Но у меня так не заработала на 2016 windows. Я добавил в группу еще контролеры домена. Тогда все норм стало.

Что касается использования группы DnsUpdateProxy, я понимаю, что в эту группу должны входить только DHCP-серверы, а не пользователь динамического обновления DNS. Предполагается, что учетная запись пользователя будет добавлена в конфигурацию DHCP-сервера, а не в группу DnsUpdateProxy.
Группа DnsUpdateProxy предназначена для клиентов DNS. Пользователь не является клиентом, это механизм, используемый клиентом (DHCP-сервером) для динамического обновления DNS, когда включены только безопасные обновления. Клиент остается сервером DHCP.
Когда DHCP-сервер находится на контроллере домена, помимо того, что он входит в группу и добавляет пользователя в конфигурацию DHCP, вам также необходимо отключить OpenACLOnProxyUpdates. Если вы этого не делаете, вы добавляете уязвимость, потому что членство в группе DnsUpdateProxy дает слишком много полномочий над записями DNS.
Некоторые школы считают, что DHCP на контроллере домена не должен быть членом DnsUpdateProxy, а только для пользователя обновления DNS должен быть назначен DHCP. Это может быть верно для более старых версий Windows Server, но для 2012R2 и более поздних версий у меня есть чувство из технических документов, что сервер все еще должен быть в группе DnsUpdateProxy, но из-за того, что он является DC, разрешения членства в этой группе открывают уязвимость.

Итак, если у вас есть DHCP на контроллере домена с включенным безопасным динамическим обновлением DNS, вы должны также выполнить эту команду на контроллере домена, на котором работает DHCP, чтобы его DNS не позволял «чужим» обновлениям изменять записи, принадлежащие DHCP:

Укажите учетные данные для защиты динамического обновления DNS.

Это применимо, если зона DNS, в которой ваш DHCP-сервер будет регистрировать / обновлять записи, является зоной, интегрированной в Active Directory, которая допускает только безопасные динамические обновления .

Вам необходимо указать учетную запись пользователя в свойствах DHCP-сервера . Откройте вкладку « Дополнительно » в свойствах DHCP-сервера и нажмите кнопку « Учетные данные» .

Введите имя пользователя, домен и пароль в доступное поле.
Обратите внимание, что учетная запись может быть учетной записью обычного пользователя без каких-либо специальных привилегий, но она должна существовать в том же лесу, что и DNS-сервер . Вы также можете использовать учетную запись пользователя из другого леса, если его лес установил доверие леса с лесом, в котором находится DNS-сервер.
Таким образом, DHCP-сервер будет по-прежнему арендовать IP-адрес, но не будет создавать DNS-запись, если запись с таким именем уже существует .
Что ж, это почти все, что вам нужно для настройки динамического обновления DNS на DHCP-сервере Windows. С этого момента ваш DHCP-сервер будет заботиться о записях DNS для своих клиентов. DHCP-сервер будет регистрировать и обновлять записи для своих клиентов , а также удаляет записи об истекших сроках аренды . Это гарантирует, что DNS-сервер не будет заполнен записями о неактивных клиентах. Кроме того, вы также можете настроить устаревание и очистку в зоне DNS в соответствии со временем аренды DHCP, и это поможет очистить неиспользуемые записи.

Существует много типов DNS записей и для новичков может быть слишком сложно понять, какая функция у этой DNS-записи или как ее настроить. В этом уроке вы узнаете, что такое PTR запись и как проверить настроена ли она для IP-адреса.

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

Что такое PTR запись

Зачем необходима PTR запись

Что вам понадобится

Перед тем, как вы начнете это руководство, вам понадобится следующее:

Доступ к консоли вашего компьютера (необязательно)

Способ 1 — Проверка PTR с помощью nslookup или dig

Windows, Unix и схожие операционные системы (Linux, MacOS) имеют встроенные инструменты для проверки DNS записей. Если вы являетесь пользователем Windows, следуйте данным этапам:

Войдите в меню Пуск Windows, впишите cmd и нажмите ENTER.
Должно появиться чёрное окно (командная строка windows).

Впишите следующую команду для получения имени хоста IP адреса (смените IP_ADDESS на нужный вам IP):

К примеру, если вы хотите проверить PTR запись для 54.243.154.xx, вы увидите похожий результат:

Для пользователей Linux или Mac процесс схож:

На MacOS, войдите в терминал с помощью (F4). Большинство дистрибутивов Linux позволяют открыть терминал сочетанием клавиш Ctrl+Alt+T.
Используйте эту команду для проверки PTR записи (смените IP_ADDRESS на нужный вам IP):

К примеру, вот результат проверки PTR записи для IP адреса 54.243.154.xx:

Способ 2 — Использование онлайн инструментов

Еще один способ для получения информации об имени хоста IP-адреса, это использовать инструмент для обратного поиска MxToolBox. Все что нужно, это вписать в поле IP адрес и нажать кнопку Reverse Lookup (Обратный поиск).

Заключение

PTR-запись - это запись в DNS, которая служит для связи IP-адреса сервера с каноническим именем этого сервера. Зачастую в PTR-записи указывается доменное имя, которое используется на сервере.

Например, на сервере с доменом sweb.ru используется IP-адрес 77.222.41.9. Для этого IP-адреса существует PTR-запись со значением "sweb.ru":

Значение PTR-записи не обязательно будет соответствовать какому-либо доменному имени, в A-записи которого используется IP-адрес.

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

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

Задание PTR-записи

PTR-записи заданы для всех основных IP-адресов серверов виртуального хостинга и выделенных серверов под нашим администрированием.

PTR-записи изначально отсутствуют для услуг:

Дополнительный IP-адрес - если необходимо указать PTR-записи, обратитесь в отдел технической поддержки через форму "Поддержка" панели управления. Указав, какую именно PTR-запись для какого IP-адреса следует задать.
На услуге VDS возможно самостоятельно указать PTR-запись в панели управление, раздел "IP-адреса".
Для услуги аренда выделенного сервера обращайтесь в отдел аренды серверов.

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

Читайте также: