Ошибка рекурсивного запроса dns

Обновлено: 26.01.2025

Хотите улучшить этот вопрос? Обновите вопрос, чтобы он подходил для Unix и Linux Stack Exchange.

Закрыто 8 лет назад .

Может кто-нибудь объяснить вкратце, что означает «рекурсивный DNS-запрос» и как его можно считать плохим ?

Я знал, кто написал это только из названия. Я не знаю, почему вы продолжаете публиковать здесь материалы по DNS, но это совсем не относится к Unix / Linux. Лично я думаю, что это достойный вопрос, но здесь он не по теме, и я не думаю, что у нас есть другой сайт в сети, который этого хочет Это действительно оффтоп здесь? Учитывая, что 90% мировых DNS-серверов работают на Unix / Linux? Возможно, вопрос можно было бы перефразировать: «Как я могу настроить свой DNS-сервер для ответа на рекурсивные запросы и почему я должен избегать этого?» но действительно ли это "оффтоп"? Просто любопытно.

TL; DR : рекурсивные запросы являются частью работы Интернета и DNS, но не все DNS-серверы должны получать рекурсивные запросы, и когда те, которые не отвечают, отвечают, у вас могут возникнуть проблемы.

Более длинная версия:

Рекурсия, см .: Смотрите в разделе Рекурсия.

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

Браузер: Конечно! . Хм. Я на самом деле не знаю, что это за IP-адрес.

Хм. Это не в моем собственном файле hosts. Дай мне просто проверить конфигурацию моего резольвера .

DNS-сервер интернет-провайдера: Конечно!

. хммм Этого нет в моем списке авторитетных доменов, и сейчас у меня нет этого ответа в кеше.

DNS-сервер интернет-провайдера: Спасибо, интернет-серверы!

DNS-сервер провайдера : Отлично, спасибо!

OS, номер, который вы ищете, 64.34.119.12.

ОПЕРАЦИОННЫЕ СИСТЕМЫ: Отлично, спасибо!

Браузер, вам нужен адрес 64.34.119.12

Браузер: Отлично, спасибо!

Ладно, сейчас захожу на страницу.

Вы: Yay, спасибо Браузер!

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

Причина. На активность DNS-сервера влияет неполадка в сети.

Решение. Убедитесь, что сервер имеет допустимое и работающее сетевое подключение. Сначала убедитесь, что соответствующее клиентское оборудование (кабели и сетевые платы) исправно, используя основные шаги решения вопросов, связанных с сетью или оборудованием.

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

Причина. С DNS-сервером можно связаться путем обычных сетевых проверок, но он не отвечает на DNS-запросы клиентов.

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

Дополнительные сведения см. в разделе Запуск и остановка DNS-сервера.

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

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

Причина. На DNS-сервере было отключено использование автоматически созданных зон обратного просмотра по умолчанию.

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

По умолчанию DNS-серверы автоматически создают три стандартных зоны обратного просмотра в соответствии с рекомендациями документов RFC.

Эти зоны создаются с использованием обычных IP-адресов, которые не используются при обратном просмотре (0.0.0.0, 127.0.0.1 и 255.255.255.255). Являясь полномочной службой DNS для зон, соответствующих этим адресам, служба DNS избегает ненужной рекурсии на корневые серверы для выполнения обратного просмотр в этих типах IP-адресов.

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

Чтобы убедиться, что эти зоны были созданы, выполните следующие действия:

Местонахождение

необходимый DNS-сервер

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

Решение. Убедитесь, что DNS-сервер не использует нестандартную конфигурацию.

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

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

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

DNS-сервер неправильно разрешает имена.

Причина. DNS-сервер предоставляет неверные данные в успешных ответах на запросы.

Решение. Определите причину появления неверных данных на DNS-сервере.

Ниже перечислены наиболее вероятные причины:

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

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

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

Дополнительные сведения см. в разделе Устранение неполадок DNS-клиентов.

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

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

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

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

Причина. DNS-сервер настроен для использования других DNS-серверов, способствующих разрешению запросов.

Решение. Проверьте, может ли DNS-сервер использовать как серверы пересылки, так и рекурсию.

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

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

Причина. Текущие корневые ссылки для DNS-сервера недопустимы.

Решение. Проверьте допустимость корневых ссылок сервера.

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

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

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

Причина. DNS-сервер не имеет сетевого подключения к корневым серверам.

Решение. Проверьте сетевое подключение к корневым серверам.

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

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

Более вероятной причиной является потеря сетевого подключения или, в некоторых случаях, низкая сетевая производительность промежуточной сетевой инфраструктуры между DNS-сервером и его настроенными корневыми серверами. Придерживайтесь стандартных шагов по разрешению вопросов, связанных с сетевыми протоколами TCP/IP для проверки подключений и определения причин неполадок.

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

Чтобы просмотреть дополнительные сведения, относящиеся к производительности DNS-запросов, можно включить и использовать файл журнала отладки DNS-сервера, который называется Dns.log. Этот журнал содержит подробные сведения о некоторых типах событий, относящихся к службе.

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

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

Ответы

Все ответы

Настройка протокола IP для Windows

Ethernet adapter Подключение по локальной сети:

DNS-суффикс подключения . . . . . :
Описание. . . . . . . . . . . . . : Intel(R) I210 Gigabit Network Connection
Физический адрес. . . . . . . . . : 10-C3-7B-44-E6-6A
DHCP включен. . . . . . . . . . . : Нет
Автонастройка включена. . . . . . : Да
Локальный IPv6-адрес канала . . . : fe80::a82d:432f:f8cf:445b%10(Основной)
IPv4-адрес. . . . . . . . . . . . : 192.168.18.252(Основной)
Маска подсети . . . . . . . . . . : 255.255.255.0
Основной шлюз. . . . . . . . . : 192.168.18.1
IAID DHCPv6 . . . . . . . . . . . : 235979643
DUID клиента DHCPv6 . . . . . . . : 00-01-00-01-1B-76-7D-FE-10-C3-7B-44-E6-6A

DNS-серверы. . . . . . . . . . . : 192.168.18.252
192.168.18.253
NetBios через TCP/IP. . . . . . . . : Включен

Ethernet adapter Hamachi:

DNS-серверы. . . . . . . . . . . : fec0:0:0:ffff::1%1
fec0:0:0:ffff::2%1
fec0:0:0:ffff::3%1
NetBios через TCP/IP. . . . . . . . : Включен

Состояние среды. . . . . . . . : Среда передачи недоступна.
DNS-суффикс подключения . . . . . :
Описание. . . . . . . . . . . . . : Адаптер Microsoft ISATAP
Физический адрес. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP включен. . . . . . . . . . . : Нет
Автонастройка включена. . . . . . : Да

Туннельный адаптер Teredo Tunneling Pseudo-Interface:

Состояние среды. . . . . . . . : Среда передачи недоступна.
DNS-суффикс подключения . . . . . :
Описание. . . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface
Физический адрес. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP включен. . . . . . . . . . . : Нет
Автонастройка включена. . . . . . : Да

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

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

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

Сервер проверки: Default-First-Site-Name\MAIN-SERVER
Запуск проверки: Connectivity
. MAIN-SERVER - пройдена проверка Connectivity

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

Сервер проверки: Default-First-Site-Name\MAIN-SERVER

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

Выполнение проверок разделов на: ForestDnsZones

Выполнение проверок разделов на: DomainDnsZones

Выполнение проверок разделов на: Schema

Выполнение проверок разделов на: Configuration

Выполнение проверок разделов на: biscom

TEST: Basic (Basc)
Warning: The AAAA record for this DC was not found

MAIN-SERVER PASS WARN PASS PASS PASS WARN n/a
. biscom.local - пройдена проверка DNS

Настройка протокола IP для Windows

Ethernet adapter Подключение по локальной сети:

