- Вопрос или проблема
- Ответ или решение
- Почему dig возвращает SERVFAIL, в то время как nslookup работает нормально на локальной зоне PowerDNS?
- 1. Возможные проблемы с .local зонами
- 2. Конфигурация DNS-сервера
- 3. Параметры запроса и DNS-кэш
- 4. Проверка локальной зоны
- 5. Забытые записи или конфликты
- Рекомендации и действия
Вопрос или проблема
Я немного нов в локальном 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-серверами.
Рекомендации и действия
-
Проверить конфигурацию зоны: Убедитесь, что все записи DNS для
holodev.local
корректные и присутствуют в базе данных. -
Изменить окончание доменного имени: Используйте альтернативное окончание, например
.dev
, если это возможно. -
Очистка кэша DNS: Попробуйте очистить кэш вашего DNS и повторно выполнить запрос.
-
Используйте опцию +trace: Воспользуйтесь
dig +trace
для детального анализа выполнения DNS-запроса. -
Логирование: Проверьте логи PowerDNS, чтобы выявить возможные ошибки на стороне сервера.
Следуя этим рекомендациям, вы сможете устранить проблему с SERVFAIL
и добиться полной функциональности вашего локального DNS-сервера на основе PowerDNS.