Dns record not found как исправить

Обновлено: 02.07.2024

В этой статье описывается, как устранять неполадки на DNS-серверах.

Проверка IP-конфигурации

Выполните ipconfig /all команду из командной строки и проверьте IP-адрес, маску подсети и шлюз по умолчанию.

Проверьте, является ли DNS-сервер полномочным для имени, которое ищется. Если это так, см. раздел Проверка на наличие проблем с достоверными данными.

Выполните следующую команду.

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

Очистка кэша сопоставителя. Для этого выполните следующую команду в окне командной строки с правами администратора:

Или в окне администрирования PowerShell выполните следующий командлет:

Повторите шаг 3.

Проверка неполадок DNS-сервера

Журнал событий

Проверьте следующие журналы, чтобы узнать, есть ли записанные ошибки:

Тестирование с помощью запроса nslookup

Выполните следующую команду и проверьте, доступен ли DNS-сервер с клиентских компьютеров.

Если сопоставитель возвращает IP-адрес клиента, у сервера нет проблем.

Если сопоставитель возвращает ответ "сбой сервера" или "Запрос отклонен", зона может быть приостановлена или сервер может быть перегружен. Чтобы узнать, приостановлен ли он, перейдите на вкладку Общие окна свойств зоны в консоли DNS.

Если сопоставитель возвращает ответ "запрос на превышение времени ожидания сервера" или "нет ответа от сервера", возможно, служба DNS не запущена. Попробуйте перезапустить службу DNS-сервера, введя следующую команду в командной строке на сервере:

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

В редких случаях DNS-сервер может иметь расширенную конфигурацию безопасности или брандмауэра. Если сервер расположен в другой сети, доступной только через промежуточный узел (например, маршрутизатор фильтрации пакетов или прокси-сервер), DNS-сервер может использовать нестандартный порт для прослушивания и получения клиентских запросов. По умолчанию программа nslookup отправляет запросы на DNS-серверы через порт UDP 53. Поэтому, если DNS-сервер использует любой другой порт, запросы nslookup завершатся ошибкой. Если вы считаете, что это может быть проблема, проверьте, используется ли промежуточный фильтр для блокировки трафика на хорошо известных портах DNS. Если это не так, попробуйте изменить фильтры пакетов или правила портов в брандмауэре, чтобы разрешить трафик через порт UDP/TCP 53.

Проверка на наличие проблем с достоверными данными

Проверьте, является ли сервер, который возвращает неверный ответ, основным сервером для зоны (основным сервером-источником для зоны или сервером, который использует интеграцию Active Directory для загрузки зоны) или сервер, на котором размещена дополнительная копия зоны.

Если сервер является сервером-источником

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

Если на сервере размещается дополнительная копия зоны

Изучите зону на сервере-источнике (сервере, с которого этот сервер извлекает зоны).

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

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

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

На сервере-получателе выполните принудительную пересылку зоны с помощью консоли DNS или выполните следующую команду:

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

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

Проверка проблем с рекурсией

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

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

Сервер, используемый во время запроса, не отвечает.

Сервер, используемый во время запроса, предоставляет неверные данные.

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

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

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

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

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

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

Тестирование неработающего делегирования

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

В командной строке на тестируемом сервере введите следующее:

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

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

Если ответ не содержит запись ресурса NS, делегирование будет разорвано.

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

Если вы определили, что вы используете неработающее делегирование, исправьте его, добавив или обновив запись ресурса "A" в родительской зоне, используя допустимый IP-адрес для соответствующего DNS-сервера для делегированной зоны.

Просмотр текущих корневых ссылок

Запустите консоль DNS.

Добавьте или подключитесь к DNS-серверу, который не прошел рекурсивный запрос.

Щелкните правой кнопкой мыши сервер и выберите пункт Свойства.

Щелкните корневые ссылки.

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

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

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

Проблемы с зонными ошибками

