Как проверить dns сервер на ошибки

Зачастую, в силу того, что информация в сети распространяется не мгновенно, привязанные к серверу домены начинают работать не сразу. Чтобы не тратить время впустую, ожидая обновления кеша DNS, желательно сразу проверить настройку вашего DNS-сервера и убедиться, что по истечении 72 часов (это максимальное время обновления глобального кеша DNS) ваш домен заработает.

Первичная диагностика

Whois

Начать диагностику следует с запроса whois:

[root@dns ~]# whois firstvds.ru 
% By submitting a query to RIPN's Whois Service
% you agree to abide by the following terms of use:
% http://www.ripn.net/about/servpol.html#3.2 (in Russian)
% http://www.ripn.net/about/en/servpol.html#3.2 (in English).

domain:        FIRSTVDS.RU
nserver:       ns1.firstvds.ru. 82.146.43.2
nserver:       ns2.firstvds.ru. 94.250.248.160
state:         REGISTERED, DELEGATED, VERIFIED
org:           CJSC "Pervyj"
registrar:     REGTIME-REG-RIPN
admin-contact: http://whois.webnames.ru
created:       2002.08.07
paid-till:     2014.08.08
free-date:     2014.09.08
source:        TCI

Last updated on 2014.03.18 03:36:35 MSK

В данном примере мы видим, что домен проделегирован на сервера имен ns1.firstvds.ru. и ns2.firstvds.ru. с указанием IP-адресов (дочерние NS-сервера всегда прописываются с указанием IP). Это корректный вывод whois и примерно так должен выглядеть ответ whois для зарегистрированного и проделегированного домена. Исключение составляет IP, он указывается только для дочерних NS-серверов.

Также следует обратить внимание на пункты «state» и «Status» (для доменов в зонах .com./.org): в поле «state» обязательно должны быть пометки REGISTERED и DELEGATED, в поле «Status» — «Ok». Для отсеивания всего лишнего из вывода whois можно использовать следующую команду:

[root@dns ~]# whois firstvds.ru | grep -Ei 'name server|nserver|state|status'
nserver:       ns1.firstvds.ru. 82.146.43.2
nserver:       ns2.firstvds.ru. 94.250.248.160
state:         REGISTERED, DELEGATED, VERIFIED

[root@dns ~]# whois ispserver.com | grep -Ei 'name server|nserver|state|status'
   Name Server: NS1.ISPVDS.COM
   Name Server: NS2.ISPVDS.COM
   Status: ok
Domain Status: ok
Name Server: NS1.ISPVDS.COM
Name Server: NS2.ISPVDS.COM

Замечание: для доменов в зоне .com/.org следует обращать внимание только на первые две записи «Name Server».

Если домен не зарегистрирован или зарегистрирован недавно, можно увидеть такую картину:

[root@dns ~]# whois fvdstest.ru
% By submitting a query to RIPN's Whois Service
% you agree to abide by the following terms of use:
% http://www.ripn.net/about/servpol.html#3.2 (in Russian)
% http://www.ripn.net/about/en/servpol.html#3.2 (in English).

No entries found for the selected source(s).

Last updated on 2014.03.18 03:46:37 MSK

Информация во whois может обновляться в течение трех часов, поэтому если вы уже приобрели домен, нужно некоторое время подождать. Это также касается смены NS-серверов домена.

dig +trace

dig — утилита, предоставляющая пользователю интерфейс командной строки для отправки запросов к DNS-серверам. Первый запрос, который нас интересует, — трассировка запросов к домену:

[root@dns ~]# dig firstvds.ru +trace

; <<>> DiG 9.8.1-P1 <<>> firstvds.ru +trace
;; global options: +cmd
.                       10045   IN      NS      l.root-servers.net.
.                       10045   IN      NS      h.root-servers.net.
.                       10045   IN      NS      a.root-servers.net.
.                       10045   IN      NS      i.root-servers.net.
.                       10045   IN      NS      g.root-servers.net.
.                       10045   IN      NS      d.root-servers.net.
.                       10045   IN      NS      j.root-servers.net.
.                       10045   IN      NS      m.root-servers.net.
.                       10045   IN      NS      c.root-servers.net.
.                       10045   IN      NS      b.root-servers.net.
.                       10045   IN      NS      e.root-servers.net.
.                       10045   IN      NS      f.root-servers.net.
.                       10045   IN      NS      k.root-servers.net.
;; Received 228 bytes from 8.8.8.8#53(8.8.8.8) in 2311 ms

