Об этой проблеме сообщил администратор одного из наших подчиненных серверов имен. Администратор сообщил, что его сервер не может выполнить разрешение имени определенного узла из домена, для которого сервер является подчиненным. Основной сервер при этом совершенно свободно выполнял ту же операцию.
Администратор получил образ кэша (более подробно об этом поговорим в следующем разделе), и таким образом убедился, что его сервер обладает корректной записью для проблемного узла. Несмотря на это, сервер не мог выполнить преобразование имени узла в IP-адрес!
Проблема была воспроизведена на ряде других подчиненных серверов. Имя узла поддавалось разрешению только основным сервером, но не подчиненными. Все серверы имели один и тот же порядковый номер в записи SOA, и образ кэша на каждом сервере показывал, что для узла существует корректная адресная запись. Так почему же они не могли преобразовать имя узла в адрес?
Поразмыслив о различиях между способами, которыми загружают данные основные и дополнительные серверы, мы заподозрили, что дело в передаче файла зоны. Основные серверы загружают свои данные непосредственно из локальных дисковых файлов. Подчиненные серверы получают данные от основного сервера путем передачи зоны. Возможно, происходила порча файлов зоны. Мы вывели файл зоны на одном из подчиненных серверов и увидели такие данные:
% cat /usr/etc/events.wrotethebook.com.hosts
PCpma IN A 172.16.64.159
IN HINFO "pc" "n3/800eventsnutscom"
PCrkc IN A 172.16.64.155
IN HINFO "pc" "n3/800eventsnutscom"
PCafc IN A 172.16.64.189
IN HINFO "pc" "n3/800eventsnutscom"
accu IN A 172.16.65.27
cmgdsl IN A 172.16.130.40
cmg IN A 172.16.130.30
PCgns IN A 172.16.64.167
IN HINFO "pc" "(3/800eventsnutscom"
gw IN A 172.16.65.254
zephyr IN A 172.16.64.188
IN HINFO "Sun" "sparcstation"
ejw IN A 172.16.65.17
PCecp IN A 172.16.64.193
IN HINFO "pc" "n Lsparcstationstcom"
Обратите внимание на странное значение в последнем поле оператора HINFO каждой из машин. Эти данные могли быть повреждены при передаче либо изначально были некорректными на основном сервере. Мы воспользовались nslookup, чтобы проверить это обстоятельство:
% nslookup Default Server: crab.wrotethebook.com Address: 172.16.12.1 > server 24seven.events.wrotethebook.com Default Server: 24seven.events.wrotethebook.com Address: 172.16.6.1 > set query=HINFO > PCwlg.events.wrotethebook.com Se rve r: 24seven.events.wrotethebook. com Address: 172.16.6.1 PCwlg.events.wrotethebook.com CPU=pc OS=ov packet size error (0xf7fff590 != 0xf7fff528) > exit
В данном примере мы предписали nslookup обращаться к серверу 24seven.euents.wrotethebook.com, то есть основному серверу домена events.wrotethebook.com. Затем мы запросили запись HINFO одного из тех узлов, для которых заподозрили порчу данных. Сообщение «packet size error» четко показывает, что nslookup столкнулась с проблемами, пытаясь получить запись HINFO напрямую с основного сервера. Мы связались с администратором основного сервера и рассказали ему о проблеме, указав на конкретные записи, попавшие под подозрение. Администратор обнаружил, что забыл добавить запись операционной системы в некоторые из записей HINFO. Он исправил ошибку, и проблема исчезла.
