Вопрос или проблема
Это последующий вопрос к моему предыдущему вопросу. Ниже представлен файл /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
Давайте разберемся, что означает данная ошибка и как ее исправить.
Причины ошибки
-
Настройки контроля доступа:
В вашей конфигурации использовалась следующая строка в файле/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-запросы из вашей локальной сети.
-
Режим работы 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. Это могло быть вызвано рядом причин:
-
Кэширование:
У Unbound есть механизмы кэширования. Если запрос к доменуexample.com
успешно прошел апдейт, он был закэширован. При следующем запросе он не смог обработать другой домен (google.com
), вернув сообщение о невозможности рекурсивного разрешения. -
Загрузка Unbound:
Если Unbound был нагружен после первого успешного запроса, это также могло повлиять на его способность реагировать на дополнительные запросы. Важно отслеживать логи (/etc/unbound/unbound.log
) для выявления возможных ошибок или предупреждений, которые указывают на проблемы.
Рекомендации по устранению проблемы
- Убедитесь, что указаны все необходимые настройки доступа.
- Отслеживайте логи Unbound для понимания причин отказов.
- Проверьте, не перегружен ли Unbound в моменты ваших запросов.
Эти шаги помогут вам стабилизировать работу Unbound и сделать DNS-запросы к нему более надежными.