Выполните следующие проверки:

Проверьте Просмотр событий как для основного, так и для дополнительного DNS-сервера.

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

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

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

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

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

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

Проверьте, запущена ли на сервере-источнике другая реализация сервера DNS, например BIND. если да, то возможно, что зона на сервере источника включает несовместимые записи ресурсов, которые Windows не распознает.

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

Если вы видите запись «DMARC не найдена», запись «DMARC не опубликована» или запись «DMARC отсутствует», это означает, что в домене отсутствует самый эффективный и мощный механизм идентификации электронной почты, такой как DMARC.

Source: Shutterstock

Чтобы предотвратить спуфинг электронной почты (практика злоумышленников маскироваться под конкретного пользователя или подключенного к сети устройства с целью похищения данных), все домены должны иметь систему авторизации электронной почты. Наверное, вы слышали о механизмах SPF и DKIM. Но дело в том, что ни SPF, ни DKIM сами по себе не могут остановить заимствование вашего домена и не могут предотвратить спуфинг электронной почты. DMARC (Domain-based Message Authentication, Reporting & Conformance) приходит на помощь. Он сочетает в себе механизмы SPF и DKIM и обеспечивает 100% защиту от атак.

DMARC может защищать от фишинг атак. Фишинг - это мошенническая попытка получить конфиденциальную информацию. Выдавая себя за правомерного индивида, хакеры манипулируют жертвами для выполнения определенных действий. По данным Verizon Data Breach Investigations Report 2018, Фишинг и претекстинг составляют 93% нарушений. 80% всех нарушений связаны с учетными данными DBIR.

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

No DMARC record

No DMARC record found

DMARC record is missing

DMARC record not found

No DMARC record published

DMARC policy not enabled

Unable to find DMARC record

В зависимости от того, чего вы хотите достичь. Есть 2 возможных варианта.

Простую запись DMARC можно рассмотреть на следующем примере:

Получилось! Недостающая запись DMARC была успешно добавлена.

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

Вариант 2: Обеспечьте 100% защиту от атак с изменением авторства и спуфинга.

Чтобы добиться 100% защиты, вам нужно понять механизм системы DMARC и то, как она работает. Трудно добиться 100% защиты от спуфинга электронной почты; это требует усердия и некоторого времени (обычно более 2 месяцев и зависит от того, насколько сложна ваша инфраструктура электронной почты).

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

Процесс начинается с простого ввода базовой записи DMARC.

3 шага для устранения проблемы “No DMARC record found”

1. Опубликуйте запись SPF.

Используйте бесплатный генератор SPF записи EasyDMARC или любой другой, чтобы создать свою запись и опубликовать сгенерированную запись в вашем DNS.

Запись SPF выглядит следующим образом.

2. Настройте идентификацию DKIM.

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

Для правильного синтаксиса необходимо использовать генераторы записей DKIM.

3. Опубликуйте запись DMARC.

Наконец готовы настроить запись DMARC. Используйте бесплатный генератор DMARC записи EasyDMARC и опубликуйте сгенерированную запись в свой DNS.Во-первых, настоятельно рекомендуется иметь политику мониторинга (p=none). После получения успешных результатов мониторинга система предложит вам изменить опубликованную политику.

Не используйте политику p=reject в самом начале, если вы не уверены, что у вас есть правильная конфигурация и видимость в вашей почтовой инфраструктуре.

Очень важно подчеркнуть, что ни SPF, ни DKIM сами по себе не могут помешать киберпреступникам отправлять электронные письма с использованием вашего домена.

Имейте в виду, что только запись DMARC с политикой “p=reject” является самой мощной и стандартной в отрасли системой идентификации электронной почты. Однако добиться “p=reject” трудно, потому что размещение его в DNS без надлежащего мониторинга может привести к тому, что ваши действительные электронные письма будут отклонены.

Вы можете легко определить и устранить свои проблемы, автоматизировав свои отчеты с помощью EasyDMARC. Вот пример вышеупомянутых агрегированных отчетов DMARC:

Эти статьи помогут вам настроить DMARC-записи от различных провайдеров DNS:

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

Коллеги, всех приветствую.

Диагностика сервера каталогов

Выполнение начальной настройки:
Выполняется попытка поиска основного сервера.
Основной сервер = dc01
* Идентифицирован лес AD.
Сбор начальных данных завершен.

Выполнение обязательных начальных проверок

Выполнение основных проверок

Сервер проверки: Default-First-Site-Name\DC01
Пропуск всех проверок, поскольку сервер DC01 не отвечает на запросы
службы каталога.

Выполнение проверок разделов на: ForestDnsZones
Запуск проверки: CheckSDRefDom
. ForestDnsZones - пройдена проверка
CheckSDRefDom
Запуск проверки: CrossRefValidation
. ForestDnsZones - пройдена проверка
CrossRefValidation

Выполнение проверок разделов на: DomainDnsZones
Запуск проверки: CheckSDRefDom
. DomainDnsZones - пройдена проверка
CheckSDRefDom
Запуск проверки: CrossRefValidation
. DomainDnsZones - пройдена проверка
CrossRefValidation

Выполнение проверок разделов на: Schema
Запуск проверки: CheckSDRefDom
. Schema - пройдена проверка CheckSDRefDom
Запуск проверки: CrossRefValidation
. Schema - пройдена проверка
CrossRefValidation

Выполнение проверок разделов на: Configuration
Запуск проверки: CheckSDRefDom
. Configuration - пройдена проверка
CheckSDRefDom
Запуск проверки: CrossRefValidation
. Configuration - пройдена проверка
CrossRefValidation

Выполнение проверок разделов на: NNIIT
Запуск проверки: CheckSDRefDom
. NNIIT - пройдена проверка CheckSDRefDom
Запуск проверки: CrossRefValidation
. NNIIT - пройдена проверка CrossRefValidation

Выполнение проверок предприятия на: NNIIT.DOMAIN
Запуск проверки: LocatorCheck
. NNIIT.DOMAIN - пройдена проверка
LocatorCheck
Запуск проверки: Intersite
. NNIIT.DOMAIN - пройдена проверка Intersite

Ответы

Если нужно, то создайте dns partitions

После этого через оснастку DNS создайте зоны nniit.domain и _msdsc.nniit.domain

(На сетевых интерфейсах DCs должен быть адрес вашего DNS.)

Все ответы

Если нужно, то создайте dns partitions

После этого через оснастку DNS создайте зоны nniit.domain и _msdsc.nniit.domain

(На сетевых интерфейсах DCs должен быть адрес вашего DNS.)

C:\Users\morozov.NNIIT>dnscmd dc01 /enlistdirectoryPartition /nniit.domain

C:\Users\morozov.NNIIT>dnscmd dc01 /createDirectoryPartition /NNIIT.DOMAIN

Однако беспокоит следущее:

Выполнение основных проверок

И в логах DNS сразу же выпали ошибки:

создано. сделано ipconfig /registerdns

Ошибка dcdiag /DnsAll осталась

Диагностика сервера каталогов

Выполнение обязательных начальных проверок

Сервер проверки: Default-First-Site-Name\DC01
Запуск проверки: Connectivity
* Active Directory LDAP Services Check
Determining IP4 connectivity
Determining IP6 connectivity
* Active Directory RPC Services Check
. DC01 - пройдена проверка Connectivity

Выполнение основных проверок

Сервер проверки: Default-First-Site-Name\DC01
Проверка пропущена по запросу пользователя: Advertising
Проверка пропущена по запросу пользователя: CheckSecurityError
Проверка пропущена по запросу пользователя: CutoffServers
Проверка пропущена по запросу пользователя: FrsEvent
Проверка пропущена по запросу пользователя: DFSREvent
Проверка пропущена по запросу пользователя: SysVolCheck
Проверка пропущена по запросу пользователя: KccEvent
Проверка пропущена по запросу пользователя: KnowsOfRoleHolders
Проверка пропущена по запросу пользователя: MachineAccount
Проверка пропущена по запросу пользователя: NCSecDesc
Проверка пропущена по запросу пользователя: NetLogons
Проверка пропущена по запросу пользователя: ObjectsReplicated
Проверка пропущена по запросу пользователя: OutboundSecureChannels
Проверка пропущена по запросу пользователя: Replications
Проверка пропущена по запросу пользователя: RidManager
Проверка пропущена по запросу пользователя: Services
Проверка пропущена по запросу пользователя: SystemLog
Проверка пропущена по запросу пользователя: Topology
Проверка пропущена по запросу пользователя: VerifyEnterpriseReferences
Проверка пропущена по запросу пользователя: VerifyReferences
Проверка пропущена по запросу пользователя: VerifyReplicas

Запуск проверки: DNS

Выполнение проверок разделов на: DomainDnsZones
Проверка пропущена по запросу пользователя: CheckSDRefDom
Проверка пропущена по запросу пользователя: CrossRefValidation

Выполнение проверок разделов на: Schema
Проверка пропущена по запросу пользователя: CheckSDRefDom
Проверка пропущена по запросу пользователя: CrossRefValidation

Выполнение проверок разделов на: Configuration
Проверка пропущена по запросу пользователя: CheckSDRefDom
Проверка пропущена по запросу пользователя: CrossRefValidation

Выполнение проверок разделов на: NNIIT
Проверка пропущена по запросу пользователя: CheckSDRefDom
Проверка пропущена по запросу пользователя: CrossRefValidation

TEST: Authentication (Auth)
Тест проверки подлинности: завершен успешно

TEST: Delegations (Del)
No delegations were found in this zone on this DNS server

TEST: Dynamic update (Dyn)
Test record _dcdiag_test_record added successfully in zone NNIIT.DOMAIN
Warning: Failed to delete the test record _dcdiag_test_record in zone NNIIT.DOMAIN
[Error details: 9505 (Type: Win32 - Description: Небезопасный пакет DNS.)]

TEST: Records registration (RReg)
Сетевой адаптер [00000006] Гигабитное сетевое подключение Intel(R) 82566DM:
Matching CNAME record found at DNS server 192.168.0.252:
2366bed9-f212-4632-9d16-fe458b7d9bbd._msdcs.NNIIT.DOMAIN

Matching A record found at DNS server 192.168.0.252:
dc01.NNIIT.DOMAIN

Matching SRV record found at DNS server 192.168.0.252:
_ldap._tcp.NNIIT.DOMAIN

Matching SRV record found at DNS server 192.168.0.252:
_ldap._tcp.62a630aa-f1fd-4c2c-9f6d-523593641d1d.domains._msdcs.NNIIT.DOMAIN

Matching SRV record found at DNS server 192.168.0.252:
_kerberos._tcp.dc._msdcs.NNIIT.DOMAIN

Matching SRV record found at DNS server 192.168.0.252:
_ldap._tcp.dc._msdcs.NNIIT.DOMAIN

Matching SRV record found at DNS server 192.168.0.252:
_kerberos._tcp.NNIIT.DOMAIN

Matching SRV record found at DNS server 192.168.0.252:
_kerberos._udp.NNIIT.DOMAIN

Matching SRV record found at DNS server 192.168.0.252:
_kpasswd._tcp.NNIIT.DOMAIN

Matching SRV record found at DNS server 192.168.0.252:
_ldap._tcp.Default-First-Site-Name._sites.NNIIT.DOMAIN

Matching SRV record found at DNS server 192.168.0.252:
_kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.NNIIT.DOMAIN

Matching SRV record found at DNS server 192.168.0.252:
_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.NNIIT.DOMAIN

Matching SRV record found at DNS server 192.168.0.252:
_kerberos._tcp.Default-First-Site-Name._sites.NNIIT.DOMAIN

Matching SRV record found at DNS server 192.168.0.252:
_ldap._tcp.gc._msdcs.NNIIT.DOMAIN

Matching A record found at DNS server 192.168.0.252:
gc._msdcs.NNIIT.DOMAIN

Matching SRV record found at DNS server 192.168.0.252:
_gc._tcp.Default-First-Site-Name._sites.NNIIT.DOMAIN

Matching SRV record found at DNS server 192.168.0.252:
_ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.NNIIT.DOMAIN

Matching SRV record found at DNS server 192.168.0.252:
_ldap._tcp.pdc._msdcs.NNIIT.DOMAIN

Matching CNAME record found at DNS server 192.168.0.253:
2366bed9-f212-4632-9d16-fe458b7d9bbd._msdcs.NNIIT.DOMAIN

Matching A record found at DNS server 192.168.0.253:
dc01.NNIIT.DOMAIN

Matching SRV record found at DNS server 192.168.0.253:
_ldap._tcp.NNIIT.DOMAIN

Matching SRV record found at DNS server 192.168.0.253:
_ldap._tcp.62a630aa-f1fd-4c2c-9f6d-523593641d1d.domains._msdcs.NNIIT.DOMAIN

Matching SRV record found at DNS server 192.168.0.253:
_kerberos._tcp.dc._msdcs.NNIIT.DOMAIN

Matching SRV record found at DNS server 192.168.0.253:
_ldap._tcp.dc._msdcs.NNIIT.DOMAIN

Matching SRV record found at DNS server 192.168.0.253:
_kerberos._tcp.NNIIT.DOMAIN

Matching SRV record found at DNS server 192.168.0.253:
_kerberos._udp.NNIIT.DOMAIN

Matching SRV record found at DNS server 192.168.0.253:
_kpasswd._tcp.NNIIT.DOMAIN

Matching SRV record found at DNS server 192.168.0.253:
_ldap._tcp.Default-First-Site-Name._sites.NNIIT.DOMAIN

Matching SRV record found at DNS server 192.168.0.253:
_kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.NNIIT.DOMAIN

Matching SRV record found at DNS server 192.168.0.253:
_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.NNIIT.DOMAIN

Matching SRV record found at DNS server 192.168.0.253:
_kerberos._tcp.Default-First-Site-Name._sites.NNIIT.DOMAIN

Matching SRV record found at DNS server 192.168.0.253:
_ldap._tcp.gc._msdcs.NNIIT.DOMAIN

Matching A record found at DNS server 192.168.0.253:
gc._msdcs.NNIIT.DOMAIN

Matching SRV record found at DNS server 192.168.0.253:
_gc._tcp.Default-First-Site-Name._sites.NNIIT.DOMAIN

Matching SRV record found at DNS server 192.168.0.253:
_ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.NNIIT.DOMAIN

Matching SRV record found at DNS server 192.168.0.253:
_ldap._tcp.pdc._msdcs.NNIIT.DOMAIN

DNS-сервер: 192.168.0.252 (DC01)
Все проверки для данного DNS-сервера пройдены
Name resolution is functional._ldap._tcp SRV record for the forest root domain is registered

DNS-сервер: 192.168.0.253 (SERVER)
Все проверки для данного DNS-сервера пройдены
Name resolution is functional._ldap._tcp SRV record for the forest root domain is registered

Для чего нужно?

или
550-There's no corresponding PTR for your IP address (IP-address), which is 550 required. Sorry, bye.

или просто
550 Your IP has no PTR Record

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

Как настроить и использовать?

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

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

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

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

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

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

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

Частые вопросы

PTR-запись для почтового сервера — какую указать?

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

Как создать PTR-запись?

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

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