Назад | Перейти на главную страницу

Ошибка 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 или любой другой внешний домен в этом отношении.

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

  • Если вы не настроили обратную зону для 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. Если эта команда возвращает ошибку, вам необходимо устранить неполадки в сети. Если он не возвращает ошибку, более внимательно изучите свои журналы.

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

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