ru.                     172800  IN      NS      e.dns.ripn.net.
ru.                     172800  IN      NS      f.dns.ripn.net.
ru.                     172800  IN      NS      b.dns.ripn.net.
ru.                     172800  IN      NS      d.dns.ripn.net.
ru.                     172800  IN      NS      a.dns.ripn.net.
;; Received 341 bytes from 192.36.148.17#53(192.36.148.17) in 934 ms

firstvds.ru.            345600  IN      NS      ns1.firstvds.ru.
firstvds.ru.            345600  IN      NS      ns2.firstvds.ru.
;; Received 97 bytes from 193.232.156.17#53(193.232.156.17) in 548 ms

firstvds.ru.            3600    IN      A       195.211.221.106
;; Received 45 bytes from 94.250.248.160#53(94.250.248.160) in 71 ms

Здесь мы видим, что сперва были опрошены корневые сервера имен, которые направили запрос на сервера зоны .ru, которые, в свою очередь, отправили его на сервера, отвечающие за зону firstvds.ru, и с них был получен IP-адрес домена. Тут могут быть различные варианты, например:

[root@dns ~]# dig firstvds.ru +trace

; <<>> DiG 9.8.1-P1 <<>> firstvds.ru +trace
;; global options: +cmd
.                       10045   IN      NS      l.root-servers.net.
.                       10045   IN      NS      h.root-servers.net.
.                       10045   IN      NS      a.root-servers.net.
.                       10045   IN      NS      i.root-servers.net.
.                       10045   IN      NS      g.root-servers.net.
.                       10045   IN      NS      d.root-servers.net.
.                       10045   IN      NS      j.root-servers.net.
.                       10045   IN      NS      m.root-servers.net.
.                       10045   IN      NS      c.root-servers.net.
.                       10045   IN      NS      b.root-servers.net.
.                       10045   IN      NS      e.root-servers.net.
.                       10045   IN      NS      f.root-servers.net.
.                       10045   IN      NS      k.root-servers.net.
;; Received 228 bytes from 8.8.8.8#53(8.8.8.8) in 2311 ms

ru.                     172800  IN      NS      e.dns.ripn.net.
ru.                     172800  IN      NS      f.dns.ripn.net.
ru.                     172800  IN      NS      b.dns.ripn.net.
ru.                     172800  IN      NS      d.dns.ripn.net.
ru.                     172800  IN      NS      a.dns.ripn.net.
;; Received 341 bytes from 192.36.148.17#53(192.36.148.17) in 934 ms

firstvds.ru.            345600  IN      NS      ns1.oldfirstvds.ru.
firstvds.ru.            345600  IN      NS      ns2.oldfirstvds.ru.
;; Received 97 bytes from 193.232.156.17#53(193.232.156.17) in 548 ms

firstvds.ru.            3600    IN      A       188.120.252.3
;; Received 45 bytes from 94.250.248.160#53(94.250.248.160) in 71 ms

Здесь мы видим несоответствие NS-серверов, на которые проделегирован домен, и тех, на которые указывают сервера зоны .ru (ns1.oldfirstvds.ru. и ns2.oldfirstvds.ru.).

Еще вариант:

[root@dns ~]# dig firstvds.ru +trace

; <<>> DiG 9.8.1-P1 <<>> firstvds.ru +trace
;; global options: +cmd
.                       9554    IN      NS      i.root-servers.net.
.                       9554    IN      NS      b.root-servers.net.
.                       9554    IN      NS      c.root-servers.net.
.                       9554    IN      NS      k.root-servers.net.
.                       9554    IN      NS      e.root-servers.net.
.                       9554    IN      NS      h.root-servers.net.
.                       9554    IN      NS      d.root-servers.net.
.                       9554    IN      NS      f.root-servers.net.
.                       9554    IN      NS      l.root-servers.net.
.                       9554    IN      NS      g.root-servers.net.
.                       9554    IN      NS      m.root-servers.net.
.                       9554    IN      NS      j.root-servers.net.
.                       9554    IN      NS      a.root-servers.net.
;; Received 228 bytes from 8.8.8.8#53(8.8.8.8) in 2399 ms

ru.                     172800  IN      NS      a.dns.ripn.net.
ru.                     172800  IN      NS      b.dns.ripn.net.
ru.                     172800  IN      NS      d.dns.ripn.net.
ru.                     172800  IN      NS      e.dns.ripn.net.
ru.                     172800  IN      NS      f.dns.ripn.net.
;; Received 341 bytes from 128.63.2.53#53(128.63.2.53) in 1061 ms

ru.                     3600    IN      SOA     a.dns.ripn.net. hostmaster.ripn.net. 4021899 86400 14400 2592000 3600
;; Received 90 bytes from 193.232.128.6#53(193.232.128.6) in 78 ms

Сервера зоны .ru ничего не знают об NS-серверах, обслуживающих зону запрашиваемого домена. Последние два случая могут быть обусловлены как проблемами в работе DNS, так и тем, что информация о домене еще не обновилась на корневых серверах имен, поэтому потребуется дальнейшая диагностика.

dig с NS-серверов

В этом случае мы запрашиваем информацию напрямую с NS-серверов, которые планируется использовать для указанного домена. Пример для запроса с ns1 (для ns2 запрос выглядит аналогично):

[root@dns ~]# dig firstvds.ru @ns1.firstvds.ru.

; <<>> DiG 9.8.1-P1 <<>> firstvds.ru @ns1.firstvds.ru.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39440
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;firstvds.ru.                   IN      A

;; ANSWER SECTION:
firstvds.ru.            3600    IN      A       195.211.221.106

;; Query time: 67 msec
;; SERVER: 82.146.43.2#53(82.146.43.2)
;; WHEN: Tue Mar 18 09:30:41 2014
;; MSG SIZE  rcvd: 45

Здесь в секции ANSWER SECTION был возвращен IP, в который NS-сервер резолвит домен, при нормальной работе этот IP должны возвращать оба NS-сервера, если IP отличается от того, что вы назначили домену на основном сервере, то зона нуждается в обновлении. В ISPmanager, к примеру, это можно сделать кнопкой «Передать» в разделе «Доменные имена», если же у вас DNS-сервер настроен без использования панели, то зона, как правило, будет обновлена самостоятельно, либо по истечении TTL зоны, либо по запросу вторичного сервера имен, если используется механизм уведомлений (опция notify yes в BIND).

Также NS-сервер может вообще не ответить:

[root@dns ~]# dig fvdstest.ru @ns1.firstvds.ru.

; <<>> DiG 9.8.1-P1 <<>> firstvds.ru @ns1.firstvds.ru
;; global options: +cmd
;; connection timed out; no servers could be reached

В этом случае следует убедиться, что внешний DNS-сервер доступен и на нем не заблокирован 53-й порт (если есть такая возможность).

Еще один вариант — пустой ответ:

[root@dns ~]# dig fvdstest.ru @ns1.firstvds.ru.

; <<>> DiG 9.8.1-P1 <<>> fvdstest.ru @ns1.firstvds.ru.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35308
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;fvdstest.ru.                   IN      A

;; Query time: 123 msec
;; SERVER: 82.146.43.2#53(82.146.43.2)
;; WHEN: Tue Mar 18 09:41:57 2014
;; MSG SIZE  rcvd: 29

Также при возникновении каких-либо проблем на NS-серверах следует произвести диагностику первичного DNS-сервера.

dig с первичного сервера имен

Служит для запроса информации непосредственно с сервера, на котором создан домен:

[root@dns ~]# dig firstvds.ru @188.120.241.90

; <<>> DiG 9.7.1-P2 <<>> firstvds.ru @188.120.241.90
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26391
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;firstvds.ru.            IN    A

;; ANSWER SECTION:
firstvds.ru.        3600    IN    A    188.120.241.90

;; AUTHORITY SECTION:
firstvds.ru.        3600    IN    NS    ns1.firstvds.ru.
firstvds.ru.        3600    IN    NS    ns2.firstvds.ru.

;; ADDITIONAL SECTION:
ns1.firstvds.ru.    3600    IN    A    82.146.43.2
ns2.firstvds.ru.    3600    IN    A    82.146.35.143

;; Query time: 71 msec
;; SERVER: 188.120.241.90#53(188.120.241.90)
;; WHEN: Thu Apr 14 15:12:51 2011
;; MSG SIZE  rcvd: 113

Приведенный вариант — то, как должен отвечать правильно настроенный DNS-сервер, в случае возникновения проблем следует перейти к более детальному изучению обстановки на корневом сервере имен.

Проблемы и решения

Вся необходимая для диагностики информация о проблемах, возникшим в работе первичного сервера имен, содержится в логах. По умолчанию DNS-сервер пишет в системный лог /var/log/messages, однако в конфигурации может быть задано ведение логов в отдельном файле, поэтому следует свериться с конфигурацией вашего DNS-сервера. В этом разделе рассмотрены наиболее часто встречающиеся в логах ошибки.

dig возвращает пустой ответ

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

Некорректные права/владелец

Первая ошибка, которую мы рассмотрим — permission denied:

Mar 17 05:53:58 fvds named[19765]: zone fvdstest.com/IN: loading from master file /etc/bind/fvdstest.com failed: permission denied
Mar 17 05:53:58 fvds named[19765]: zone fvdstest.com/IN: not loaded due to errors.

Ошибка говорит о некорректных правах на файл зоны или о некорректном владельце файла:

[root@dns ~]# ls -l /etc/bind/fvdstest.com
-rw-r----- 1 root root 444 Mar 17 05:50 /etc/bind/fvdstest.com

В данном случае проблема именно с владельцем, им должен быть пользователь, от которого запущен bind:

[root@dns ~]# ls -l /etc/bind/fvdstest.com
-rw-r----- 1 bind bind 444 Mar 17 05:50 /etc/bind/fvdstest.com

Также следует обратить внимание на права и группу самой директории /etc/bind/:

[root@dns ~]# ls -ld /etc/bind/
drwxr-sr-x 2 root bind 4096 Mar 15 18:42 /etc/bind

Отсутствие A-записей для дочерних NS

Следующая ошибка в логе:

Mar 17 05:56:55 fvds named[19933]: zone fvdstest.com/IN: NS 'ns1.fvdstest.com' has no address records (A or AAAA)
Mar 17 05:56:55 fvds named[19933]: zone fvdstest.com/IN: NS 'ns2.fvdstest.com' has no address records (A or AAAA)
Mar 17 05:56:55 fvds named[19933]: zone fvdstest.com/IN: not loaded due to errors.

Проблема в том, что в NS-записях указаны дочерние домены третьего уровня, для которых отсутствует A-запись: ‘ns1.fvdstest.com’ и ‘ns2.fvdstest.com’, соответственно, нужно либо указать другие, уже настроенные на другом домене, NS-сервера, либо прописать соответствующие A-записи:

ns1     IN      A       10.10.10.10
ns2     IN      A       11.11.11.11

CNAME и другие записи

Еще одна достаточно распространенная ошибка:

Mar 17 06:08:39 fvds named[20701]: zone fvdstest.com/IN: loading from master file /etc/bind/fvdstest.com failed: CNAME and other data
Mar 17 06:08:39 fvds named[20701]: zone fvdstest.com/IN: not loaded due to errors.

Записи A и CNAME не могут одновременно сосуществовать для одного домена/поддомена:

test.fvdstest.com.   IN      A       10.10.10.10
test.fvdstest.com.   IN      CNAME   google.com

После устранения всех ошибок в логе должна появиться следующая запись:

Mar 17 06:13:12 fvds named[20914]: zone fvdstest.com/IN: loaded serial 2014022800

Однако, даже после этого мы можем получить пустой ответ на запрос утилитой dig. Тут вариантов не так много:

Отсутствие A-записи

По умолчанию утилита dig запрашивает именно A-запись домена, поэтому пустой ответ может означать, что эта запись отсутствует. Пример A-записи:

fvdstest.com.   IN      A       10.10.10.10

Тут стоит отметить, что в некоторых случаях необходимости в A-записи нет, и чтобы проверить, как отдается та или иная запись, нужно сообщить утилите dig тип запрашиваемой записи:

[root@dns ~]# dig fvdstest.com @188.120.234.14 MX

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> fvdstest.com @10.10.10.10 MX
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47888
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 3

;; QUESTION SECTION:
;fvdstest.com.                  IN      MX

;; ANSWER SECTION:
fvdstest.com.           3600    IN      MX      10 mail.fvdstest.com.
fvdstest.com.           3600    IN      MX      20 mail.fvdstest.com.

;; AUTHORITY SECTION:
fvdstest.com.           3600    IN      NS      ns2.fvdstest.com.
fvdstest.com.           3600    IN      NS      ns1.fvdstest.com.

;; ADDITIONAL SECTION:
mail.fvdstest.com.      3600    IN      A       123.123.123.123
ns1.fvdstest.com.       3600    IN      A       10.10.10.10
ns2.fvdstest.com.       3600    IN      A       11.11.11.11

;; Query time: 1 msec
;; SERVER: 188.120.234.14#53(188.120.234.14)
;; WHEN: Mon Mar 17 08:30:16 2014
;; MSG SIZE  rcvd: 151

Замечание: для получения всех записей можно указать тип ANY, также полезным будет ключ +short, позволяющий выводить сокращенный ответ:

[root@dns ~]# dig fvdstest.com @10.10.10.10 +short ANY
"v=spf1 ip4:123.123.123.123 a mx ~all"
fvds.com. root.fvds.com. 2014022800 10800 3600 604800 86400
ns1.fvdstest.com.
ns2.fvdstest.com.
20 mail.fvdstest.com.
10 mail.fvdstest.com.
123.123.123.123

Запрещены запросы к DNS-серверу

В конфигурации DNS-сервера могут быть разрешены запросы только с определенных адресов (как правило, разрешаются запросы только со slave-сервера). В случае с DNS-сервером BIND это директива allow-query{}. В этом случае мы увидим в логе следующую запись:

Mar 17 06:29:22 fvds named[21971]: client 188.120.234.14#49834: query 'fvdstest.com/A/IN' denied

Вариантов диагностики в этом случае два: либо временно добавить свой адрес в список разрешенных, либо делать запросы непосредственно с сервера, на котором расположен slave. Если slave настроен так, чтобы делать запросы не с основного IP на интерфейсе, утилите dig нужно будет указать ключ «-b xxx.xxx.xxx.xxx», где xxx.xxx.xxx.xxx – IP на интерфейсе, с которого разрешены запросы к master:

[root@dns ~]# dig fvdstest.com @188.120.234.14 +short -b 188.120.234.14 ANY
"v=spf1 ip4:123.123.123.123 a mx ~all"
fvds.com. root.fvds.com. 2014022800 10800 3600 604800 86400
ns1.fvdstest.com.
ns2.fvdstest.com.
20 mail.fvdstest.com.
10 mail.fvdstest.com.
123.123.123.123

Connection timed out

[root@dns ~]# dig fvdstest.com
; <<>> DiG 9.7.1-P2 <<>> fvdstest.com @10.10.10.10
;; global options: +cmd
;; connection timed out; no servers could be reached

Данный вывод говорит о том, что на сервере, с которого производится запрос информации о доменном имени, возникли проблемы. Это может быть как неработающий named, так и блокировка 53 порта с помощью файрвола.

Transfer failed

[root@dns ~]# dig fvdstest.com @10.10.10.10 AXFR
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> fvdstest.com @10.10.10.10 AXFR
;; global options: +cmd
; Transfer failed.

Mar 17 07:18:51 fvds named[23074]: client 188.120.234.14#50652: zone transfer 'fvdstest.com/AXFR/IN' denied

Эта ошибка говорит о том, что в конфигурации DNS-сервера запрещен трансфер зоны на адрес, с которого пришел запрос (директива allow-transfer{} в BIND). В плане диагностики проблема идентична ситуации с ограничением на запросы.

Отсутствие закрывающей точки

Иногда в ответе dig можно наблюдать такую картину

[root@dns ~]#
; <<>> DiG 9.7.1-P2 <<>> <domain> @<IP-адрес VDS>
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1253
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;<domain>.        IN    A

;; ANSWER SECTION:
<domain>.    3600    IN    A    123.123.123.123

;; AUTHORITY SECTION:
<domain>.    3600    IN    NS    ns2.firstvds.ru.<domain>.
<domain>.    3600    IN    NS    ns1.firstvds.ru.<domain>.

;; Query time: 70 msec
;; SERVER: 92.63.103.212#53(92.63.103.212)
;; WHEN: Fri Apr 15 15:49:16 2011
;; MSG SIZE  rcvd: 97

Проблема заключается в том, что при создании доменного имени были указаны некорректные сервера имен. Конкретно в данном случае пропущена закрывающаяся точка в доменном имени ns1.firstvds.ru.

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

Как только вы зарегистрировали доменное имя, оно начинает обслуживаться DNS-сервером, и любое обращение к домену по имени проходит через него. С момента привязки доменного имени к DNS-серверу может пройти до 72 часов, чтобы домен начал работать. Если по истечении этого срока домен не заработал или возникла ситуация, когда работающий домен перестал отвечать на запросы, проведите быструю диагностику DNS.

С чего начать?

Используйте утилиту whois для первичной диагностики DNS. Актуально для Linux-систем.

Выполните команду:

whois ispserver.ru

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

Whois выводит информацию о домене, в данном примере — ispserver.ru. Серверы имен, которые обслуживают домен — ns1.ispvds.com, ns2.ispvds.com — это первичный и вторичный DNS-серверы. На ns1.ispvds.com вносятся изменения зоны ispserver.ru, ns2.ispvds.com периодически синхронизирует свои записи с первичным DNS-сервером. В случае дочерних DNS-серверов (расположенных на самом делегируемом домене) в выводе whois рядом с именем сервера имен указывается его IP-адрес.

Строка с меткой “state:” обозначает статус, в котором находится домен. REGISTERED и DELEGATED в этой строке указывают на то, что домен зарегистрирован и делегирован.

Для получения краткой информации о домене используйте команду whois с параметрами:

whois ispserver.ru | grep -Ei 'name server|nserver|state'

Если домен не зарегистрирован (такого домена не существует), то ответ на whois будет следующим:

Используйте утилиту dig для обращения из командной строки к серверу DNS. Выполните трассировку маршрута пакетов к DNS-серверу командой:

dig ispserver.ru +trace

Первые 13 строк, начинающиеся со знака “.”, обозначают, что сначала были опрошены серверы имен корневой зоны, затем было сделано перенаправление на зону .ru (строки, начинающиеся с “.ru”), а затем запрос был отправлен на серверы имен домена ispserver.ru — ns1.ispvds.com, ns2.ispvds.com. Предпоследняя строка указывает на то, что серверы имен передали IP-адрес домена ispserver.ru в ответ на запрос.

Если при трассировке на каком-то шаге передача запроса происходит не на нужный DNS-сервер (например, серверы зоны .ru не перенаправляют пакет на серверы ns1.ispvds.com, ns2.ispvds.com), это означает, что информация о домене либо еще не обновилась, либо появились какие-то проблемы при работе DNS-сервера.

Опросите конкретный DNS-сервер, обслуживающий ваш домен, командой

dig ispserver.ru ns1.ispvds.ru

Секция ANSWER SECTION содержит IP-адрес, возвращенный DNS-сервером. Этот IP должен совпадать с тем, который вы назначали домену. Если он отличается, обновите доменную зону или подождите, пока она обновится автоматически. Все DNS-серверы должны возвращать один и тот же IP-адрес для домена.

Ошибка “Connection timed out”

Если в ответ на команду dig вы получаете сообщение “Connection timed out”, это означает, что DNS-сервер не отвечает.

Проверьте, доступен ли DNS-сервер и открыт ли на нем 53 порт.

Опросите первичный сервер имен командой

dig ispserver.ru <IP-адрес>

где IP-адрес - IP сервера, на котором расположен домен.

При правильной работе DNS должен выводиться корректный IP-адрес домена.

Решение основных проблем с DNS

Описание всех возникших проблем DNS-сервера читайте в лог-файле DNS, который по умолчанию находится по следующему пути: /var/log/messages. Расположение может быть изменено в зависимости от настроек вашего сервера. Через ISPmanager лог-файл можно просмотреть через “Менеджер файлов”.

Далее описаны наиболее часто возникающие проблемы DNS, которые можно обнаружить командой dig или в лог-файле.

Пустой ответ на команду dig

Под пустым ответом на команду dig понимается отсутствие секции ANSWER в выводе.

Как правило, причинами такого ответа могут быть:

• не существует такого доменного имени;
• домен не зарегистрирован на VPS;
• не создана А-запись для домена.

Проверьте, зарегистрирован ли домен на сервере. Зайдите в ISPmanager в раздел “Сайты” и убедитесь, что в списке существует запись вашего доменного имени. В данном примере это isptest.com, которого в списке нет. Нажмите на кнопку “Создать сайт” и создайте новый сайт.

Если у вас нет панели управления ISPmanager, проверьте, есть ли файл зоны домена, вручную.

Удостоверьтесь, что на сервере для вашего домена корректно созданы А-записи. Зайдите в ISPmanager в раздел “Управление DNS”. Выделите домен и нажмите кнопку “Управлять DNS записями”.

Среди ресурсных записей найдите А-запись и удостоверьтесь, что каждая запись содержит значение IP-адрес сервера, на котором расположен домен. В обратном случае исправьте несоответствия или создайте записи заново.

Если вы не используете панель управления ISPmanager, выполните проверки вручную на сервере. Пример А-записи в конфигурационном файле named.conf:

ispserver.com.   IN      A       10.10.10.10

Ошибка “Permission denied”

Следующая запись лог-файле DNS означает, что были неправильно назначены права на файл зоны или владелец файла /etc/bind/ispsrv.com

Oct 12 15:23:50 ispsrv named[18761]: zone ispsrv.ru/IN: loading from master file /etc/bind/ispsrv.com failed: permission denied

Oct 12 15:23:50 ispsrv named[18761]: zone ispsrv.ru/IN: not loaded due to errors.

Удостоверьтесь, что служба bind запущена от имени того же пользователя, что и владелец файла ispsrv.com. Выполните команду

[root@dns ~]# ls -l /etc/bind/ispsrv.com -rw -r

Следующий результат этой команды говорит о том, что владельцем /etc/bind/ispsrv.com является суперпользователь root:

1 root root 444 Oct 12 16:00 /etc/bind/fvdstest.com

Также проверьте права на саму папку /etc/bind/ командой:

[root@dns ~]# ls -ld /etc/bind/ drwxr-sr-x

Следующий результат указывает на то, что директория доступна пользователям root и bind:

2 root bind 4096 Oct 12 16:07 /etc/bind

Ошибка “No address records (A or AAAA)”

Следующие строки в лог-файле DNS означают, что ресурсная А-запись отсутствует для дочернего NS:

Oct 12 15:23:50 ispsrv ds named[19931]: zone ispsrv.ru/IN: NS 'ns1.ispsrv.com' has no address records (A or AAAA)

Oct 12 15:23:50 ispsrv named[19931]: zone ispsrv.ru/IN: NS 'ns2.ispsrv.com' has no address records (A or AAAA)

Oct 12 15:23:50 ispsrv named[19931]: zone ispsrv.ru/IN: not loaded due to errors.

В данном случае для DNS-серверов ns1.ispsrv.com и ns2.ispsrv.com отсутствуют А-записи. Сделайте следующие записи в фале named.conf:

ns1     IN      A       10.10.10.10

ns2     IN      A       11.11.11.11

Ошибка “CNAME and other data”

Следующие строки в лог-файле DNS означают, что для одного домена прописаны одновременно А и CNAME ресурсные  записи:

Oct 12 16:13:30 ispsrv named[20701]: zone ispsrv.ru/IN: loading from master file /etc/bind/fvdstest.com failed: CNAME and other data

Oct 12 16:13:30 ispsrv named[20701]: zone ispsrv.ru/IN: not loaded due to errors.

Конфликт вызывает запись вида:

ispsrv.com.   IN      A       10.10.10.10

ispsrv.com.   IN      CNAME   isptest.com

Оставьте только одну необходимую запись.

Ошибка “Query denied”

Следующие строки в лог-файле DNS означают, что ваш запрос к DNS-серверу запрещен:

Oct 12 16:53:03 ispsrv named[03771]: client 188.120.234.14#49834: query ‘ispsrv.com/A/IN’ denied

А таком случае DNS-сервер возможно настроен так, что запросы к нему разрешены только от дочернего DNS (slave).

Ошибка “Transfer failed”

Следующие строки в лог-файле DNS означают, что в конфигурации DNS запрещен трансфер на данный IP-адрес зоны домена:

Oct 12 17:13:13 ispsrv named[83374]: client 188.126.231.143#50652: zone transfer ispsrv.com/AXFR/IN' denied

Команда dig указывает на эту ошибку следующим ответом:

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> ispsrv.com @10.10.10.10 AXFR

;; global options: +cmd

; Transfer failed.

Ошибка в синтаксисе

Если вы случайно допустили синтаксическую ошибку в конфигурации файла доменной зоны, то в ответе на команду dig появятся не ожидаемые вами обозначения. Например,

;; QUESTION SECTION:

;<domain>.        IN    A

;; ANSWER SECTION:

<domain>.    3600    IN    A    123.123.123.123

;; AUTHORITY SECTION:

<domain>.    3600    IN    NS    ns2.ispsrv.ru.<domain>.

<domain>.    3600    IN    NS    ns1.ispsrv.ru.<domain>.

<domain> означает, что после ns1.ispsrv.ru не поставлена точка. Исправьте ошибку, поставив закрывающую точку: ns1.ispsrv.ru.

Во время интернет-серфинга пользователи часто встречаются с ошибкой «DNS-сервер не отвечает» при открытии сайтов. Что делать в таких ситуациях и как исправить проблему — расскажем в этой статье.

Каждый сайт в интернете обладает уникальным адресом. Для пользователя он представлен в виде осмысленного набора букв, например, yandex.ru, но в глобальной сети используется цифровое значение для обозначения веб-ресурсов. Его называют IP-адрес и он может выглядеть следующим образом: 176.108.10.5.

Разумеется, пользователям удобнее запоминать буквы, чем цифры, поэтому существует DNS-сервер, который отвечает за транслирование IP-адреса в символы и наоборот. И если при обращении к странице появляется текст «DNS-сервер не отвечает», значит запрос пользователя не был корректно транслирован.

Причины появления

Причины, по которым возникает такая ошибка, могут быть двух разновидностей:

1. Проблема на стороне провайдера: возможно, DNS-сервер недоступен, отключили электричество, проводятся технические работы и др.

2. Проблема на стороне пользователя: отключен интернет, сбросились параметры роутера, проблемы с драйверами и т.д.

Как решить проблему

Прежде чем приступать к решению, определим, на каком этапе проявляется ошибка, связанная с недоступностью адресов DNS-сервера.

Проблема с роутером

Важно! После обновления роутер необходимо перезагрузить.

Смена DNS-адреса

Важно! Так как ручная настройка DNS-сервера на Windows 7, 8 и 10 аналогична, расскажем об этом на примере одной из версий этих ОС.

Важно! Обязательно указывайте альтернативный адрес. Если предпочитаемый адрес окажется недоступен, обращение пойдет к альтернативному.

Проверка службы DNS

Обнуление кэша

ipconfig /flushdns
ipconfig /registerdns
ipconfig /renew
ipconfig /release

Настройка антивируса

Общение с интернет-провайдером

Вам также может быть интересно

• DNS для домена бесплатно
• Как делегировать домен на сервер
• Всё про DNS-сервисы

191028
Санкт-Петербург
Литейный пр., д. 26, Лит. А

+7 (812) 403-06-99

ООО «ИТГЛОБАЛКОМ ЛАБС»

191028
Санкт-Петербург
Литейный пр., д. 26, Лит. А

+7 (812) 403-06-99

ООО «ИТГЛОБАЛКОМ ЛАБС»