Я установил BIND9 через apt-get на недавно установленном и полностью обновленном UBUNTU 12.04, виртуализированном на VirtualBox.
Я хочу использовать его как сервер имен только для кеша.
named.conf содержит только следующие строки:
options { directory "/var/cache/bind"; dnssec-validation auto; auth-nxdomain no; listen-on-v6 {any;}; recursion yes; allow-recursion {localnets;}; allow-query-cache {localnets;}; allow-query {localnets;}; }; zone "." { type hint; file "/etc/bind/db.root"; }; zone "localhost" { type master; file "/etc/bind/db.local"; }; zone "127.in-addr.arpa" { type master; file "/etc/bind/db.127"; };
Теперь, если я dig что-либо, использующее мой сервер имен, поиск не выполняется с connection timed out; no servers could be reached и журнал BIND9 полон DNS format error [...] non-improving referral или также FORMERR.
В частности, результат dig @127.0.0.1 www.amazon.com является
; <<>> DiG 9.8.1-P1 <<>> @127.0.0.1 www.amazon.com ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached
Кроме того, с помощью Wireshark я могу видеть исходящие пакеты на корневые серверы, но никогда не получаю ответа.
Но если я использую dig используя внешний сервер имен (например, 8.8.8.8), или я использую его в опции пересылки BIND9, поиск будет успешным.
Зачем?
Я полагаю, вы уже подтвердили, что в вашем Ubuntu в VirtualBox есть реальное подключение к Интернету.
Если это так, частой причиной того, что ваш собственный рекурсивный сервер не работает, является то, что ваш интернет-провайдер блокирует доступ к другим авторитетным серверам имен, которые работают на domain порт. Я вижу ты уже безуспешно пытался делать прямые запросы к корневым серверам непосредственно с dig, что указывает на наличие некоторых проблем с подключением.
Короче, вы можете сделать простой тест: попробуйте запустить dig @8.8.8.8 +trace www.google.com имитировать, как рекурсивный преобразователь будет выполнять разрешение имен.
Если вы получите тайм-аут до ., то либо с вашим подключением что-то не так, либо ваш провайдер блокирует Google Public DNS (и, скорее всего, любой другой DNS тоже).
Если вы получите тайм-аут сразу после ., то ваш провайдер блокирует доступ к корневым серверам (и, вероятно, ко всем другим авторитетным серверам имен тоже).
Если ваше рекурсивное разрешение не имеет тайм-аутов, но отсутствует com. и google.com. шаги, прыгая прямо с . к www.google.com. (или, возможно, даже не . для начала), значит, ваш провайдер перенаправляет все domain-port запрашивает их собственный набор рекурсивных DNS-серверов, и вы не можете запустить свой собственный рекурсивный сервер имен с таким подключением к Интернету.
Если вы получите результат почти такой же, как показано ниже, со всеми ., com., google.com. и www.google.com. шагов, то ваш собственный локальный рекурсивный преобразователь должен работать нормально, при условии соблюдения инструкций по установке и настройке.
# dig @8.8.8.8 +trace www.google.com
; <<>> DiG 9.7.3 <<>> @8.8.8.8 +trace www.google.com
; (1 server found)
;; global options: +cmd
. 2244 IN NS a.root-servers.net.
. 2244 IN NS b.root-servers.net.
. 2244 IN NS c.root-servers.net.
. 2244 IN NS d.root-servers.net.
. 2244 IN NS e.root-servers.net.
. 2244 IN NS f.root-servers.net.
. 2244 IN NS g.root-servers.net.
. 2244 IN NS h.root-servers.net.
. 2244 IN NS i.root-servers.net.
. 2244 IN NS j.root-servers.net.
. 2244 IN NS k.root-servers.net.
. 2244 IN NS l.root-servers.net.
. 2244 IN NS m.root-servers.net.
;; Received 228 bytes from 8.8.8.8#53(8.8.8.8) in 25 ms
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
;; Received 504 bytes from 192.33.4.12#53(c.root-servers.net) in 15 ms
google.com. 172800 IN NS ns2.google.com.
google.com. 172800 IN NS ns1.google.com.
google.com. 172800 IN NS ns3.google.com.
google.com. 172800 IN NS ns4.google.com.
;; Received 168 bytes from 192.55.83.30#53(m.gtld-servers.net) in 183 ms
www.google.com. 300 IN A 74.125.225.208
www.google.com. 300 IN A 74.125.225.211
www.google.com. 300 IN A 74.125.225.212
www.google.com. 300 IN A 74.125.225.209
www.google.com. 300 IN A 74.125.225.210
;; Received 112 bytes from 216.239.38.10#53(ns4.google.com) in 24 ms
Первое, что я замечаю, это то, что у вас нет «рекурсии да»; в named.conf. BIND не является рекурсивным по умолчанию (в течение некоторого времени) из соображений безопасности. Вы должны разрешить вашей локальной сети запрашивать преобразователь с рекурсивными запросами:
acl me {
::1/128;
127.0.0.0/8;
};
...
recursion yes;
allow-recursion { me; };
allow-query-cache { me; };
allow-query { me; };
Он не объясняет странные сообщения об ошибках, которые вы обнаруживаете в журналах. Откровенно говоря, в вопросах ServerFault я ненавижу расплывчатые резюме вроде «Теперь, если я что-нибудь откопаю с помощью своего сервера имен, поиск завершится неудачно, и время соединения истекло». Опубликуйте полную команду и полный результат, и мы увидим.