Как настроить обратную зону dns

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

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

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 сессии.

Источник

OpenRate.us

Сайт про CRM-маркетинг, рассылки и вот это всё

Настраиваем rDNS и PTR-записи

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

Корректно настроенные rDNS адреса нужны, чтобы отправлять сообщения с вашего собственного сервера. Практически все почтовые серверы отвергнут приём сообщения ещё на стадии начала сессии, если у IP-адреса вашего сервера отсутствует запись в обратной зоне DNS. Причина отказа удалённым почтовым сервером может быть такой:

Число 550 во всех трёх случаях является стандартным кодом почтового SMTP сервера, сообщающего о критической ошибке, которая препятствует дальнейшей работе в рамках данной почтовой сессии. Вообще все ошибки серии 500 являются критическими и продолжение передачи почты после их появления невозможно. Текст же поясняет причину отказа более подробно и сообщает, что администратор почтового сервера-получателя настроил его на проверку наличия у почтового сервера-отправителя записи в обратной зоне DNS (rDNS) и в случае её отсутствия сервер-получатель обязан отказывать отправителю в соединении (SMTP-ошибки серии 5XX).

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

Оператору блока IP-адресов для регистрации обратной зоны DNS необходимо зарегистрировать в своём личном кабинете на сайте RIPE объект типа «domain», указать адрес DNS-серверов, которые будут поддерживать зону rDNS и настроить поддержку зоны вида 3.2.1.in-addr.arpa на них. За ресурсы в обратной зоне отвечает указатель (pointer) — запись типа PTR. К ней-то и идут запросы о разрешении IP-адреса и имя хоста (см. ниже описание принципа построения PTR записи).

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

В обоих случаях имя IP-адресу почтового сервера, а особенно корпоративного почтового сервера, следует давать осмысленно.

Примеры хороших имён для сервера почты:

Примеры плохих имён:

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

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

В Postfix необходимо включить опцию

Проверка обратной зоны DNS: http://remote.12dt.com
Введите свой IP адрес, если отображается ваш домен — настройка правильная

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

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

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) отвечает отдельный сервер.

Например, если IP вашего почтового сервера 78.56.158.23. То в NS записи сервера или настройки хостера необходимо добавить следующую DNS запись (IP при этом записывается в обратном порядке):

Источник

Создание в Windows Server обратной DNS-зоны с нестандартной маской

Reverse lookup-зона — полезная и нужная штука, но в случае создания оной для локальной сети — проблем не возникает. Сложнее, когда провайдер делегирует часть адресного пространства.

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

Обновления личного кабинета — доступны также по RSS.

22 августа: В загрузках для домашней лабы — новые Windows Server 2022 и Windows 11 Enterprise, ядро 5.13.12 и Debian 11
12 мая: В разделе загрузок домашней лабораторной — топология для первых занятий по ENCOR, обновлённый QEMU и Bodhi Linux 6.0, опять же используемый как хост на ENCOR
3 мая: Новое в виртуальной лабе — ядро 5.12 и QEMU 6.0.0
4 апреля: Образ Kali Linux 21.01 с обновлениями за апрель 2021
4 апреля: Минималистичный образ Debian Linux 10.9 с обновлениями за апрель 2021
4 апреля: Обновлённые образы Windows Server 2019
4 апреля: Специальный образ старого Windows Server 2003 R2
4 апреля: Рабочий образ нового Windows Server 2022
8 января: Образ Ubuntu Server 21.04 (hirsute hippo) с предустановленными инструментами разработчика и Kali Linux 2021 с браузерами Chrome/Firefox — соответственно серверная и клиентская часть для грядущих вебинаров по HTTP/TLS/Security
4 января: Январское обновление домашней лабы — с QEMU 5.2.0 и всякими другими интересностями (подробнее см. новость на сайте)

Новое в архиве Knowledge Assurance. Часть из этих записей доступна бесплатно, на нашем канале YouTube.