DNS-суффикс подключения . . . . . :
Описание. . . . . . . . . . . . . : Сетевое подключение Intel(R) 82567V-2 Gig
abit
Физический адрес. . . . . . . . . : 00-27-0E-01-36-BC
DHCP включен. . . . . . . . . . . : Нет
Автонастройка включена. . . . . . : Да
Локальный IPv6-адрес канала . . . : fe80::a8b7:1ec5:e229:6dbb%10(Основной)
IPv4-адрес. . . . . . . . . . . . : 192.168.18.253(Основной)
Маска подсети . . . . . . . . . . : 255.255.255.0
Основной шлюз. . . . . . . . . : 192.168.18.1
IAID DHCPv6 . . . . . . . . . . . : 234891022
DUID клиента DHCPv6 . . . . . . . : 00-01-00-01-1B-B3-0E-C4-00-27-0E-01-36-BC

DNS-серверы. . . . . . . . . . . : 192.168.18.252
127.0.0.1
NetBios через TCP/IP. . . . . . . . : Включен

Туннельный адаптер Teredo Tunneling Pseudo-Interface:

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

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

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

Сервер проверки: Default-First-Site-Name\RES-SERVER
Запуск проверки: Connectivity
. RES-SERVER - пройдена проверка Connectivity

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

Сервер проверки: Default-First-Site-Name\RES-SERVER

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

Выполнение проверок разделов на: ForestDnsZones

Выполнение проверок разделов на: DomainDnsZones

Выполнение проверок разделов на: Schema

Выполнение проверок разделов на: Configuration

Выполнение проверок разделов на: biscom

В итоге получается так что часть сайтов открывается, а часть нет, может кто-то сталкивался с таким поведением и подскажет куда рыть. Конфиги почти все default.

Не знаю, что у вас там происходит, но я бы запустил tcpdump, чтобы посмотреть, какие запросы на самом деле приходят от клиента. Я не знаю механизмов DNS, чтобы с помощю них браузер поменял отображаемый URL. Существует NAPTR, но ведь браузер его не использует.

Смотри кто добавляет этот суффикс.
Можешь начать с простого sudo grep -r -l DefaultSearchDomain /etc 2>/dev/null

К сожалению давно уже попробовал поискать и единственное возможное совпадение найдено как раз в /etc/resolv.conf search DefaultSearchDomain

Пока на клиенте сменил search на другое имя домена и проблемы не замечаю. Буду наблюдать, возможно проблема как раз возникает если домен для поиска по умолчанию на клиенте и сервере совпадают, после чего в кэше идет корозия, но меня смущает в этом случае другое, почти такие же конфиги только на OS FreeBSD работают как часы. Возможно в CentOS имеется какой-то небольшой баг который творит такие вещи.

Баг - это ты. RTFM

/etc/resolv.conf search DefaultSearchDomain

Пересмотри своё мировоззрение, почитал твои посты, больше не куда выплескивать свой негатив?

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

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

Только что закончил разбираться с

Думаешь гугл не осилил? не ты мочишь. segfault всегда был выход за пределы памяти, значит или какое-то значение лезет за свои границы или другая проблема, но в любом случае выход за пределы, нехер пытатся в int сунуть long int и т.д. ловится через gdb и прочие вещи. Нагруженный, опять же, в зависимости от ситуации если на этапе старта проблема, то синкаем через dd на удаленную машину и разбираемся, вариаций немерено.

Твоя попытка втолкнуть гугл бессмысленна, имя defaultdomain и defaultsearchdomain должны дописываться в том случае если отсутствуют корневые домены в запросе, но в моем примере они описаны, не осилил прочитать лог или resolv.conf и понять для каких это ситуаций применяется? бяда. Еще раз, меняй своё мировозрение, если ты так крут то какого хера ты в обще тут делаешь.

должны дописываться в том случае если отсутствуют корневые домены в запросе

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

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

найдено как раз в /etc/resolv.conf search DefaultSearchDomain

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

Жалость то какая. Слуш, а можешь посоветовать, что лучше под линь - nvidia или ati ?

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

Ты бы resolv.conf и host.conf с этого клиента привел. Как вариант там search+domain+trim каким-нибудь хитрым хором собрались.

hosts.conf такого в системе нету.

/etc/resolv.conf он генерится из /etc/network/interface

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

суфикс дописывается при определенных условиях

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

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