Тестирование и отладка
Категория: Система доменных имен | Автор: admin | 30-04-2010, 04:15 | Просмотров: 3887

Демон named располагает рядом встроенных средств отладки, основное из которых — великолепная подсистема журнальной регистрации. Можно также задавать уровни отладки в строке вызова демона или устанавливать их посредством команды ndc. Имеются команды, заставляющие демон вывести статистику результатов своей работы в файл. С помощью программ dig и nslookup можно проверить, правильно ли функционирует механизм поиска имен.

 

Журнальная регистрация

 

Возможности подсистемы журнальной регистрации демона named действительно впечатляют. Сервер BIND 4 использует систему Syslog для записи сообщений об ошибках и различных аномалиях. В BIND 8 концепция журнальной регистрации обобщена: добавлен еще один уровень переадресации и поддерживается направление сообщений непосредственно в файлы. Прежде чем переходить к деталям, приведем мини-словарь терминов, связанных с журнальной регистрацией в пакете BIND (табл. 16.12).

Таблица 16.12. Лексикон пакета BIND

Термин

Что означает

канал

Место, куда направляются сообщения: система Syslog, файл или устройство /dev/null

категория

Класс сообщений, генерируемых демоном named; например, сообщения о динамических обновлениях или сообщения об ответах на запросы

модуль

Имя исходного модуля, который сгенерировал сообщение (только в BIND 9)

средство

Название средства системы Syslog; за DNS не закреплено собственное средство, но можно выбрать любое стандартное

серьезность

Степень тяжести сообщения об ошибке; то, что в Syslog называется приоритетом

 

Конфигурирование журнальной подсистемы осуществляется при помощи инструкции logging в файле named.conf. Сначала определяются каналы — возможные пункты доставки сообщений. Затем различным категориям сообщений назначаются те каналы, куда они будут поступать.

При генерации сообщения ему назначается категория, модуль (в BIND 9) и уровень серьезности. После этого оно рассылается по всем каналам, связанным с данными категорией и модулем. В каждом канале имеется фильтр, определяющий, сообщения какого уровня серьезности можно пропускать. Каналы, ведущие в систему Syslog, подвергаются дополнительной фильтрации в соответствии с правилами, установленными в файле /etc/syslog.conf.

Вот общий вид инструкции logging:

 

logging {

   определение канала; 

   определение канала; 

...

   category имя_категории {

        имя_канала;

        имя канала;

...

  };

};

 

 

Определение канала может выглядеть немного по-разному в зависимости от того, ведет ли он к файлу или к системе Syslog. Для каждого канала необходимо выбрать либо тип file, либо тип syslog; совмещать их канал не может.

 

channel имя_канала {

 

file путь [versions число_версии | unlimited]   [size размер];

syslog средство;

severity серьезность;

print-category yes  | no;

print-severity yes  | no;

print-time yes  | no;

};

 

 

Для файлового канала аргумент число_версий сообщает, сколько резервных копий файла нужно хранить. Аргумент размер указывает, какой предельный размер файла допускается (примеры: 2048, 100k, 20m, 15g, unlimited, default).

Для каналов системы Syslog задается имя средства, указываемое при регистрации сообщений. Это может быть любое стандартное средство, но на практике единственный разумный выбор — средства daemon и lосаl0-lосаl7.

 

Остальные предложения в определении канала являются необязательными. Аргумент серьезность может принимать следующие значения (в порядке снижения приоритета): critical, error, warning, notice, info и debug (к нему может добавляться номер уровня, например severity debug 3). Понимается также значение dynamic, которое соответствует текущему уровню отладки сервера.

Различные параметры семейства print задают или отменяют вывод различных префиксов сообщений. Система Syslog добавляет перед каждым сообщением метку времени и имя узла, но не уровень серьезности или категорию. В BIND 9 существует также параметр, позволяющий отображать имя исходного файла (модуля), сгенерировавшего сообщение. Параметр print-time рекомендуется включать только для файловых каналов, поскольку в Syslog произойдет ненужное дублирование информации.

В табл. 16.13 перечислены четыре канала, определенные по умолчанию. В большинстве случаев создавать новые каналы не требуется.

 

Таблица 16.13. Стандартные каналы журнальной регистрации пакета BIND

Имя канала

Назначение

default syslog

Посылает сообщения уровня info и выше в систему Syslog от имени средства daemon

default_debug

Направляет сообщения в файл named.run; уровень серьезности устанавливается равным dynamic

default_stderr

Направляет сообщения в стандартный канал ошибок демон: named с уровнем серьезности info

null

Отбрасывает все сообщения

 

В табл. 16.14 приведен список категорий сообщений, поддерживаемых в BIND 8 и 9. Категории версии 9 еще не полностью определены. Если в столбце Версия указано "8/9?", это означает, что категория существует в BIND 8, но еще не поддерживается в BIND 9.

 

Таблица 16.14. Категории сообщений пакета BIND

Категория

Версия

Что охватывает

default

8/9

Категории, для которых не был явно назначен канал1

General

9

Неклассифицированные сообщения

Config

8/9

Этап анализа и обработки конфигурационного файла

Parser

8

Этап низкоуровневой обработки конфигурационного файла

Queries/client

8/9

Короткое сообщение для каждого запроса, принимаемого сервером (!)

Dnssec

9

Сообщения системы DNSSEC

lame-servers

8/9?

Сообщения о серверах, которые, как предполагается, обслуживают зону, но на самом деле это не так2

statistics

8/9?

Общие статистические сообщения серверов имен

Panic

8/9?

Фатальные ошибки

Update

8/9

Сообщения о динамических обновлениях

Ncache

8/9?

Сообщения о кэшировании отрицательных ответов

xfer-in

8/9

Сообщения о зонных пересылках, принимаемых сер­вером

xfer-out

8/9

Сообщения о зонных пересылках, отправляемых сер­вером

db/database

8/9

Сообщения об операциях с базой данных

eventlib

8

Отладочная информация, поступающая от системы обработки событий

Packet

8/9?

Копии принимаемых и отправляемых пакетов3

Notify

8/9

Сообщения об изменении зоны

Cname

8/9?

Сообщения вида "... указывает на запись CNAME"

security

8/9

Принятые или не принятые запросы

os

8/9?

Ошибки операционной системы

Insist

8/9?

Внутренние ошибки

maintenance

8/9?

Периодические служебные события

Load

8/9?

Сообщения о загрузке зоны

response-checks

8/9?

Пояснения  к неправильно сформированным или неверным ответным пакетам

resolver

9 '

Операции преобразования имен, например рекурсив­ный поиск, выполняемый от имени клиента

Network

9

Сетевые операции

1 В BIND 8 категорию default попадают также неклассифицированные сообщения.

2 Это может быть как родительская, так и дочерняя зона.

3 Это должен быть единый файловый канал.

 

Полный список категорий BIND 8 содержится в файле /include/dns/congcommon.h. В том же каталоге находится файл log.h со списком модулей. В BIND 9 эти файлы называются lib/dns/include/dns/log.h и bin/named/include/named/log.h.

Стандартный вид инструкции logging в BIND 8 таков:

 

logging {

   category default { default_syslog; default_debug;  };

   category panic { default_syslog; default_stderr;};

   category eventlib { default_debug;};

   category packet ( default_debug;};

};

 

 

В BIND 9 он будет следующим:

 

logging {

   category default ( default_syslog; default_debug;   };

};

 

 

Нужно просматривать журнальные файлы при внесении существенных изменений в систему BIND; возможно, стоит также повысить уровень отладки. После того как демон named вернется в стабильное состояние, следует переконфигурировать систему так, чтобы регистрировались только важные сообщения. Ниже перечислены наиболее распространенные сообщения.

•        Неправильно сконфигурированный сервер. Если подобное сообщение поступает от одной из внутренних зон, значит, в конфигурации системы присутствует ошибка. Если же в сообщении говорится о какой-то зоне в Internet, то можно не беспокоиться: это чья-то чужая ошибка.

•        Неправильная отсылка. Это сообщение свидетельствует о неправильном взаимодействии серверов имен определенной зоны.

•        Не авторитетен. Подчиненный сервер не может получить авторитетные данные о зоне. Возможно, у него хранится неправильная ссылка на главный сервер или же тот не смог загрузить зону.

  • Отказанная зона. Демон named отказался загружать зонный файл, поскольку тот содержит ошибки.
  • Не найдена запись NS. В зонном файле после записи SOA отсутствуют записи NS. Возможно, они действительно отсутствуют либо перед ними не поставлен знак табуляции или какой-нибудь другой пробельный символ. Во втором случае эти записи не присоединяются к зоне и, следовательно, интерпретируются неправильно.

•        Не задано стандартное значение TTL. Желательно задавать стандартное значение TTL посредством директивы $TTL, расположенной в начале зонного файла. Данная ошибка свидетельствует о том, что такая директива отсутствует. В BIND 8 в подобной ситуации берется значение параметра минимальное время жизни записи SOA. В BIND 9 наличие директивы обязательно, в противном случае демон named откажется загружать зонный файл.

  • Нет корневого сервера имен для данного класса. Демону named не удается найти корневые серверы имен. Следует проверить файл корневых "подсказок" и подключение сервера к Internet.
  • Адрес уже используется. Порт, который нужен для работы демона named, занят другим процессом, возможно, другой копией демона. Если демон отсутствует в списке выполняющихся процессов, то, очевидно, он перед этим аварийно завершил свою работу и оставил открытым управляющий сокет программы ndc.

 

Прекрасную таблицу с описанием сообщений об ошибках BIND можно найти по адресу

http://www.acmebw.com/askmrdns/bind-messages.htm

 

Уровни отладки

 

Уровни отладки демона named обозначаются целыми числами от 0 до 11. Чем выше уровень, тем больше текста содержит выходная информация. Уровень 0 выключает отладку. Уровни 1 и 2 отлично подходят для отладки конфигурационного файла и базы данных. Уровни выше четвертого предназначены для программистов, сопровождающих программный код демона.

Отладку можно запустить из командной строки, активизируя демон named с флагом -d. Например, команда

# named -d2

 

запускает демон на уровне отладки 2. По умолчанию отладочная информация записывается в файл named.run, местоположение которого зависит от операционной системы (подробности указаны в параграфе 16.16). Он растет очень быстро, поэтому в процессе отладки будьте внимательны.

Если отладку нужно включить во время работы демона named, необходимо воспользоваться командой ndc trace, которая увеличивает уровень отладки на единицу. Команда ndc notrace отключает режим отладки. Кроме того, возможно создание канала регистрации сообщений, в определение которого входит строка следующего вида:

severity debug 3

 

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

Просматривая файлы регистрации и отладочные сообщения, можно заметить, как часто делаются ошибки в конфигурации DNS. Малюсенькая точка в конце имени (точнее, ее отсутствие) приводит к угрожающему росту трафика DNS. Теоретически точка нужна в конце каждого полностью определенного имени домена.

 

Отладка посредством программы ndc

 

Программа ndc (rndc в BIND 9) — очень удобное средство управления демоном named. Поддерживаемые ею команды перечислены в табл. 16.15. Те команды, которые создают файлы, помещают их в каталог, обозначенный в файле named.conf как начальный каталог демона named.

Выполнить команду ndc reload — все равно что послать демону named сигнал HUP. Эта команда заставляет демон заново прочитать конфигурационный файл и повторно загрузить зонные файлы. Команду ndc reload зона удобно применять на загруженном сервере, когда изменению подвергается только одна зона, а остальные трогать не нужно.

 

Таблица 16.15. Полезные отладочные команды программы ndc

Команда

Функция

help

Вывод списка доступных команд программы ndc

status

Отображение текущего статуса выполнения демона named

trace

Увеличение уровня отладки на единицу

notrace

Выключение отладки

dumpdb

Вывод образа базы данных DNS в файл nameddump.db

stats

Вывод статистической информации в файл named.stats

reload

Повторная загрузка файла named.conf и зонных файлов

reload зона 

Повторная загрузка только указанной зоны

restart

Повторный запуск демона named с очисткой кэша

querylog

Переключение режима трассировки поступающих запросов

 

Команда ndc dumpdb заставляет демон named записать образ своей базы данных в файл named_dump.db. Он будет очень большим и будет содержать не только локальные данные, но также данные, накопленные в кэше сервера имен. Не так давно мы провели эту операцию на основном сервере имен домена colorado.edu, и вышло, что кэш базы данных занял 16 Мбайт, тогда как весь зонный файл — менее 200 Кбайт.

Последние версии демона named ведут статистику запросов, которую можно получить с помощью команды ndc stats. В ответ на нее демон записывает статистическую информацию в файл named.stats. Ниже показан образец такого файла, взятый с главного сервера домена cs.colorado.edu (перед этим он непрерывно функционировал в течение 43-х дней). Мы немного сократили вывод, удалив записи, касающиеся устаревших или неиспользуемых типов записей. Кроме того, мы переформатировали нижнюю секцию, которая обычно записывается в одну строку.

 

+++ Statistics Dump +++ Wed Feb   2 15:07:18 2000

 

180465           time since boot  (sees)

52669            time since reset  (sees)

0                Unknown query types

475460           A queries

3                NS queries

194              CNAME queries

15686            SOA queries

138816           PTR queries

76244            MX queries

130939           TXT queries

1                LOC queries

171              SRV queries

42               AXFR queries

124587           ANY queries

 

++ Name Server Statistics ++

 

RR     RNXD   RFwdR   RDupR   RFail   RFErr   RErr   RAXFR   RLame

320252 23620  249826  1013    3532    0       903    42      10339

 

ROpts   SSysQ   SAns   SFwdQ   SDupQ   SErr   RQ     RIQ  RFwdQ

0       55547   652973 265736  291448  0      963690 0    0

 

RDupQ   RTCP   SFwdR   SFail   SFErr   SNaAns    SNXD

47876   1605   249826  18      0       162533    190644

 

 

Загадочные данные в конце листинга отображают такие статистические показатели, как число дублирующихся запросов и ответов, а также количество случаев напрасного делегирования. Первая буква аббревиатуры обозначает принятый (R) или отправленный (S) пакет, последняя — запрос (Q) или ответ (R). Реальный смысл заголовков описан в файле ns_stats.c, который расположен в каталоге src/bin/named дистрибутива BIND 8. На момент написания книги статистические показатели еще не были реализованы в BIND 9, поэтому мы не можем указать нужный исходный файл. Его можно будет найти с помощью утилиты grep или find.

Любой запрос, приводящий к ошибке, регистрируется, учитывается в одном или нескольких статистических показателях и отбрасывается. В категорию Unknown query types (неизвестные типы запросов) включается любой запрос к ресурсу, тип которого не поддерживается сервером. Группа ANY — это не настоящий тип записей. Сюда попадают запросы, содержащие просьбу предоставить любую информацию о требуемом имени. Колонки в нижней половине листинга, в заголовке которых содержится строка Dup, отображают число дублирующихся запросов или ответов. Дублирование обычно происходит, когда срок действия запроса истекает раньше, чем на него будет получен ответ. В этом случае запрос посылается заново.

В BIND 8, если установлен параметр deallocate-on-exit, команда ndc stats, помимо всего прочего, записывает в файл named.memstats статистику использования памяти. В BIND 9 данная информация доступна только в режиме отладки демона named.

 

Отладка с помощью программ nslookup, dig и host

 

Программы nslookup, dig и host позволяют в режиме командной строки посылать запросы базе данных DNS. Самая старая из них — nslookup, она всегда являлась частью дистрибутива BIND. Программа dig (domain information groper — искатель доменной информации) первоначально была написана Стивом Хотцом (Steve Hotz), а Майкл Сойер (Michael Sawyer) переписал ее для BIND 9. Она также входит в состав BIND. Программа host, написанная Эриком Вассенааром (Eric Wassenaar), поставляется с исходными текстами и имеет функции для проверки синтаксиса зонных файлов. Мы рассмотрим все три утилиты, но прежде нужно сказать, что мы предпочитаем пользоваться программой dig, а не nslookup, хотя программа host нам тоже нравится. Иногда они выдают разные результаты из-за того, что используются разные модули распознавания: в dig и host это распознаватель пакета BIND, а в nslookup — свой собственный.

Программа nslookup — утилита пользовательского уровня, посылающая запросы базе данных DNS. Она принимает в качестве аргумента полностью определенные имена, оканчивающиеся точкой, и добавляет стандартное имя домена, если точка не указана. При работе с локальными именами это как раз то, что нужно. В табл. 16.16 показан краткий список команд, поддерживаемых программой nslookup.

Таблица 16.16. Команды, которые поддерживаются программой nslookup

Команда

Функция

имя

Вывод информации об указанном узле или домене

help или ?

Вывод полного списка команд

exit

Выход

server узел 

Задание сервера по умолчанию с использованием текущего сервера

lserver узел 

Задание сервера по умолчанию с использованием исходного сервера

set type=xcx 

Установка типа записи для запроса1

set debug

Включение отладки

set d2

Включение массы отладочных средств

ls домен 

Вывод всех машинно-адресных соответствий

1 Хороший аргумент для этой команды – any, т.е. «все»

 

Программа dig имеет те же функциональные возможности, что и nslookup, но установки, заложенные в ней по умолчанию, более эффективны. Кроме того, она выдает больше информации и отличается более изысканным интерфейсом пользователя (особенно в сравнении со старыми версиями nslookup).

Например, запросить записи MX для узла anchor можно посредством команды

% dig anchor.cs. Colorado.edu. mx

 

Команда

% dig @nsl.berkeley.edu vangogh.berkeley.edu. any

 

запрашивает все записи для узла vangogh с сервера berkeley.edu, а команда

% dig -х 128.32.33.5

выполняет обратный запрос, в результате которого будет найден узел vangogh.

Приведем полный пример, в котором программы nslookup и dig запрашивают одни и те же данные:

% nslookup

Default Server:    bb.rc.vix.com

Address:    204.152.187.11

> set

> amazon.com.

Server:    bb.rc.vix.com

Address:    204.152.187.11

Non-authoritative answers:

amazon.com nameserver = AUTHOD.NS.UU.NET

amazon.com nameserver = NS2.PNAP.NET

amazon.com nameserver = NS1.PNAP.NET

amazon.com nameserver - NS-1.amazon.com

amazon.com preference = 10, mail exchanger = service-4.amazon.com

amazon.com preference = 10, mail exchanger = service-5.amazon.com

amazon.com internet address = 208.216.182.15

Authoritative answers can be found from:

amazon.com             nameserver = AUTHOO.NS.UU.NET

amazon.com             nameserver = NS2.PNAP.NET

amazon.com             nameserver = NS1.PNAP.NET

amazon.com             nameserver = NS-1.amazon.com

AUTH00.NS.UU.NET       internet address = 198.6.1.65

NS2.PNAP.NET           internet address = 206.253.194.97

NS1.PNAP.NET           internet address = 206.253.194.65

NS-1.amazon.com        internet address = 209.191.164.20

service-4.amazon.com   internet address = 209.191.164.50

service-5.amazon.com   internet address = 209.191.164.51

 

 

Программа nslookup вернула четыре записи NS, две записи MX и одну запись А. Она также выдала IP-адреса серверов имен и МХ-узлов.

 

% dig amazon.com. any

; «» DiG 8.3 «>> amazon.com any

;; res options:  init recurs defnam dnssrch

;; got answer:

;;  -»HEADER«- opcode: QUERY,   status:  NOERROR,   id:  4

;;  flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 4, ADDITIONAL: 6

;; QUERY SECTION:

;;         amazon.com,  type = ANY,  class = IN

;; ANSWER SECTION:

amazon.com.            1h27mlls    IN   NS   AUTHOO.NS.UU.NET.

amazon.com.            1h27mlls    IN   NS   NS2.PNAP.NET.

amazon.com.            1h27mlls    IN   NS   NS1.PNAP.NET.

amazon.com.            1h27mlls    IN   NS   NS-1.amazon.com.

amazon.com.            59m22s      IN   MX   10  service-4.amazon.com.

amazon.com.            59m22s      IN   MX   10  service-5.amazon.com.

amazon.com.            1h59m29s    IN   A    208.216.182.15

;; AUTHORITY SECTION:

amazon.com.            1h27mlls    IN   NS   AUTHOO.NS.UU.NET.

amazon.com.            1h27mlls    IN   NS   NS2.PNAP.NET.

amazon.com.            1h27mlls    IN   NS   NS1.PNAP.NET.

amazon.com.            1h27mlls    IN   NS   NS-1.amazon. com.

;; ADDITIONAL SECTION:

AUTHOO.NS.UU.NET.       13hllm20s    IN   A   198.6.1.65

NS2.PNAP.NET.           20h51m44s    IN   A   206.253.194.97

NS1.PNAP.NET.           20h51m44s    IN   A   206.253.194.65

NS-1.amazon.com.        59m22s       IN   A   209.191.164.20

service-4.amazon.com.   59m22s       IN   A   209.191.164.50

service-5.amazon.com.   59m22s       IN   A   209.191.164.51

;; Total query time: 7 msec

;;  FROM: bb.rc.vix.com to SERVER:  default — 204.152.187.11

;;  WHEN:  Sun Jul    2 12:45:59 2000

;; MSG SIZE    sent:  28    rcvd:  338

 

 

Программа dig довольно многословна. Ее выходная информация включает не только сведения о домене, но и данные о количестве посланных запросов и полном времени прохождения ответа. Выводные данные отформатированы так, чтобы их можно было использовать в зонных файлах. Это особенно удобно, если делаются запросы к корневым серверам с целью заполнения файла "подсказок".

Программа host по умолчанию выдает краткую, но полезную информацию об указанном домене. Существует также опция -v для более детального описания (хотя и не столь подробного, как в случае программы dig). Вводимое имя домена должно завершаться точкой. Встречая относительное имя, программа сначала пытается добавить к нему домены, указанные в файле resolv.conf. Если ни одно из них не подходит, программа просто присоединяет к имени точку.

% host amazon.com.

amazon.com has address 208.216.182.15

amazon.com mail is handled (pri=10) by service-4.amazon.com

amazon.com mail is handled (pri=10) by service-5.amazon.com

 

 

Тестируя новую конфигурацию, не забудьте проверить как локальные, так и удаленные узлы. Если доступ к узлу можно получить по IP-адресу, но не по имени, скорее всего, виновата система DNS.

 

Напрасное делегирование

 

Подавая заявление о получении доменного имени, вы просите, чтобы вашему основному серверу имен и администратору DNS была выделена (делегирована) некоторая часть дерева имен. Если не поддерживать работу домена или перенести сервер имен на другой компьютер, не обновив связующие записи родительского домена, будет иметь место так называемое напрасное делегирование.

Последствия напрасного делегирования могут быть очень плохими. Если пользователь попытается связаться с узлом, находящимся в неправильно сконфигурированном домене, сервер имен отклонит этот запрос, но система DNS продолжит повторять запрос сотни раз, терроризируя и главный сервер пользователя, и корневые серверы. В одном журнальном файле, размер которого за неделю возрос до 3,5 Мбайт (на уровне info), более трети записей касались напрасного делегирования. Из них 16% запросов были к корневым серверам, предположительно по поводу несуществующих доменов. Один настойчивый пользователь более сотни раз запрашивал корневые серверы о домене tokyotopless.net. Бедняга!

Приведем пример:

 

Jan 29 05:34:52 ipn.caida.org named[223]: Lame server on

'www.games.net'   (in 'GAMES.net'?):   1207.82.198.1501.53 'NS2.EX0DUS.net'

 

 

Вот как можно установить источник проблемы с помощью программы dig (часть выходных данных отброшена):

 

% dig www. games . net.

;;  QUESTIONS:

;;  www.games.net,  type = A,  class = IN

;; ANSWERS :

www.games.net.   3600     A     209.1.23.92

;; AUTHORITY RECORDS :

games.net.       3600     NS   ns.exodus.net.

games.net.       3600     NS   ns2.exodus.net.

games.net.       3600     NS   ns.pcworld.com.

;; ADDITIONAL RECORDS:   ...

 

 

В ответ на первый запрос к локальному серверу возвращается адресная запись для узла www.games.net и список авторитетных серверов. Сервер ns.exodus.net на момент обращения к нему работал нормально (результаты запроса здесь не показаны), а вот сервер ns2.exodus.net — совсем другая история:

% dig @ns2.exodus.net www.games.net.

;;  QUESTIONS:

;;  www.games.net,  type = A,  class = IN

;; AUTHORITY RECORDS :

net.                244362  NS  F.GTLD-SERVERS.net.

net.                244362  NS  J.GTLD-SERVERS.net.

net.                244362  NS  К.GTLD-SERVERS.net.

net.                244362  NS  A.GTLD-SERVERS.net.

 

 

Сервер указан как авторитетный для домена, но для него не возвращается записей, лишь ссылки на серверы домена верхнего уровня "net". Следовательно, можно сделать вывод о том, что домен ns2.exodus.com сконфигурирован неправильно.



 (голосов: 0)
Версия для печати | Комментариев: 0
Информация
Посетители, находящиеся в группе Гости, не могут оставлять комментарии в данной новости.


 
Логин
Пароль
 

 
Locations of visitors to this page