Почему dig отвечает SERVFAIL, а nslookup разрешает нормально на локальной зоне powerdns?

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

Я немного нов в локальном DNS, поэтому хочу использовать 1 узел с IP 192.168.100.11 и auth + recursor + dnsdist на одном хосте. Auth-сервер должен разрешать только локальную зону (holodev.local в моем случае), recursor должен разрешать все, что не локально, и перенаправлять это на публичные DNS-сервера. Я настроил зону .local через PowerAdmin и добавил обратную зону 100.168.192.in-addr.arpa, которая содержит SOA-запись и PTR для моего nextcloud ‘98.100.168.192.in-addr.arpa PTR nextcloud.holodev.local‘. Основная зона содержит записи ns1 и ns2 (я не уверен в использовании ns2 на одном узле), SOA и A для nextcloud. У меня есть следующие конфигурации:

pdns.conf

[root@dns ~]# sed '/^\s*#/d;/^\s*$/d' /etc/pdns/pdns.conf 
dnsupdate=yes
launch=gmysql 
gmysql-host=localhost 
gmysql-user=pda 
gmysql-password=dnsdbpas1
gmysql-dbname=pda
local-address=127.0.0.1
local-port=5300
log-dns-queries=yes
security-poll-suffix=
setgid=pdns
setuid=pdns

конфигурация recursor

[root@dns ~]# sed '/^\s*#/d;/^\s*$/d' /etc/pdns-recursor/recursor.conf 
disable-syslog=no
forward-zones=holodev.local=127.0.0.1:5300
forward-zones-recurse=.=8.8.8.8
local-address=127.0.0.1
local-port=5301
logging-facility=1
loglevel=6
quiet=no
security-poll-suffix=
setgid=pdns-recursor
setuid=pdns-recursor

конфигурация dnsdist

[root@dns ~]# sed '/^\s*--/d;/^\s*$/d' /etc/dnsdist/dnsdist.conf 
setSecurityPollSuffix("")
setLocal('192.168.100.11')
addLocal('127.0.0.1')
newServer({address="127.0.0.1:5301", name="recursor"})
newServer({address="127.0.0.1:5300", name="authoritive", pool={"auth"}})
setServerPolicy(firstAvailable)
pc = newPacketCache(10000, {maxTTL=86400, minTTL=0, temporaryFailureTTL=60, staleTTL=60, dontAge=false})
getPool(""):setCache(pc)
addAction(NotRule(OrRule({makeRule("192.168.0.0/16"), makeRule("127.0.0.1")})), DropAction())

Вывод Dig (я использую CT под тем же гипервизором, но IP другой и только 1 DNS сервер в resolve.conf). И мне интересно, что внешние зоны работают нормально

[root@zabbix ~]# dig holodev.local @192.168.100.11

; <<>> DiG 9.16.23-RH <<>> holodev.local @192.168.100.11
;; глобальные опции: +cmd
;; Получен ответ:
;; ПРЕДУПРЕЖДЕНИЕ: .local зарезервирован для Multicast DNS
;; Вы в настоящее время тестируете, что происходит, когда запрос mDNS утечет в DNS
;; ->>ЗАГОЛОВОК<<- opcode: QUERY, статус: SERVFAIL, id: 7871
;; флаги: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

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

;; Время запроса: 0 мс
;; СЕРВЕР: 192.168.100.11#53(192.168.100.11)
;; КОГДА: Сб Окт 26 02:43:05 UTC 2024
;; РАЗМЕР MSG  получен: 42

----------------------------

[root@zabbix ~]# dig google.com @192.168.100.11

; <<>> DiG 9.16.23-RH <<>> google.com @192.168.100.11
;; глобальные опции: +cmd
;; Получен ответ:
;; ->>ЗАГОЛОВОК<<- opcode: QUERY, статус: NOERROR, id: 12312
;; флаги: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

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

;; СЕКЦИЯ ОТВЕТА:
google.com.             57      IN      A       142.250.203.206

;; Время запроса: 75 мс
;; СЕРВЕР: 192.168.100.11#53(192.168.100.11)
;; КОГДА: Сб Окт 26 02:53:12 UTC 2024
;; РАЗМЕР MSG  получен: 55

nslookup

[root@zabbix ~]# nslookup nextcloud.holodev.local 192.168.100.11
Сервер:         192.168.100.11
Адрес:        192.168.100.11#53

Неавторитетный ответ:
Имя:   nextcloud.holodev.local
Адрес: 192.168.100.98

Что я не понимаю и что вызывает статус: SERVFAIL? Я также могу использовать curl и ping для домена.

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

Почему dig возвращает SERVFAIL, в то время как nslookup работает нормально на локальной зоне PowerDNS?

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

1. Возможные проблемы с .local зонами

Согласно документации, доменное имя с окончанием .local зарезервировано для Multicast DNS (mDNS). Это может привести к тому, что инструменты, такие как dig, будут пытаться разрешать такие запросы не через обычные DNS-серверы, а через протокол mDNS, что может вызывать сложности. Таким образом, dig мог интерпретировать ваш запрос неправильно, учитывая специфику именования.

2. Конфигурация DNS-сервера

Также важно обратить внимание на вашу конфигурацию PowerDNS:

  • Auth сервер (powerdns) настроен на использование базы данных, и в нем указаны зоны и записи, такие как SOA и A. Убедитесь, что записи в базе данных корректны и что они доступны для запроса.
  • В файле конфигурации recursor (PowerDNS Recursor) указано, что локальная зона (holodev.local) перенаправляется на авторитетный сервер на localhost (127.0.0.1:5300). Это также должно быть корректно настроено, чтобы обеспечить нормальную работу.
  • Важно убедиться, что функционал dnsdist правильно маршрутизирует запросы между рекурсивным и авторитетным серверами.

3. Параметры запроса и DNS-кэш

Различия в ответах dig и nslookup могут также происходить в результате вспомогательных параметров, которые по умолчанию включены в одном из инструментов. Например:

  • nslookup может использовать кэшированные результаты, что позволяет ему успешно разрешать домены, в то время как dig, отправляя свежий запрос, может натолкнуться на проблему.

Чтобы устранить потенциальные конфликты с кэшем, можно попробовать использовать опцию +trace в dig, чтобы отслеживать, где именно происходит сбой.

4. Проверка локальной зоны

Не забудьте проверить корректность записи PTR для вашего устройства через инверсный DNS-запрос:

dig -x 192.168.100.98 @192.168.100.11

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

5. Забытые записи или конфликты

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

Рекомендации и действия

  1. Проверить конфигурацию зоны: Убедитесь, что все записи DNS для holodev.local корректные и присутствуют в базе данных.

  2. Изменить окончание доменного имени: Используйте альтернативное окончание, например .dev, если это возможно.

  3. Очистка кэша DNS: Попробуйте очистить кэш вашего DNS и повторно выполнить запрос.

  4. Используйте опцию +trace: Воспользуйтесь dig +trace для детального анализа выполнения DNS-запроса.

  5. Логирование: Проверьте логи PowerDNS, чтобы выявить возможные ошибки на стороне сервера.

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

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

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