Ошибка SERVERFAIL при выполнении nslookup на самом сервере. FreeBSD

Я использую FreeBSD для настройки DNS-сервера. Я установил BIND и настроил все в файле resolv.conf и named.conf .

Это IP-адрес моего DNS-сервера 192.168.10.100 .

в resolv.conf Я добавил следующую строку:

nameserver 192.168.10.100

Я также создал зону в файле named.conf с именем .pbv , а затем я использовал nsupdate , чтобы добавить домен в эту зону, которая называется testing.pbv

. Теперь, когда я nslookup 192.168.10.100 на самом сервере, он не работает и всегда возвращается,

;; Got SERVFAIL reply from 192.168.10.100, trying next server
;; connection timed out; no servers could be reached

Однако, когда я nslookup testingpbv , он возвращает следующее:

Server:         192.168.10.100
Address:        192.168.10.100#53

Name:   testing.pbv
Address: 192.168.10.100

Я не понимаю, почему я не могу запустить nslookup 192.168.10.100 ?

Это мой resolv. conf

nameserver 192.168.10.100
nameserver 8.8.8.8

Здесь стоит упомянуть, что я даже не могу найти google.com или любой другой внешний домен, если на то пошло.

0
задан 16 May 2016 в 07:51
2 ответа

Здесь происходит несколько вещей. Давайте разберемся.

  • Если вы не настроили обратную зону для 10.168.192.in-addr.arpa , ваш рекурсивный сервер должен получать эту информацию откуда-то еще. Вы не упомянули о настройке такой зоны, поэтому я предполагаю, что ее не существует.
  • Частные сети RFC 1918 не маршрутизируются в Интернете. Если DNS-сервер должен выполнить полную рекурсию по обратному DNS-запросу для этого IP-пространства, произойдет одно из двух:
    1. Рекурсия выполняется до тех пор, пока не будут достигнуты серверы черной дыры IANA . Они вернут ответ NXDOMAIN .
    2. Сервер пропускает этап обращения к Интернету, поскольку знает, что это бессмысленно. Он подделывает ответ NXDOMAIN и не тратит впустую полосу пропускания. BIND 9.9 и выше делает это с помощью так называемой автоматических пустых зон .

Чтобы упростить все это, если вы видите здесь SERVFAIL , это означает, что что-то сломано. Либо сервер пытается получить ответ из Интернета и не может этого сделать, либо у вас неправильная конфигурация и вы недостаточно внимательно читаете журналы. (например, это могло бы произойти, если бы вы создали зону с недопустимым синтаксисом для 10.168.192.in-addr.arpa )

Чтобы исключить сетевую проблему, вы можете попробовать запустить dig + trace 10.168.192.in-addr.arpa . Если эта команда возвращает ошибку, вам необходимо устранить неполадки в сети. Если он не возвращает ошибку, более внимательно изучите свои журналы.

3
ответ дан 4 December 2019 в 11:45

nslookup на IP-адресе будет искать соответствующую запись PTR , которая, очевидно, отсутствует в вашей конфигурации.

Тем не менее, я работал в огромных компаниях с сотнями серверов, и ни одна из них не настраивала обратный поиск на локальных IP-адресах.

1
ответ дан 4 December 2019 в 11:45

Теги

Похожие вопросы