Почему unbound DNS не смог выполнить запрос на домен?

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

Это последующий вопрос к моему предыдущему вопросу. Ниже представлен файл /etc/unbound/unbound.conf:

# unbound.conf(5) файл конфигурации для unbound(8).
server:
    directory: "/etc/unbound"
    username: "unbound"
    chroot: ""
    logfile: "/etc/unbound/unbound.log"
    pidfile: "/etc/unbound/unbound.pid"
    verbosity: 1
    # слушать на всех интерфейсах и отвечать на запросы с локального порта 3000.
    interface: 0.0.0.0 
    interface: ::0
    port: 3000
    access-control: 10.0.0.0/8 allow
    #access-control: 2001:DB8::/64 allow

С запущенной unbound.service я попытался сделать dig домен через локальный сервер unbound:

root@DNS:/etc/unbound# dig example.com A @192.168.1.50 -p 3000

; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> example.com A @192.168.1.50 -p 3000
;; глобальные параметры: +cmd
;; Получен ответ:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 8367
;; флаги: qr rd ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; ПРЕДУПРЕЖДЕНИЕ: рекурсия запрашивалась, но недоступна

;; Время запроса: 0 мсек
;; СЕРВЕР: 192.168.1.50#3000(192.168.1.50) (UDP)
;; КОГДА: Вс Окт 29 16:18:19 UTC 2024
;; РАЗМЕР СООБЩЕНИЯ rcvd: 12

Я не понимаю, почему ПРЕДУПРЕЖДЕНИЕ: рекурсия запрашивалась, но недоступна, так как unbound настроен по умолчанию как рекурсивный резолвер. Также СЕРВЕР: 192.168.1.50#3000(192.168.1.50) (UDP) показывает, что использовался unbound, однако он не смог получить домен. Что не так и как я могу исправить эту проблему?

Ниже показан ответ через systemd-resolved.service stub-сервер:

root@DNS:/etc/unbound# dig example.com

; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> example.com
;; глобальные параметры: +cmd
;; Получен ответ:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36356
;; флаги: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: версия: 0, флаги:; udp: 65494
;; СЕКЦИЯ ВОПРОСА:
;example.com.           IN  A

;; СЕКЦИЯ ОТВЕТА:
example.com.        3304    IN  A   93.184.215.14

;; Время запроса: 12 мсек
;; СЕРВЕР: 127.0.0.53#53(127.0.0.53) (UDP)
;; КОГДА: Вс Окт 29 16:43:59 UTC 2024
;; РАЗМЕР СООБЩЕНИЯ rcvd: 56

Обновление:

После исправления подсети, как упомянуто в ответе @mpboden, команда dig сработала только один раз. Почему это так?

root@DNS:/etc/unbound/unbound.conf.d# systemctl start unbound.service
root@DNS:/etc/unbound/unbound.conf.d# [1730230920] unbound[5780:0] уведомление: инициализация модуля 0: subnetcache
[1730230920] unbound[5780:0] уведомление: инициализация модуля 1: validator
[1730230920] unbound[5780:0] уведомление: инициализация модуля 2: iterator
[1730230921] unbound[5780:0] информация: начало службы (unbound 1.19.2).

root@DNS:/etc/unbound/unbound.conf.d# dig example.com A @192.168.1.50 -p 3000

; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> example.com A @192.168.1.50 -p 3000
;; глобальные параметры: +cmd
;; Получен ответ:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40273
;; флаги: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: версия: 0, флаги:; udp: 1232
;; СЕКЦИЯ ВОПРОСА:
;example.com.           IN  A

;; СЕКЦИЯ ОТВЕТА:
example.com.        3600    IN  A   93.184.215.14

;; Время запроса: 712 мсек
;; СЕРВЕР: 192.168.1.50#3000(192.168.1.50) (UDP)
;; КОГДА: Вс Окт 29 19:42:34 UTC 2024
;; РАЗМЕР СООБЩЕНИЯ rcvd: 56