HCIA 2.5 — Первый модуль курса Huawei HCIA Routing and Switching
AT-NETLAB 20.12 — Обновлённый вебинар по созданию и настройке домашней лабы
Cisco SPNGN1 1.0 — CCNA Service Provider (последнее прочтение) занятие 7
Cisco SPNGN1 1.0 — CCNA Service Provider (последнее прочтение) занятие 6
Cisco SPNGN1 1.0 — CCNA Service Provider (последнее прочтение) занятие 5
Cisco IINS 3.0 — Шестое занятие CCNA:Security 2020
Cisco SPNGN1 1.0 — CCNA Service Provider (последнее прочтение) занятие 4
Cisco SPNGN1 1.0 — CCNA Service Provider (последнее прочтение) занятие 3
AT-NETLAB 20.04 — Вебинар по созданию и настройке домашней лабы
Cisco IINS 3.0 — Пятое занятие CCNA:Security 2020

Источник

Что такое обратный DNS? Основные инструменты для выполнения обратного поиска DNS

Что такое обратный DNS (rDNS)?

Мы все знаем, что такое DNS и как он работает. Но даже некоторые IT-ботаники иногда забывают о rDNS, а третьи, которые только что присоединились к клубу, никогда даже не слышали о нем.

На простом языке обратный DNS или rDNS делает противоположное традиционному DNS. То есть, вместо преобразования доменного имени на IP, он преобразует IP к имени хоста.

Разрешение rDNS – это совершенно отдельный механизм от обычного разрешения DNS. Например, если домен “yourcompany.com” указывает на IP 1.2.3.4 (фиктивный IP-адрес), это не обязательно означает, что обратное разрешение для IP является 1.2.3.4.

Для хранения записей rDNS существует определенный тип записи DNS, называемый записью PTR. Эта запись также известна как ”запись ресурсов” (RR) и задает IP-адреса всех систем, используя инвертированную нотацию.

Эта конфигурация rDNS позволяет выполнять поиск IP-адреса в DNS, так как inaddr.arpa домен добавляется в инвертированную нотацию IP, превращая IP в доменное имя.

Например: чтобы преобразовать IP-адрес 1.2.3.4 в PTR-запись, нам нужно инвертировать IP и добавить домен inaddr.arpa в результате чего получается следующая запись: 4.3.2.1.in-addr.arpa.

Классическая работа системы DNS заключается в преобразовании или разрешении IP-адресов в имена, но некоторые сценарии требуют обратного, и это означает, что имена подключенных к интернету устройств переводятся с их IP-адресов. Это то, что называется rDNS, или обратное разрешение.

Поддерживают ли все типы IP-адресов rDNS? Безусловно, и IPv4 и IPv6 поддерживают поиск rDNS. В случае адресов на основе IPv4 поисковые запросы используют специальный домен in-addr.arpa, в то время как для IPv6 rDNS поиск специального домена ip6.arpa используется.

Нужен ли мне rDNS? Текущее использование обратного DNS

Насколько важна rDNS тогда? Может ли мой интернет-бизнес жить без него?

Ответ-да…и нет. В то же время.

Если у вас нет настройки rDNS для вашей ИТ-инфраструктуры, она все равно будет работать. Это не является строгим требованием. Однако некоторые вещи могут работать не так, как ожидалось, или могут вызвать трудности. Продолжай читать.

Когда rDNS полезно?

Если вы хотите, чтобы предотвратить проблемы с электронной почтой. Если вы размещаете свой собственный почтовый сервер, rDNS становится довольно полезным для ваших исходящих писем. Запись rDNS позволяет отслеживать происхождение электронной почты, повышая доверие к почтовому серверу и становясь надежным источником для многих популярных поставщиков услуг электронной почты, таких как Gmail, Yahoo, Hotmail и других. Некоторые серверы входящей электронной почты даже не позволяют вашей электронной почте поступать на их почтовые ящики, Если у вас нет настройки записи rDNS. Поэтому, если вы используете свой собственный почтовый сервер, вы захотите иметь его в виду.
Когда вы проводите расследование киберпреступности. Еще одно популярное использование обратных записей DNS-это выявление потенциальных угроз и массовые сканеры по всему интернету. Используя обе конечные точки API безопасности или веб-продукты, такие как SurfaceBrowser, вы или ваша команда можете легко идентифицировать авторов и сети, стоящие за массовым сканированием, распространением вредоносных программ или другими видами вредоносных действий — так же, как Трой Мурш показал в нашем блоге, как использовать обратные записи DNS для идентификации массовых сканеров .

Как я могу выполнить обратный поиск DNS?

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

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

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

Этот параметр dig автоматически выполняет поиск для традиционного имени IP-адреса, такого как 94.2.0.192.in-addr.arpa, и установите тип запроса и класс в PTR и IN соответственно для адресов IPv6. Поиск rDNS выполняется с использованием формата nibble под IP6.ARPA домен.

Самое интересное заключается в следующем:

Вы можете grep выходные данные для более четкого результата.

Команда host, вероятно, является самой популярной командой, когда речь заходит о выполнении быстрого разрешения rDNS с терминала. Синтаксис довольно прост:

Где XX. XX. XX. XX-это реальный IP-адрес. Давайте рассмотрим несколько примеров.

Cloudflare поставляется в первую очередь с обратным запросом разрешения DNS против 1.1.1.1:

То же самое относится и к любому другому IP-адресу, например DNS-серверу Google:

Или наши собственные securitytrails.com IP-адрес:

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

G-Suite Toolbox Dig

Некоторое время назад Google выпустила очень полезный ресурс под названием G-Suite dig , онлайн-утилита, которая позволяет выполнять любой тип DNS-запросов на основе простого, но сложного веб-интерфейса.

В этом случае выберите запись “PTR”, введите свой IP-адрес и получите полный результат rDNS за считанные секунды.

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

Обратная конечная точка DNS API

Использование нашего мощного API является еще одним отличным источником для запроса нашей пассивной базы данных DNS для любых записей PTR компании.

Конечная точка “/v1/ips/list” позволяет запрашивать домен apex (в этом случае cloudflare.com), так что вы можете легко обнаружить все известные IP-адреса, связанные с Cloudflare.com доменное имя.

Давайте использовать быстрый скрипт python, чтобы увидеть, как это выглядит:

В дополнение к записям PTR, вы также найдете открытые порты для каждого из хостов, возвращенных нашей службой API.

Благодаря нашему полностью основанному на HTTP API, вы также можете выполнить простой запрос CURL из командной строки или использовать любые другие популярные языки, включая Node.js, JavaScript, Ruby, Go и PHP.

Массивная разведка rDNS

Когда мы говорим, что SurfaceBrower – это идеальный инструмент для исследования поверхности атаки “все-в-одном”, мы действительно имеем это в виду. Помимо всех зон DNS, доменных имен, SSL и открытых портов данных он имеет, SurfaceBrowser может быть использован в качестве инструмента массового обратного поиска DNS.

Чтобы изучить данные rDNS от любой компании, просто запустите SurfaceBrowser с консоли вашего аккаунта по адресу: https://securitytrails.com/app/sb/

Выберите любое доменное имя, которое вы хотите изучить, а затем нажмите на опцию “обратный DNS”, как показано ниже:

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

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

В этом случае, исследуя fbi.gov доменное имя выявило 289 записей. Каждый из них может быть изучен в области результатов, что позволяет исследовать запись PTR, открытые порты и количество связанных IP-адресов. Взглянуть:

Если вам нужно найти связанные IP-адреса, указывающие на любую PTR-запись, просто нажмите число+ для немедленных результатов::

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

fbi.gov это “маленькая ” организация, когда речь заходит о PTR-записях, хотя мы нашли много полезной информации. Но вот что происходит, когда вы исследуете большую онлайн-компанию, такую как Google:

Ибо … cache.google.com мы нашли около 94 тыс. IP-адресов, связанных с этой записью PTR. Представьте себе выполнение этого поиска с помощью традиционных обратных инструментов DNS. Это может занять целую вечность!

Последняя мысль

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

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

Источник