Пользователь сообщил, что на его рабочей станции имя определенного узла разрешается, а на центральной системе - нет. При этом центральная система была способна разрешать имена других узлов.

Мы провели ряд тестов и обнаружили, что на одних системах имя этого узла разрешается, а на других - нет. Какой-то определенной и предсказуемой схемы у сбоев не было. Поэтому мы воспользовались nslookup для проверки удаленных серверов:

% nslookup
 Default Server: crab.wrotethebook.com
 Address: 172.16.12.1
 >    set type=NS
     >    foo.edu.
         Server: crab.wrotethebook.com
         Address: 172.16.12.1
         foo.edu nameserver = gerbil.foo.edu
         foo.edu nameserver = red.big.com
         foo.edu nameserver = shrew.foo.edu
         gerbil.foo.edu inet address = 198.97.99.2
         red.big.com inet address = 184.6.16.2
         shrew.foo.edu inet address = 198.97.99.1
         >    set type=ANY
             >    server gerbil.foo.edu
                 Default Server: gerbil.foo.edu
                 Address: 198.97.99.2
                 >    hamster.foo.edu
                     Server: gerbil.foo.edu
                     Address: 198.97.99.2
                     hamster.foo.edu    inet address = 198.97.99.8
                     >    server red.big.com
                         Default Server: red.big.com
                         Address: 184.6.16.2
                         >    hamster.foo.edu
                             Server: red.big.com
                             Address: 184.6.16.2
                             *** red.big.com can't find hamster.foo.edu: Non-existent domain 

Данный сеанс nslookup содержит несколько шагов. Прежде всего, необходимо найти компетентные серверы для имени узла, о котором идет речь {hamster.foo.edu). Мы установили тип запроса в NS, чтобы получить соответствующие записи, и выполнили поиск для домена (foo.edu), к которому принадлежит имя узла. В результате мы получили имена трех компетентных серверов : gerbil.foo.edu, red.big.com и shrew.foo.edu.

Затем мы установили тип запроса в ANY с целью поиска произвольных записей, связанных с именем проблемного узла. Затем мы предписали nslookup обращаться к первому серверу из списка компетентных, gerbil.foo.edu, и выполнили запрос для hamster.foo.edu. Мы получили адресную запись. Итак, сервер gerbil.foo.edu работает замечательно. Мы повторили тест для сервера red.big.com и получили сбой. Запрос не вернул каких-либо записей.

Следующий шаг - получить записи SOA с каждого из серверов и выяснить, идентичны ли они:

>    set type=SOA
>    foo.edu.
Server: red.big.com
Address: 184.6.16.2
foo.edu    origin = gerbil.foo.edu
mail addr = amanda.gerbil.foo.edu
serial=10164, refresh=43200, retry=3600, expire=3600000,
min=2592000
>    server gerbil.foo.edu
Default Server: gerbil.foo.edu
Address: 198.97.99.2
>    foo.edu.
Server: gerbil.foo.edu
Address: 198.97.99.2
foo.edu    origin = gerbil.foo.edu
mail addr = amanda.gerbil.foo.edu
serial=10164, refresh=43200, retry=3600, expire=3600000,
min=2592000
> exit

Если записи SOA имеют различные порядковые номера, вполне возможно, что файл зоны (а следовательно, и данные узла) еще не был скопирован на подчиненный сервер. Если порядковые номера совпадают, а данные различаются, как в этом случае, присутствует конкретная проблема. Уведомите администратора удаленного домена. Почтовый адрес администратора содержится в поле «mail addr» записи SOA. В нашем примере письмо с описанием проблемы отправляется на адрес Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра..