Тестируемые dns серверы не совпадают с ns записями файла зоны размещенного на сервере
Файлы и логи DNS-серверов
Записи доменных зон PowerDNS.
Записи хранятся в базах данных MySQL, отдельная база на каждое пространство имён.
Проверка возможности передачи доменной зоны от первичного сервера к вторичному
— адрес, указанный на первичном сервере в директиве transfer-source для пространства доменных имён в конфигурационном файле BIND. Можно также узнать на форме редактирования пользователя, который является владельцем доменной зоны: Учётные записи → Пользователи → Изменить → поле IP-адрес.
Ответ должен быть вида:
Частые причины проблемы:
- Для пользователя указан приватный IP-адрес, который недоступен со вторичного сервера.
- Адрес вторичного сервера не указан в allow-transfer доменной зоны. Чтобы добавить адрес вторичного сервера зайдите в DNSmanager под пользователем, который является владельцем доменной зоны → Настройки → Настройки DNS → поле Allow-transfer.
DNS-сервер BIND не смог загрузить доменную зону
Наиболее распространённая причина проблемы в том, что файл доменной зоны некорректный.
Для решения проблемы добавьте в файл доменной зоны A-записи:
Ресурсная запись CNAME не должна быть указана вместе с A-записью для одного поддомена:
Это приводит к ошибке вида:
Также CNAME-запись нельзя создать для доменов второго уровня.
Диагностика вторичного (slave) DNS-сервера
DNS-сервер не отдаёт доменную зону
Проверьте , что на первичном DNS-сервере зона отдаётся :
— IP-адрес DNS-сервера, как правило, совпадает с основным IP-адресом сервера.
Ответ на запрос должен быть вида:
DNS-сервер не запущен, если получен ответ вида:
Если получен пустой ответ, значит, у DNS-сервера нет информации о домене. Возможно, он не смог загрузить доменную зону. Смотрите лог.
Записи доменных зон PowerDNS
Записи хранятся в базах данных MySQL , отдельная база на каждое пространство имён. Пространство по умолчанию — powerdns для CentOS, pdns для Debian.
Проверка связи с первичным DNS-сервером
Подключитесь к первичному серверу по telnet к 53 порту:
Если подключиться не удаётся, проверьте настройки файервола на первичном и вторичном серверах.
Файлы доменных зон BIND
Диагностика первичного (master) DNS-сервера
Права доступа
Если во время передачи доменной зоны от первичного сервера к вторичному в логе есть строки вида:
То причина проблемы в отсутствии прав на файл доменной зоны. Файл доменной зоны должен принадлежать владельцу, от имени которого работает BIND:
В статье приведены решения наиболее часто возникающих проблем, связанных с работой DNSmanager.
Конфигурационный файл PowerDNS
Проверка связи с первичным DNS-сервером
Подключитесь к первичному серверу по telnet к 53 порту:
Если подключиться не удаётся, проверьте настройки файервола на первичном и вторичном серверах.
Не получается завести зону на DNS-сервере. (С DNS-сервера не получена SOA-запись для домена.)
Модератор: SLEDopit
Права доступа
Если во время передачи доменной зоны от первичного сервера к вторичному в логе есть строки вида:
Причина проблемы в отсутствии прав на файл доменной зоны. Файл доменной зоны должен принадлежать владельцу, от имени которого работает BIND:
Файл зоны состоит из ресурсных записей разных типов.
Единственный поддерживаемый класс записей — IN.
Набор ресурсных записей с одинаковым типом, классом и именем (в левой части записи) называется множеством записей (RRset).
Обязательными являются записи типа SOA и NS для имени, совпадающего с названием зоны. Все остальные могут отсутствовать.
Записи состоят из различных полей (параметров).
Формат записи временных параметров
В интерфейсе редактора зон возможно указать значение временных параметров в неделях, днях, часах, минутах и секундах, используя соответствующие буквы: w — недели, d — дни, h — часы, m — минуты, s — секунды.
XXw — XX недель, XXd — XX дней, XXh — XX часов, XXm — XX минут, XXs — XX секунд (где XX — число).
В файл зоны временной параметр будет записан в секундах.
Примеры записей:
1890 — 1890 секунд;
2d5h — 2 дня и 5 часов;
3h30s — 3 часа и 30 секунд.
Параметры Default TTL, TTL, Minimum TTL
Временные параметры Default TTL, TTL, Minimum TTL определяют время TTL (Time-to-live — «время жизни»), в течение которого DNS-серверы (кроме вторичных), получившие информацию о записях с любого DNS-сервера, будут ее хранить в своей памяти (кэше) и сообщать ее по запросам других DNS-серверов.
Определяет «время жизни» (time-to-live) для конкретной записи.
Необязательный параметр. Если значение параметра в записи не указано, то «время жизни» определяется параметром Default TTL.
Рекомендуемое значение:
86400 (1d);
Диапазон допускаемых редактором DNS-master значений:
от 600 до 2147483647 секунд включительно (2 31 −1).
Записи, принадлежащие одному множеству RRrset (с одинаковым типом, классом и именем в левой части записи), должны иметь одинаковое значение TTL.
Default TTL
Определяет время TTL— «время жизни», в течение которого кэширующие DNS-серверы, получившие информацию о записях с любого DNS-сервера, будут ее хранить в своей памяти (кэше) и сообщать ее по запросам других DNS-серверов и резолверов.
Рекомендуемое значение:
86400 (1d);
Диапазон допускаемых редактором DNS-master значений:
от 600 до 2147483647 секунд включительно (2 31 −1).
Minimum TTL
Формат записи временных параметров приведен в соответствующем разделе
Запись SOA (Start of Authority) или начальная запись зоны указывает, на каком сервере хранится эталонная информация о данном домене, содержит контактную информацию лица, ответственного за данную зону, параметры времени кэширования зонной информации и взаимодействия DNS-серверов.
В любой зоне должна быть только одна SOA-запись для имени, совпадающего с именем зоны.
Формат SOA-записи
имя [TTL] SOA Данные
имя: имя зоны
TTL: см. описание параметра TTL
SOА: тип записи
Serial number
Serial number (серийный номер) — это номер версии файла зоны. Этот номер должен быть положительным целым числом и увеличиваться каждый раз, когда в файл зоны вносятся изменения (см. RFC1982). Увеличение серийного номера показывает вторичным серверам, что зона изменена, и что им необходимо обновить у себя зону.
Вы можете не увеличивать этот номер вручную, т.к. он увеличивается автоматически при сохранении файла зоны в редакторе файлов зон.
Если вы измените серийный номер так, что после сохранения файла зоны он останется неизменным или станет меньше, чем был ранее, то вторичные серверы не будут перечитывать данные с первичного сервера, т.к. будут считать, что данные не изменились.
Диапазон допустимых значений (для редактора файлов зон): от 0 до 2147483646 включительно (2 31 −2).
Временной параметр Refresh показывает, как часто вторичные серверы должны запрашивать первичный сервер, чтобы узнать, не увеличился ли Serial number(серийный номер) зоны и, следовательно, не нужно ли обновить ее у себя.
Рекомендуемое значение: от 1h до 6h.
Диапазон допустимых значений: от 30m до 4w.
Формат записи временных параметров приведен в соответствующем разделе.
Параметр Retry показывает, как долго вторичный сервер имен должен ждать, перед тем как повторить попытку запроса первичного сервера (на предмет изменений серийного номера данной зоны), если предыдущая попытка оказалась неудачной.
Рекомендуемое значение: от 20m до 60m;
Диапазон допустимых значений: от 5m до 2w.
Формат записи временных параметров приведен в соответствующем разделе.
Параметр Expire указывает верхнее ограничение по времени, в течение которого вторичный сервер может использовать ранее полученные данные о зоне до того, как они потеряют силу из-за отсутствия обновления (например, вследствие отключения первичного сервера имен на длительное время).
Рекомендуемое значение: от 1w до 1m;
Диапазон допустимых значений: не менее значения параметра Refresh и не более 1 года.
Формат записи временных параметров приведен в соответствующем разделе.
Редактирование SOA-записи
Для редактирования SOA-записи необходимо выбрать домен.
Затем выбрать пункт «SOA и TTL».
После чего заполнить необходимые поля и нажать кнопку «Применить».
Далее, перед выгрузкой обновленного файла зоны можно посмотреть его содержимое, для этого нужно зайти в пункт «Ресурсные записи».
Нажать ссылку «предпросмотр зоны».
В открывшемся окне проверить правильность обновляемых данных.
В данном случае SOA-запись имеет следующий вид:
Если данные верны, то нужно выгрузить зону. Для этого закройте окно с содержимым файла зоны и нажмите кнопку «Выгрузить зону».
Запись типа A позволяет установить соответствие между именем хоста в домене и его IP-адресом.
Запись типа A имеет следующий формат:
имя_хоста [TTL] A IP-адрес
имя_хоста: доменное имя хоста (устройства), подключенного к Интернету, для которого данная запись определяет соответствие с его IP-адресом.
TTL: см. описание параметра TTL
А: тип записи
IP-адрес: IP-адрес хоста.
Обращаем ваше внимание на то, что у всех записей типа А, относящихся к одному имени хоста, значение TTL должно быть одинаковым.
или
Запись типа NS имеет следующий формат:
доменное_имя [TTL] NS имя_хоста
TTL: см. описание параметра TTL
NS: тип записи
имя_хоста: доменное имя DNS-сервера.
Обращаем ваше внимание на то, что у всех записей типа NS, относящихся к одному доменному имени, значение TTL должно быть одинаковым.
Если для делегирования некоторого домена в зону внесены NS-записи, то для этого доменного имени в данной зоне не может быть других типов записей, кроме glue-записей, если они нужны (см. RFC1034).
Запись типа MX (Mail Exchange — почтовый сервер) определяет почтовый сервер — машину, которая обрабатывает почту для вашего домена.
Запись типа MX имеет следующий формат:
доменное_имя [TTL] MX приоритет почтовый сервер
TTL: см. описание параметра TTL
MX: тип записи
приоритет: определяет значение приоритетности почтового сервера. Чем меньше число, тем выше приоритет почтового сервера (0 означает самый высокий приоритет, 65535 — самый низкий). Таким образом, почтовый сервер с более высоким приоритетом является основным, а почтовые серверы с более низкими приоритетами будут второстепенными и вступят в работу в том случае, если все более приоритетные серверы по каким-либо причинам недоступны или неработоспособны.
почтовый сервер: имя почтового сервера.
или
Обращаем ваше внимание на то, что у всех записей типа MX, относящихся к одному доменному имени, значение TTL должно быть одинаковым, то есть приведенные в примере записи не могут существовать одновременно.
Запись типа CNAME (Canonical Name — каноническое имя) позволяет присваивать хосту мнемонические имена. Мнемонические имена, или псевдонимы, широко применяются для связывания с хостом какой-либо функции, либо просто для сокращения имени.
Реальное имя иногда называют каноническим.
Если для хоста есть запись типа CNAME, которая содержит его мнемонические имена, другие записи для данного хоста должны ссылаться на его реальное (каноническое) имя, а не на мнемоническое. Когда программы DNS встречают запись CNAME, они прекращают свои запросы по мнемоническому имени и переключаются на реальное имя.
Кроме того, если данное имя использовано в качестве псевдонима, то на него нельзя занести записи любого другого типа.
Т.е. недопустима конструкция вида:
domain CNAME имя_хоста
domain MX 10 почтовый сервер
Мнемонические имена полезны, например, в случае, когда имя хоста изменилось, и вы хотите разрешить пользователям, знающим старое имя, получить доступ к хосту.
Запись типа CNAME имеет следующий формат:
мнемоимя [TTL] CNAME имя_хоста
Мнемоимя: мнемоническое имя хоста
TTL: см. описание параметра TTL
CNAME: тип записи
имя_хоста: каноническое имя хоста.
или
Запись типа AAAA позволяет установить соответствие между именем хоста в домене и его IPv6-адресом.
Запись типа AAAA имеет следующий формат:
имя_хоста [TTL] AAAA IPv6_адрес
имя_хоста: доменное имя хоста (устройства), подключенного к Интернету, для которого данная запись определяет соответствие с его IPv6-адресом.
TTL: см. описание параметра TTL
АAAA: тип записи
IPv6_адрес: IPv6-адрес хоста.
Обращаем ваше внимание на то, что у всех записей типа АAAA, относящихся к одному имени хоста, значение TTL должно быть одинаковым.
или
Записи типа PTR (Pointer — указатель) служат для выполнения обратного преобразования IP-адресов в имена хостов. Для каждого сетевого интерфейса хоста рекомендуется создать запись PTR.
Примечание: Если провайдер выделил вам несколько IP-адресов из своей сети, то по поводу записей в обратной зоне вам следует обращаться к нему.
Запись типа PTR имеет следующий формат:
адрес [TTL] PTR имя_хоста
адрес: преобразованный IP-адрес хоста
TTL: см. описание параметра TTL
PTR: тип записи.
Примеры PTR-записей
или
Записи типа SRV используются для поиска серверов, обеспечивающих работу тех или иных служб в данном домене.
С подробным описанием этого типа записей вы можете ознакомиться в RFC-2782.
Запись типа SRV имеет следующий формат:
_Service._Proto.Name [TTL] SRV Priority Weight Port Target
Service: название службы (пример: ldap, kerberos, gc и другие).
Proto: протокол, при помощи которого клиенты могут подключиться к данной службе (пример: tcp, udp).
Name: имя домена, в котором размещена данная служба.
TTL: см. описание параметра TTL.
SRV: тип записи.
Priority: приоритет данного сервера. Чем меньше число, тем выше приоритет (0 означает самый высокий приоритет, 65535 — самый низкий).
Weight: относительный вес для серверов с одинаковым приоритетом. Предназначен для распределения нагрузки между серверами, для которых указан равный приоритет.
Port: порт, на котором размещена указанная служба на данном сервере.
Target: доменное имя сервера, предоставляющего данную службу.
Примеры SRV-записей
или
Запись типа TXT обычно используется для текстового описания доменного имени.
Запись типа TXT имеет следующий формат:
имя [TTL] TXT текст
имя: имя домена или хоста
TTL: см. описание параметра TTL
TXT: тип записи
текст: одна или несколько текстовых строк, каждая из которых содержит не более 255 символов.
Примеры TXT-записи:
или
При добавлении или редактировании TXT-записи в интерфейсе редактора файлов зон:
- Если необходимо внести несколько текстовых строк, то они должны быть разделены переводом строки.
- Если в строке ввода более 255 символов, перевод строки осуществляется автоматически после 255-го символа.
- Не нужно указывать кавычки (символ ") в начале и конце текстовой строки. В файл зоны строка автоматически будет записана в стандартном для поля TXT-формате, т.е. с кавычками.
- Если в текстовой строке используются кавычки, то они будут автоматически экранированы.
Просмотр существующих ресурсных записей
Для просмотра ресурсных записей необходимо выбрать домен.
Перейти в раздел «Ресурсные записи»
После этого на странице откроется таблица со списком всех текущих ресурсных записей.
Добавление новых ресурсных записей
Для того чтобы добавить новую запись, нужно перейти в раздел «Ресурсные записи» зоны и нажать кнопку «Добавить новую запись».
Указать необходимые параметры добавляемой записи.
* Количество и набор задаваемых параметров различаются в зависимости от типа добавляемой записи
После того, как вы добавите новую зону, вам нужно выгрузить файл зоны для того, чтобы изменения вступили в силу. Для этого на этой же странице нажмите кнопку «Выгрузить зону».
Маски (символ "*") в записях файла зоны
DNS резервирует специальный символ, звездочку (*), для использования в файлах зоны в качестве части маски. Звездочка сопоставляется с любым числом меток в имени, за исключением тех случаев, когда запись для имени уже существует в базе данных DNS-сервера.
Место использования маски строго определено — это может быть только первый символ в поле имени текущего домена или имени хоста, отделенный от остальных символом ".".
Символ звездочка (*) недопустим в имени домена в левой части NS-записи.
Примеры использования масок:
Запись означает, что любое возможное имя хоста в домене domaintest.ru (например, "www.domaintest.ru", "mail.domaintest.ru", "anyname1.anyname2.domaintest.ru" и т.п.) будет соответствовать IP-адресу 194.123.1.1.
Диагностика сервера каталогов
Выполнение начальной настройки:
Выполняется попытка поиска основного сервера.
Основной сервер = dc1
* Идентифицирован лес AD.
Сбор начальных данных завершен.
Выполнение обязательных начальных проверок
Сервер проверки: Default-First-Site-Name\DC1
Запуск проверки: Connectivity
Узел 74d8d7c9-8301-4132-b5e5-78a77c40411f._msdcs.perrino.local не
удается разрешить в IP-адрес. Проверьте DNS-сервер, DHCP, имя сервера
и т. д.
Получена ошибка при проверке подключения LDAP и RPC. Проверьте
параметры брандмауэра.
. DC1 - не пройдена проверка Connectivity
Выполнение основных проверок
Сервер проверки: Default-First-Site-Name\DC1
Запуск проверки: DNS
Проверки DNS выполняются без зависания. Подождите несколько минут.
. DC1 - пройдена проверка DNS
Выполнение проверок разделов на: ForestDnsZones
Выполнение проверок разделов на: DomainDnsZones
Выполнение проверок разделов на: Schema
Выполнение проверок разделов на: Configuration
Выполнение проверок разделов на: perrino
Выполнение проверок предприятия на: perrino.local
Запуск проверки: DNS
Результаты проверки контроллеров домена:
Контроллер домена: dc1.perrino.local
Домен: perrino.local
TEST: Basic (Basc)
Ошибка: Невозможно подключение LDAP
Внимание! У адаптера
[00000007] HP Ethernet 1Gb 2-port 361i Adapter неверный
DNS-сервер: 192.168.15.2 (DC1)
Ошибка: все DNS-серверы недействительны
Не найдены записи узла (A или AAAA) для данного DC
Внимание! На данном сервере DC/DNS не найдена зона Active
Directory (возможно, из-за неверной настройки)
TEST: Forwarders/Root hints (Forw)
Ошибка. Корневые ссылки и серверы пересылки не настроены или
повреждены. Убедитесь, что хотя бы один из них работает.
TEST: Dynamic update (Dyn)
Warning: Failed to add the test record dcdiag-test-record in z
one perrino.local
TEST: Records registration (RReg)
Ошибка. Не удается найти регистрации записей для всех сетевых
адаптеров
Отчет о результатах проверки DNS-серверов, используемых приведенными
выше контроллерами домена:
DNS-сервер: 192.168.15.2 (DC1)
1 - проверка на данном DNS-сервере не пройдена
Name resolution is not functional. _ldap._tcp.perrino.local. fail
ed on the DNS server 192.168.15.2
Отчет по результатам проверки DNS:
Auth Basc Forw Del Dyn RReg Ext
_________________________________________________________________
Домен: perrino.local
dc1 PASS FAIL FAIL n/a WARN FAIL n/a
. perrino.local - не пройдена проверка DNS
DNS-сервер ожидает от доменных служб Active Directory (AD DS) сигнала о том, что первичная синхронизация каталога завершена. Службу DNS-сервера невозможно запустить до завершения первичной синхронизации, так как критические данные DNS могут быть еще не реплицированными на этот контроллер домена. Если журнал событий AD DS показывает, что имеются проблемы с разрешением DNS-имен в адреса, рассмотрите возможность добавления IP-адреса другого DNS-сервера для этого домена в список DNS-серверов в свойствах протокола IP этого компьютера. Такое событие будет записываться в журнал каждые две минуты, пока служба AD DS не сообщит об успешном завершении первичной синхронизации.
DNS-сервер BIND не смог загрузить доменную зону
Наиболее распространённая причина проблемы в том, что файл доменной зоны некорректный.
Для решения проблемы добавьте в файл доменной зоны A-записи:
Ресурсная запись CNAME не должна быть указана вместе с A-записью для одного поддомена:
Это приводит к ошибке вида:
Также обратите внимание, что CNAME-запись нельзя создать для доменов второго уровня.
Файлы и логи DNS-серверов
Логи BIND и PowerDNS
Диагностика первичного (master) DNS-сервера
Проверка возможности передачи доменной зоны от первичного сервера к вторичному
Ответ должен быть вида:
Частая причина проблемы: в файле доменной зоны DNS-сервера в allow-transfer ук азан приватный IP-адрес, который недоступен со вторичного сервера.
Диагностика вторичного (slave) DNS-сервера
Конфигурационный файл BIND
Не получается завести зону на DNS-сервере.
Не знаю что не так я сделал. Ниже показываю вывод некоторых команд. В качестве DNS-сервера используется BIND.
файл обратной зоны:
Хотя бы подскажите в какую сторону мне глядеть? Перечитал уже много информации, и на форуме тоже, но яснее от этого не стало, к сожалению. Ещё добавлю, что стоит Red Hat 4, и есть ещё зоны для локальной (офисной) сети, которые успешно работают (настраивал не я ).
Звонил интернет-провайдеру, который даёт интернет и IP-адреса серверов, спрашивал нет ли у них каких ограничивающих настроек, которые каким-либо образом влияли на мою проблему. Сказали что нет.
Включить логгирование ошибок и увидеть-таки где лажа с конфигом. В частности, в области определения зоны.
Bind какой версии?
Посморрел я Nslookup
Вроде отдается все.
Здравствуйте. Логгирование включил, таким путём:
А в логе named-auth.log все записи такие:
Читал мануал про эту ошибку и толком не понял что это такое, вот что в мануале написано про это:
5.1 'RRset exists (value dependent)' prerequisite not satisfied (NXRRSET) Problem: Some RRset that ought to exist, does not exist.
This message means what it says. The dynamic update request failed because a prerequisite condition - that some name or group of names (RRset) existed - did not hold. An NXRRSET error - no such RRset - was returned to the client making the request.
Версия BIND 9.2.2
Далее по-поводу nslookup. Сегодня я воспользовался named-checkconf, он пожаловался на кое-какие проблемы и я исправил их. Named-checkzone отрабатывает без ошибок. После этого команда
стала работать.
И я попробовал использовать nslookup, также как и вы, Indarien, но результат получился другой:
Попробуй все это сделать так,без обратной зоны.Если все заработает то прописывай алиасы и обратную зону.
Извините была ошибочка , отредактировал.
У меня bind в chroot находится ,
file "/var/named/vikingbank.ru"; это путь где находятся файлы с прямыми и обратными занами,тебе нужно их поменять.
Удивительно почему у тебя не работает, у меня вот так все прописано , все прекрасно работает..Если не трудно скинь лог пожалуйста посмотрю .И весь named.conf покажи.
А в логах нет ничего интересного, поэтому опять привожу их не полностью, поскольку все записи идентичные. Вот так выглядит named-auth.log:
А вот так named-update.log:
Прикрепляю сюда файл syslog после перезагрузки сервера с новыми настройками (не ругайтесь , только что делал. И ещё файл messages.
А дайте-ка плз ifconfig с пары машин.
1 - находящаяся внутри сети
2 - Находящаяся снаружи
И для каждой результаты nslookup.
И до кучи Ifconfig с самого сервака.
А вне сети у меня нет возможности. Ну если только попросить кого-нибудь, или я неправильно вас понимаю? Indarien, а вы же уже делали от себя?
А в логах у меня конечно есть записи с которыми нужно срочно что-то делать. Например, с файловой системой что-то не то, и прочее. Но пока с текущей проблемой не разберусь, другие не буду трогать, а то ещё новые проблемы наживу, вообще сервак полетит. Не дай бог.
Ребята, огромное спасибо за поиски решения, но пока что временный тайм-аут по этой теме, т.к. тот самый провайдер (ru-center) начал реагировать на изменения моих настроек и прислал мне письмо что мол теперь не получена SOA-запись со вторичного сервера имён. Теперь поразбираюсь с этим. Отпишусь как что.
yaleks, спасибо! Я сделал так, для надёжности всё указал явно:
Теперь наверное нужно подождать, посмотрим что на это скажет RU-Center.
А вне сети у меня нет возможности. Ну если только попросить кого-нибудь, или я неправильно вас понимаю? Indarien, а вы же уже делали от себя?
Я неправильно выразился, с наружи, но из той же сети обратится.
Я когда настраивал свой первый праймари были подобные проблемы, там затык был в правильном ACL, вернее в неправильном =), в моем случае.
Успехов Вам. =)
Indarien Я сделал nslookup из Windows в локальной сети. Не знаю насколько это информативно, но вот, гляньте:
Очередная попытка тестирования будет произведена через 3 часа.
Так пишет регистратор RU-Center. Что ещё плохо, это то что попытки он свои делает через целых 3 часа.
NS0 не отдает зону, все остальные нормально.
После удаления зоны случайно ждать не нужно?
Indarien, после того как я вчера удалил на xname.org зону vikingbank.ru, я пытался создать её вновь, но, как я уже написал, не получалось - действительно требуется подождать. Сегодня с утра получилось создать вновь, но опять ерунда какая-то: ns0.xname.org почему-то "not available", а ns1.xname.org откуда-то взял старое описание зоны - со старым серийным номером. Причём серийник зоны с моего name-сервера (217.195.83.66) - нормальный, последний (сегодня менял, запарился думал что сегодня 22-е число ). Однако при нажатии ссылки "zone content" напротив моего сервера, то выдаётся ошибка:
При возникновении проблем с DNS-сервером проведите диагностику первичного и вторичного DNS-сервера. В этой статье приведены способы диагностики и расположение основных конфигурационных и лог-файлов.
DNS-сервер не отдаёт доменную зону
Проверьте, что первичный DNS-сервер отдаёт зону :
— IP-адрес DNS-сервера, как правило, совпадает с основным IP-адресом сервера.
Ответ на запрос должен быть вида :
DNS-сервер не запущен или порт DNS (53) закрыт, если получен ответ вида:
Если получен пустой ответ, значит у DNS-сервера нет информации о домене. Возможно, он не смог загрузить доменную зону. В этом случае с мотрите лог.
Читайте также: