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

Администратор получил образ кэша (более подробно об этом поговорим в следующем разделе), и таким образом убедился, что его сервер обладает корректной записью для проблемного узла. Несмотря на это, сервер не мог выполнить преобразование имени узла в 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. Он исправил ошибку, и проблема исчезла.

Обмениваться, хранить, передавать Ваши файлы стало просто как никогда.
yandex-disk
Читать подробнее: для чего Yandex-Диск проекту Mini-Server. Практика установки, настройки и использования сетевого хранилища на Ubuntu server LTS 12.04 в статье Резервное копирование сервера Ubuntu на Яндекс Диск.

>> Ubuntu 12.04 + Nginx Скачать сервер
>> Fedora 15 Скачать сервер
>> Простой Debian 6.0.6 Скачать сервер
>> CentOS 6.0 и
+ (5.6) другой
Скачать сервер
>> OpenSUSE 11.4
MAX
Скачать сервер

Вход на сайт

ВНИМАНИЕ!

Регистрация на сайте только по согласованию с администратором ресурса. Обращаться через форму обратной связи.