Не работает reverse dns

Обновлено: 07.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-именах.

ip-адрес ПК Pointer (PTR) domain

еще есть записи;

same as parent folder Start of Authority (SOA) domain

same as parent folder Name Server (NS) domain

А с чего там domain, когда должен быть hostname? И "ip-адрес ПК" там что полный указан? Должен быть только последний октет (последняя цифра).

да, динамическия обновления включены

ip-адрес ПК Pointer (PTR) domain

еще есть записи;

same as parent folder Start of Authority (SOA) domain

same as parent folder Name Server (NS) domain

ой, да, там указан hostname.

А вот по поводу ip-адреса.

Когда создавась обратная зона, то там в качестве номера сети было указано 3 октета. Нужно было 2? Тогда последний 3-й как и где указать?

первые три октета указываются при создании зоны, последний - при создании поинтера.

Файл зоны после этого называется так, как указал sie. А записи выглядят напрмер так:

что-то не получается.

создаю зону заново, указываю 3 октета

в результате в DNS появляется такая картинка:

Reverse Lookup Zones:

создаю новый указатель (New Pointer(PTR)) - в строке с указателем выходит ip-адрес полностью, т.е по предыдущему примеру:

как (по шагам) создаете поинтер. как заполняете поля в мастере?

Reverse Lookup Zones - New Zone - Мастер установки:

- выбираю Primary zone;

- указываю номер зоны (н-р, 10.0.0)

- на следующей странице в поле Create a new file with this file name отбражается 0.0.10.in-addr.arpa.dns;

- отмечаю Allow both nonsecure and secure dynamic updates (после установки Active Directory поменяю на "только безопасные" );

В DNS от Reverse Lookup Zones пошла ветка 10.0.0.х Subnet - правой кнопкой мыши в меню выбираю New Pointer(PTR):

в окошке New Resource Record - в поле Host IP_number указываю 1 (отображается 10.0.0.1)

Далее в командной строке даю ipconfig/registerdns

В DNS в меню Action щелкаю Refresh.

что-то не получается.

создаю зону заново, указываю 3 октета

в результате в DNS появляется такая картинка:

Reverse Lookup Zones:

В меню view консоли DNS поставьте галку "advansed" - получится то, что от вас хотят

Имхо, вы говорите об одном и том же. Просто у одного включена галка "advansed" в меню view консоли DNS, а у другого - нет

Галку включила. Да, теперь мы пришли к одному виду.

Тогда в чем может быть засада?

Reverse Lookup Zones - New Zone - Мастер установки:

- выбираю Primary zone;

- указываю номер зоны (н-р, 10.0.0)

- на следующей странице в поле Create a new file with this file name отбражается 0.0.10.in-addr.arpa.dns;

- отмечаю Allow both nonsecure and secure dynamic updates (после установки Active Directory поменяю на "только безопасные" );

В DNS от Reverse Lookup Zones пошла ветка 10.0.0.х Subnet - правой кнопкой мыши в меню выбираю New Pointer(PTR):

в окошке New Resource Record - в поле Host IP_number указываю 1 (отображается 10.0.0.1)

Я наткнулся на странное поведение с машинами Windows, которое, по-видимому, вполне соответствует всем версиям Windows от Vista / 2008 до 8.1 / 2012 R2; это не происходит вместо этого при использовании Windows XP или Windows Server 2003.

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

Еще несколько деталей:

И нет, настройка DHCP-сервера для регистрации DNS здесь не вариант.

Друг не из SF сказал: «Это нормально, PTR обновляется только через DHCP в Win2K +». Судя по вашему опыту, это не совсем так, но может быть близко . Я пытаюсь найти лучшую ссылку. Массимо, ты можешь проверить трассировку проволочной акулы и проверить пакет DHCPREQUEST? Должен быть установлен флаг в «1», если клиент должен обновить и запись A, и запись PTR. Флаг «0» означает, что клиент обновляет запись A и запрашивает, чтобы сервер обновил запись PTR от своего имени. По умолчанию "0". Также в области DHCP убедитесь, что == Перейдите на вкладку DNS, нажмите Свойства, а затем нажмите, чтобы выбрать Динамически обновлять записи DNS A и PTR, только если запрошен клиентами DHCP, установлен флажок ==. Это будет означать, что когда на сервере появляется флаг по умолчанию «0», он попытается зарегистрировать запись PTR на DNS-сервере (ах), для которого настроено обновление. И убедитесь, что учетные данные динамического обновления DNS правильные и для этого применяются соответствующие разрешения У меня такая же проблема. Использование pfSense в качестве DHCP-сервера. Win2k8 DC / DNS. Win7 клиенты. Клиенты регистрируют записи A, но не записи PTR.

