Рекурсия недоступна, но всё равно даёт ответ.

Содержание

Вопрос или проблема
Ответ или решение
Теория
Пример
Применение

Вопрос или проблема

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

Например:

[root@dhcppc14 vwxyz]# dig muse.mu @202.159.36.218

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.30.rc1.el6_6.3 <<>> muse.mu @202.159.36.218
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46239
;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
**;; WARNING: recursion requested but not available**

;; QUESTION SECTION:

;muse.mu. IN A

;; ANSWER SECTION:

**muse.mu. 3600 IN A 162.249.109.50**

;; Query time: 253 msec
;; SERVER: 202.159.36.218#53(202.159.36.218)
;; WHEN: Sat Jun 27 05:58:14 2015
;; MSG SIZE rcvd: 41

Можете объяснить, что именно произошло?

Спасибо,

Я не уверен, должен ли 202.159.36.218 быть авторитативным сервером имен для muse.mu или какое он имеет отношение к этому. Из-за этого я не могу объяснить, почему 202.159.36.218 отвечает за muse.mu без рекурсии.

Предупреждение, которое вы видите, печатается из dig, когда он отправляет запрос с RD (требуется рекурсия) и получает ответ без RA (доступность рекурсии).

dig по умолчанию отправляет рекурсивные запросы (тип сообщения RD, “рекурсия требуется”).

Из страницы руководства dig:

+[no]recurse

Переключает установку бита RD (требуется рекурсия) в запросе. Этот бит установлен по умолчанию, что означает, что dig обычно отправляет рекурсивные запросы. Рекурсия автоматически отключается, когда используются параметры запроса +nssearch или +trace.

Из RFC 883:

Сервер имен, который поддерживает рекурсивный сервис, устанавливает бит Recursion Available (RA) во всех ответах, которые он генерирует. Запрашивающий может запросить рекурсивный сервис, установив бит Recursion Desired (RD) в запросах. В некоторых ситуациях, когда рекурсивный сервис является единственным путем к желаемой информации (см. ниже), сервер имен может идти по рекурсии, даже если RD ноль.

Предупреждение будет появляться всякий раз, когда вы выполняете запрос к авторитетному серверу имен, где рекурсия не разрешена без указания, что запрос должен быть нерекурсивным (опция +norecurse).

Попробуйте

dig +trace @202.159.36.218 muse.mu

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

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

Ответ или решение

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

Теория

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

Когда вы используете команду dig, она по умолчанию отправляет рекурсивный запрос. Это означает, что dig запрашивает сервер о разрешении имени и полагается на то, что сервер при необходимости сам выполнит другие действия для получения ответа. Если сервер способен выполнять рекурсивные запросы, в его ответах будет установлен флаг RA (Recursion Available).

Пример

В вашем случае, вы отправили запрос к DNS-серверу по адресу 202.159.36.218 для домена muse.mu. Результат, который вы получили, выглядит следующим образом:

Вы получили ответ, несмотря на предупреждение о том, что рекурсия недоступна (**WARNING: recursion requested but not available**).
В ответе содержится информация о A-записи для домена muse.mu, указывающая IP-адрес 162.249.109.50.

Возможные объяснения этого явления включают:

Авторитативные полномочия: Сервер 202.159.36.218 может быть авторитативным для домена muse.mu. В этом случае сервер имеет право предоставить конечный ответ, и рекурсия ему не нужна.
Локальный кэш: Сервер может иметь закэшированный ответ на подобный запрос. Многие DNS-серверы сохраняют закэшированные ответы на запросы, которые они ранее выполняли. Это позволяет ускорить обработку запросов и уменьшить нагрузку на DNS-систему.
Форвардинг: Сервер может использовать форвардинг — механизм, при котором он пересылает запросы к другому серверу, который имеет необходимые полномочия для ответа. Однако форвардинг обычно используется в рекурсивных конфигурациях.

Применение

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

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

В данном случае целесообразно провести дополнительные проверки, чтобы определить, является ли сервер 202.159.36.218 действительно авторитативным для muse.mu. Это можно сделать, например, с помощью команды dig +trace, которая позволяет вам отследить весь путь разрешения, начиная с корневых серверов и заканчивая конечным авторитативным сервером. Это поможет подтвердить или опровергнуть гипотезу о наличии авторитативного ответа от данного сервера.

Детальное понимание таких механизмов поможет вам эффективно управлять инфраструктурой DNS и своевременно выявлять нестандартные или неожиданные ситуации.