root@DNS:/etc/unbound/unbound.conf.d# dig google.com A @192.168.1.50 -p 3000

; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> google.com A @192.168.1.50 -p 3000
;; глобальные параметры: +cmd
;; Получен ответ:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 49774
;; флаги: qr rd ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; ПРЕДУПРЕЖДЕНИЕ: рекурсия запрашивалась, но недоступна

;; Время запроса: 0 мсек
;; СЕРВЕР: 192.168.1.50#3000(192.168.1.50) (UDP)
;; КОГДА: Вс Окт 29 19:42:56 UTC 2024
;; РАЗМЕР СООБЩЕНИЯ rcvd: 12


root@DNS:/etc/unbound/unbound.conf.d# dig example.com A @192.168.1.50 -p 3000

; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> example.com A @192.168.1.50 -p 3000
;; глобальные параметры: +cmd
;; Получен ответ:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 46236
;; флаги: qr rd ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; ПРЕДУПРЕЖДЕНИЕ: рекурсия запрашивалась, но недоступна

;; Время запроса: 0 мсек
;; СЕРВЕР: 192.168.1.50#3000(192.168.1.50) (UDP)
;; КОГДА: Вс Окт 29 19:43:36 UTC 2024
;; РАЗМЕР СООБЩЕНИЯ rcvd: 12

Я вижу, что вы определили следующее:

access-control: 10.0.0.0/8 allow

Но ваша подсеть 192.168.1.0/24. Измените эту строку на:

access-control: 192.168.1.0/24 allow

Это позволит unbound принимать DNS-запросы из сети 192.168.1.0/24.

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

Почему Unbound DNS не смог выполнить запрос DNS для домена?

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

WARNING: recursion requested but not available

Давайте разберемся, что означает данная ошибка и как ее исправить.

Причины ошибки

  1. Настройки контроля доступа:
    В вашей конфигурации использовалась следующая строка в файле /etc/unbound/unbound.conf:

    access-control: 10.0.0.0/8 allow

    Ваша сеть имеет адрес в диапазоне 192.168.1.0/24, что является частным адресным пространством, не соответствующим настройке, указанной выше. В результате Unbound отвергал запросы от локальных клиентов, что и приводило к сообщению о том, что рециркуляция (recursion) невозможна.

    Решение: Измените строку контроля доступа:

    access-control: 192.168.1.0/24 allow

    Это позволит Unbound принимать DNS-запросы из вашей локальной сети.

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

Стек вызовов и ответ на запросы

Когда вы выполняете команду dig на локальной машине:

dig example.com A @192.168.1.50 -p 3000

Unbound реагирует на запрос, отправляя ответ с заголовком:

;; flags: qr rd ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

Это свидетельствует о том, что запрос не обработан (статус REFUSED), как и показано в ваших тестах.

Что изменилось после обновления конфигурации?

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

  1. Кэширование:
    У Unbound есть механизмы кэширования. Если запрос к домену example.com успешно прошел апдейт, он был закэширован. При следующем запросе он не смог обработать другой домен (google.com), вернув сообщение о невозможности рекурсивного разрешения.

  2. Загрузка Unbound:
    Если Unbound был нагружен после первого успешного запроса, это также могло повлиять на его способность реагировать на дополнительные запросы. Важно отслеживать логи (/etc/unbound/unbound.log) для выявления возможных ошибок или предупреждений, которые указывают на проблемы.

Рекомендации по устранению проблемы

  • Убедитесь, что указаны все необходимые настройки доступа.
  • Отслеживайте логи Unbound для понимания причин отказов.
  • Проверьте, не перегружен ли Unbound в моменты ваших запросов.

Эти шаги помогут вам стабилизировать работу Unbound и сделать DNS-запросы к нему более надежными.

Оцените материал
Добавить комментарий

Капча загружается...