Решение заключается в проверке Use this connection's DNS suffix in DNS registration в настройках TCP / IP сетевого интерфейса:

Как ни странно, это единственное решение, гарантирующее, что Windows зарегистрирует записи A и PTR для сетевого подключения DHCP; в противном случае он зарегистрирует только запись А.

Я просто столкнулся с этим снова сам, мне кажется, что это ошибка. Было бы хорошо, если бы MS исправил.

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

Computer Configuration\Administrative Templates\Network\DNS Client

Интересный. Я уже пытался «Зарегистрировать записи PTR», но безрезультатно, но «Зарегистрировать записи DNS с DNS-суффиксом для конкретного подключения» могло бы сработать, потому что это действительно происходит при ручном включении этой опции в свойствах сетевого подключения (см. Принятый ответ). ). @Massimo, да, это соответствует тому, что я видел. Мне нужен был способ для этого, поэтому я продолжал играть с политикой, пока она не сработала.

Windows 2000 .. отправляет параметр 81 и его полное доменное имя на сервер DHCP и просит сервер DHCP зарегистрировать запись ресурса указателя (PTR RR) от своего имени. Клиент динамического обновления регистрирует запись ресурса адреса (A RR). .. DHCP-сервер может быть настроен на указание клиенту разрешить серверу регистрировать обе записи в DNS.

Статически настроенные (не DHCP) клиенты регистрируют как A RR, так и PTR RR на DNS-сервере.

В статье также упоминается, Changing registry entries changes the behavior of the dynamic update DNS client. так что может быть обходной путь реестра . Поиск

Изменить:
Согласно статье, на которую ссылается TheCleaner ниже, объект групповой политики, о котором я упоминал в своем комментарии, не будет делать то, что вы хотите (да, MS и программное обеспечение с закрытым исходным кодом). Но флажки «Зарегистрировать адрес этого подключения в DNS» и «Использовать DNS-суффикс этого подключения в регистрации DNS» работают. У меня нет удобной тестовой среды, чтобы попробовать это .

Мой почтовый сервер настроен с помощью постфикса, у меня есть соответствующие записи A / AAAA и т. Д., Включая запись PTR с моего IPv4 -> yourbud.co.za (мой домен).

MXToolBox показывает Reverse DNS does not match SMTP Banner . Причина в том, что ответ HELO / EHLO не содержит domain.tld внутри строки. Оно делает.

Требования к SMTP-серверу

Настройка Postfix (все настройки dkim, dmarc, spf тоже)
Записи A / AAAA, указывающие адреса yourbud.co.za -> ipv4 / 6
Запись PTR указывает на ipv4 (и ipv6 необязательно?) -> yourbud.co.za

Здесь вы можете найти диагностику MXToolBox MX для моего домена. Далее dmarc, dkim & spf все отчеты проходят.

Корневая проблема (мне нужно решить)

Outlook и GMail помечают мои электронные письма как нежелательные.

Больше информации:

Согласно this, and this, this, this (и некоторым другим) все предполагает, что несоответствие баннера заставит почтовые провайдеры (Outlook, GMail и т. Д.) Пометить электронные письма как спам / нежелательную почту, что и происходит.

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

Почему Outlook / GMail по-прежнему считает мою почту спамом / нежелательной почтой?

Ваша настройка, вероятно, в порядке

И IPv4, и IPv6 имеют совпадающие прямые и обратные записи:

Баннеры SMTP в IPv4 и IPv6 соответствуют этим записям:

Главное - содержание

Сьюзан Гунелиус (Cannabiz Media): Проблемы с почтовым маркетингом для предприятий, занимающихся марихуаной:

Microsoft, Gmail и т. Д., Будучи американскими компаниями, тоже подпадают под этот вывод.

MXToolBox показывает Reverse DNS does not match SMTP Banner . Причина в том, что ответ HELO / EHLO не содержит domain.tld внутри строки. Оно делает.

Ваш вывод MXToolBox показывает SMTP Banner Check: OK - Reverse DNS matches SMTP Banner , и вы правы, что ваши ответы EHLO используют ваше действительное имя хоста. Скорее, предупреждение от MXToolBox SMTP Valid Hostname: Reverse DNS is not a valid Hostname . Я не могу понять, почему он так говорит; ваши записи A, AAAA и PTR в порядке.

Что касается успешной доставки исходящий mail для вашего домена, переменная Postfix, о которой вам действительно нужно беспокоиться, не myhostname (который используется, когда другой сервер обращается к вашему серверу для доставки входящей почты для вашего домена), но smtp_helo_name (который используется, когда ваш сервер подключается к другому серверу для доставки исходящей почты из вашего домена). Однако, smtp_helo_name установлен на $myhostname по умолчанию, так что вы, вероятно, уже правильно его установили.

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

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