Не заслуживающий доверия ответ nslookup как исправить

Не заслуживающий доверия ответ nslookup как исправить

  • Remove From My Forums

  • Вопрос

  • C:Usersv.DESKTOP>nslookup
    ╤хЁтхЁ яю єьюыўрэш■: google-public-dns-a.google.com
    Address: 8.8.8.8
    > set norecurse
    > set type=any
    > .
    ╤хЁтхЁ: google-public-dns-a.google.com
    Address: 8.8.8.8
    Не заслуживающий доверия ответ:
    (root) ??? unknown type 48 ???
    (root) ??? unknown type 48 ???
    (root) ??? unknown type 48 ???
    (root) ??? unknown type 46 ???
    (root) ??? unknown type 47 ???
    (root) ??? unknown type 46 ???
    (root) nameserver = a.root-servers.net
    (root) nameserver = b.root-servers.net
    (root) nameserver = c.root-servers.net
    (root) nameserver = d.root-servers.net
    (root) nameserver = e.root-servers.net
    (root) nameserver = f.root-servers.net
    (root) nameserver = g.root-servers.net
    (root) nameserver = h.root-servers.net
    (root) nameserver = i.root-servers.net
    (root) nameserver = j.root-servers.net
    (root) nameserver = k.root-servers.net
    (root) nameserver = l.root-servers.net
    (root) nameserver = m.root-servers.net
    (root) ??? unknown type 46 ???
    (root)
    primary name server = a.root-servers.net
    responsible mail addr = nstld.verisign-grs.com
    serial = 2019033001
    refresh = 1800 (30 mins)
    retry = 900 (15 mins)
    expire = 604800 (7 days)
    default TTL = 86400 (1 day)
    (root) ??? unknown type 46 ???

Ответы

  • Потому что вы подали запрос серверу DNS(8.8.8.8), который не является полномочным для тех записей, которые он вернул в ответе (ссылки на корневые серверы DNS).

    Вот если бы вы подали такой же запрос на один из тех серверов, которые  получили в ответе (список полномочных серверов для корневой зоны DNS), то (скорее всего 😉 ) получили бы от него ответ, “заслуживающий доверия” (в оригинале -authoritative,
    в данном случае более правильный перевод – “полномочный”).

    Слава России!

    • Помечено в качестве ответа

      6 апреля 2019 г. 16:44

  • возможно потому что вы используете публичные днс вместо доменных?

    The opinion expressed by me is not an official position of Microsoft

    • Помечено в качестве ответа
      Vasya1395
      6 апреля 2019 г. 16:44

  • Я отправил запрос к публичному dns серверу google ,чтобы узнать ip адрес корневого сервера dns a.root-servers.net

    Microsoft Windows [Version 10.0.17763.404]
    (c) Корпорация Майкрософт (Microsoft Corporation), 2018. Все права защищены.

    C:Usersv.DESKTOP>nslookup
    ╤хЁтхЁ яю єьюыўрэш■:  google-public-dns-a.google.com
    Address:  8.8.8.8

    > a.root-servers.net
    ╤хЁтхЁ:  google-public-dns-a.google.com
    Address:  8.8.8.8

    Не заслуживающий доверия ответ:
    ╚ь :     a.root-servers.net
    Addresses:  2001:503:ba3e::2:30

    Как мне выяснить ip адрес корневого dns сервера a.root-servers.net,чтобы ответ от dns сервера,который прописан в настройках моего сетевого подключения (публичный dns google) я получил заслуживающий доверия ответ?         
      

    Никак. Вам уже объяснили выше почему. 

    This posting is provided “AS IS” with no warranties, and confers no rights.

    • Помечено в качестве ответа
      Vasya1395
      6 апреля 2019 г. 18:50

Источник

Время на прочтение
3 мин

Количество просмотров 81K

image

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

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

Естественно, я сразу проверил регистрацию домена, что показало, что домен активен, проплачен до следующего года и делегирован на DNS-сервера регистратора. Начал делать запросы по всем доступным dns-серверам:

Запрос на собственные DNS-сервера:

Z:>nslookup ufsin45.ru
╤хЁтхЁ:  serv.domain.local
Address:  10.45.15.249

Не заслуживающий доверия ответ:
╚ь :     ufsin45.ru
Address:  85.249.4.35

Запрос на корневой а-сервер:

Z:>nslookup ufsin45.ru a.dns.ripn.net
128.232.193.in-addr.arpa        nameserver = int3.dns.ripn.net
128.232.193.in-addr.arpa        nameserver = ns.relarn.ru
128.232.193.in-addr.arpa        nameserver = int2.dns.ripn.net
int2.dns.ripn.net       internet address = 195.209.10.37
int3.dns.ripn.net       internet address = 194.226.76.90
int3.dns.ripn.net       AAAA IPv6 address = 2001:6d0:ffd9:316:194:226:29:50
╤хЁтхЁ:  UnKnown
Address:  193.232.128.6

╚ь :     ufsin45.ru
Served by:
- ns2.nameself.com

          ufsin45.ru
- ns1.nameself.com

          ufsin45.ru

И самое интересное — любимый всеми Public DNS от Google:

Z:>nslookup ufsin45.ru 8.8.8.8
╤хЁтхЁ:  google-public-dns-a.google.com
Address:  8.8.8.8

*** google-public-dns-a.google.com не удалось найти ufsin45.ru: Server failed

Z:>nslookup ufsin45.ru 8.8.4.4
╤хЁтхЁ:  google-public-dns-b.google.com
Address:  8.8.4.4

*** google-public-dns-b.google.com не удалось найти ufsin45.ru: Server failed

Зная, сколько админов (да, думаю, и провайдеры многие этим грешат) не заморачиваясь ставят в качестве основных name-серверов эти легко запоминающиеся цифры ip-адресов, понимаю, что наш домен теряет посетителей и, главное, доверие к почтовому сервису.

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

Я честно пытался найти в дебрях техподдержки Google, к кому можно обратиться с данной проблемой, но, видимо, публичные name-сервера у них являются некой побочной службой, без инфраструктуры и поддержки. И, судя по увеличивающимся запросам на форумах по продуктам Google, на других форумах, а также устных отзывов своих коллег, эта проблема набирает обороты и, возможно, скоро еще один бесплатный сервис Корпорации Добра канет в лету…

P.S. После бурных обсуждений, с помощью уважаемого хабраобщества, прихожу к выводу, что Гугл виноват только в мегапопулярности своего ресолвера.
Но окончательную причину пока не нашли…

P.P.S. Уж не знаю, положительная ли энергия хабрасообщества так повлияла, или кто-то из причастных к проблеме людей прочитал этот пост и тихо исправил, может мистический полтергей «поиграл да отдал», а может и повлияло обновление SOA зоны, но сейчас все чудесным образом заработало. Все 21 сервер отресолвили наш домен. Еще раз большое спасибо всем ответившим, да прибудет с Вами Великая информационная сила! 🙂

Источник

Утилита nslookup. Команда Help

Nslookup — отображает информацию, которую вы можете использовать для диагностики инфраструктуры доменных имен (DNS). Перед использованием этого инструмента вы должны быть знакомы с тем, как работает DNS. Инструмент командной строки nslookup доступен, только если вы установили протокол TCP / IP.

Синтаксис

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

nslookup [<-SubCommand ...>] [{<computerTofind> | –<Server>}]

nslookup /exit

nslookup /finger [<UserName>] [{[>] <FileName>|[>>] <FileName>}]

nslookup /{help | ?}

nslookup /ls [<Option>] <DNSDomain> [{[>] <FileName>|[>>] <FileName>}]

nslookup /lserver <DNSDomain>

nslookup /root

nslookup /server <DNSDomain>

nslookup /set <KeyWord>[=<Value>]

nslookup /set all

nslookup /set class=<Class>

nslookup /set [no]d2

nslookup /set [no]debug

nslookup /set [no]defname

nslookup /set domain=<DomainName>

nslookup /set [no]ignore

nslookup /set port=<Port>

nslookup /set querytype=<ResourceRecordtype>

nslookup /set [no]recurse

nslookup /set retry=<Number>

nslookup /set root=<RootServer>

nslookup /set [no]search

nslookup /set srchlist=<DomainName>[/...]

nslookup /set timeout=<Number>

nslookup /set type=<ResourceRecordtype>

nslookup /set [no]vc

nslookup /view <FileName>

Список команд на сайте Майкрософт.

Параметры

Команда Синтаксис Описание
nslookup exit /exit Выход из утилиты.
nslookup finger finger [<UserName>] [{[>] <FileName>|[>>] <FileName>}] Соединение с finger сервером на текущем ПК.
nslookup help /help Выводит краткий список доступных подкоманд nslookup.
nslookup ls ls [<Option>] <DNSDomain> [{[>] <FileName>|[>>] <FileName>}] Выводит информацию о домене.
nslookup lserver lserver <DNSDomain> Меняет стандартный сервер для заданного домена DNS.
nslookup root root Меняет стандартный сервер, на корневой сервер DNS.
nslookup server server <DNSDomain> Меняет стандартный сервер имён, на выбранный вами.
nslookup set set <KeyWord>[=<Value>] Изменение стандартной конфигурации утилиты nslookup.
nslookup set all set all Выводит параметры текущей конфигурации.
nslookup set class set class=<Class> Меняет класс запроса. Класс указывает группу протоколов информации.
nslookup set d2 set [no]d2 Включает или выключает глубокий режим отладки. В режиме отладки выводятся данные о каждого пакета.
nslookup set debug set [no]debug Включает или выключает режим отладки.
nslookup set defname set defname Добавляет используемый по умолчанию домен DNS, к запросу на поиск одиночного компонента. Компонент называется одиночным, если не содержит точек.
nslookup set domain set domain=<DomainName> Изменяет имя домена по умолчанию (DNS) на указанное имя.
nslookup set ignore set ignore Игнорировать ошибки с неполными пакетами.
nslookup set port set port=<Port> Изменяет стандартный TCP/UDP порт сервера DNS на указанный.
nslookup set querytype set querytype=<ResourceRecordtype> Изменяет тип записи ресурса для запроса.
nslookup set recurse set [no]recurse Указывает DNS серверу по умолчанию, опросить другие сервера в сети, если у него нет необходимой информации.
nslookup set retry set retry=<Number> Указать число необходимых повторов запроса.
nslookup set root set root=<RootServer> Изменяет адрес коренного сервера.
nslookup set search set [no]search Добавляет имена доменов DNS из списка поиска доменов DNS в запрос, до тех пор пока не будет получен ответ. Данный метод используется в тех случаях, когда set и lookup содержат хотя-бы одну точку, но не содержат завершающей точки.
nslookup set srchlist Set srchlist=<DomainName>[/…] Изменяет стандартное имя домена DNS и список поиска.
nslookup set timeout set timeout=<Number> Изменяет таймаут ожидания ответа в секундах.
nslookup set type set type=<ResourceRecordtype> Изменяет тип записи ресурса для запроса.
nslookup set vc set [no]vc Указывает использовать или не использовать виртуальную цепь при отправке запросов на сервер.
nslookup view view <FileName> Вывод и сортировка данных, полученных ранее при помощи команды ls.

Примечания

  • Если computerTofind является IP-адресом, а запрос хочет получить A или PTR запись, возвращается имя компьютера. Если computerTofind является именем и у него нет точки в конце, к имени добавляется имя домена DNS по умолчанию. Это зависит от состояния следующих заданных подкоманд: domain, srchlist, defname и search.
  • Если вы используете дефис (-) вместо computerTofind, утилита nslookup перейдёт в интерактивный режим.
  • Длина строки не может превышать 256 символов.
  • nslookup имеет два режима: интерактивный и неинтерактивный. Если вы собираетесь воспользоваться утилитой единожды — используйте неинтерактивный режим. Первым параметром введите имя или IP-адрес компьютера, который вы хотите найти, а вторым параметром введите имя или IP-адрес сервера DNS-имен. Если вы опустите второй аргумент, nslookup использует DNS-сервер по умолчанию.
    Если вам нужно использовать утилиту несколько раз, вы можете войти в интерактивный режим. Для этого введите дефис (-) для первого параметра и имя или IP-адрес сервера имен DNS для второго параметра. Или опустите оба параметра, и nslookup использует DNS-сервер по умолчанию.
    Ниже приведены некоторые советы о работе в интерактивном режиме:

    • Чтобы прервать линию интерактивных команд в любое время, нажмите CTRL + B.
    • Чтобы выйти, введите exit.
    • Чтобы обработать встроенную команду в качестве имени компьютера, перед ним следует использовать escape-символ ().
    • Неопознанная команда интерпретируется как имя компьютера.

    • Если поиск не сработал, утилита nslookup выдаст сообщение об ошибке. В следующей таблице перечислены возможные сообщения об ошибках:

    Сообщение об ошибке Описание
    timed out Сервер не отвечает на запрос, спустя какое-то время (таймаут), и какое-то количество попыток запроса. Вы можете установить таймаут запроса, использовав подкоманду set timeout. Вы можете установить количество попыток запроса, использовав подкоманду set retry.
    No response from server Сервер DNS не отвечает на запросы утилиты nslookup.
    No records На DNS сервере нет записей по вашему запросу, если конечно, вы не ошиблись в имени домена. Формат запроса определяется подкомандой set querytype.
    Nonexistent domain Компьютер или имя домена не существуют.
    Connection refused
    или
    Network is unreachable    		 Соединение с сервером DNS не установлено. Это ошибка чаще всего происходит при использовании команд ls и finger
    Server failure Сервер DNS определил внутреннюю ошибку в своей базе данных, и не может предоставить правильный ответ.
    Refused Сервер DNS прервал соединение.
    Format error Сервер DNS обнаружил неверный формат в запросе. Чаще всего это происходит из-за ошибки утилиты nslookup

Что значит «Не заслуживающий доверия ответ»?

Сообщение «Не заслуживающий доверия ответ:» (Non-authoritative answer: ) означает только то, что DNS-сервер по умолчанию, не является владельцем зоны запрашиваемого домена, т.е. записей об этом домене в его собственной базе нет, и для предоставления информации был сделан рекурсивный запрос к другому серверу DNS. Так что в принципе, в этом сообщении ничего страшного нет.

Как узнать MX запись домена с помощью nslookup?

Для того, чтобы узнать MX запись домена используйте подкоманду type:

nslookup -type=mx logi.cc

Вывод команды nslookup mx

Nslookup online

Посмотреть ответ DNS сервера о домене можно онлайн. Таких сервисов множество, вот некоторые из них:
1. 2whois.ru
Ответ сайта ping.eu на запрос об A записи домена Logi.cc

2. ing.eu
Ответ сайта 2whois.ru на запрос об A записи домена Logi.cc

Nslookup очень полезная утилита для определения неверной работы DNS вашего домена, или не правильной работы NS серверов на вашем компьютере.

Источник
  • Remove From My Forums

  • Question

  • C:Usersv.DESKTOP>nslookup
    ╤хЁтхЁ яю єьюыўрэш■: google-public-dns-a.google.com
    Address: 8.8.8.8
    > set norecurse
    > set type=any
    > .
    ╤хЁтхЁ: google-public-dns-a.google.com
    Address: 8.8.8.8
    Не заслуживающий доверия ответ:
    (root) ??? unknown type 48 ???
    (root) ??? unknown type 48 ???
    (root) ??? unknown type 48 ???
    (root) ??? unknown type 46 ???
    (root) ??? unknown type 47 ???
    (root) ??? unknown type 46 ???
    (root) nameserver = a.root-servers.net
    (root) nameserver = b.root-servers.net
    (root) nameserver = c.root-servers.net
    (root) nameserver = d.root-servers.net
    (root) nameserver = e.root-servers.net
    (root) nameserver = f.root-servers.net
    (root) nameserver = g.root-servers.net
    (root) nameserver = h.root-servers.net
    (root) nameserver = i.root-servers.net
    (root) nameserver = j.root-servers.net
    (root) nameserver = k.root-servers.net
    (root) nameserver = l.root-servers.net
    (root) nameserver = m.root-servers.net
    (root) ??? unknown type 46 ???
    (root)
    primary name server = a.root-servers.net
    responsible mail addr = nstld.verisign-grs.com
    serial = 2019033001
    refresh = 1800 (30 mins)
    retry = 900 (15 mins)
    expire = 604800 (7 days)
    default TTL = 86400 (1 day)
    (root) ??? unknown type 46 ???

Answers

  • Потому что вы подали запрос серверу DNS(8.8.8.8), который не является полномочным для тех записей, которые он вернул в ответе (ссылки на корневые серверы DNS).

    Вот если бы вы подали такой же запрос на один из тех серверов, которые  получили в ответе (список полномочных серверов для корневой зоны DNS), то (скорее всего 😉 ) получили бы от него ответ, “заслуживающий доверия” (в оригинале -authoritative,
    в данном случае более правильный перевод – “полномочный”).

    Слава России!

    • Marked as answer by

      Saturday, April 6, 2019 4:44 PM

  • возможно потому что вы используете публичные днс вместо доменных?

    The opinion expressed by me is not an official position of Microsoft

    • Marked as answer by
      Vasya1395
      Saturday, April 6, 2019 4:44 PM

  • Я отправил запрос к публичному dns серверу google ,чтобы узнать ip адрес корневого сервера dns a.root-servers.net

    Microsoft Windows [Version 10.0.17763.404]
    (c) Корпорация Майкрософт (Microsoft Corporation), 2018. Все права защищены.

    C:Usersv.DESKTOP>nslookup
    ╤хЁтхЁ яю єьюыўрэш■:  google-public-dns-a.google.com
    Address:  8.8.8.8

    > a.root-servers.net
    ╤хЁтхЁ:  google-public-dns-a.google.com
    Address:  8.8.8.8

    Не заслуживающий доверия ответ:
    ╚ь :     a.root-servers.net
    Addresses:  2001:503:ba3e::2:30

    Как мне выяснить ip адрес корневого dns сервера a.root-servers.net,чтобы ответ от dns сервера,который прописан в настройках моего сетевого подключения (публичный dns google) я получил заслуживающий доверия ответ?         
      

    Никак. Вам уже объяснили выше почему. 

    This posting is provided “AS IS” with no warranties, and confers no rights.

    • Marked as answer by
      Vasya1395
      Saturday, April 6, 2019 6:50 PM

Источник

Команда NSLOOKUP — работа с сервером DNS из командной строки

&nbsp &nbsp Утилита NSLOOKUP присутствует в операционных системах Windows, начиная с Windows NT , и предназначена для формирования запросов к серверам DNS из командной строки. Фактически, утилита является аналогом службы DNS-клиент и позволяет диагностировать проблемы с разрешением имен в системе DNS. По умолчанию, все запросы отправляются на DNS-сервер, адрес которого задан настройками сетевого подключения. В терминах утилиты такой сервер является сервером по умолчанию (default server). Команда ipconfig /all позволяет получить информацию о настройках протокола IP и, в том числе, о серверах DNS, используемых в системе.

При запуске nslookup без параметров, утилита переходит в интерактивный режим, ожидая ввод команд пользователя. Ввод знака вопроса или help позволяет отобразить справку о внутренних командах и опциях nslookup :

(идентификаторы отображаются в верхнем регистре, квадратные скобки «[]» обозначают необязательные параметры)

NAME — печать сведений об узле или домене NAME с помощью сервера по умолчанию
NAME1 NAME2 — та же операция, но в качестве сервера используется NAME2
help или ? — печать сведений о стандартных командах
set OPTION — установить параметр
all — печать параметров, текущего сервера и узла
[no]debug — печать отладочных сведений
[no]d2 — печать полных отладочных сведений
[no]defname — добавить имя домена ко всем запросам
[no]recurse — запрос рекурсивного ответа на запрос
[no]search — использовать список поиска доменов
[no]vc — всегда использовать виртуальную схему
domain=NAME — установить имя домена по умолчанию NAME
srchlist=N1[/N2/. /N6] — установить домен N1 и список поиска N1,N2 и т.д.
root=NAME — установить корневой сервер NAME
retry=X — установить число повторов X
timeout=X — установить интервал времени ожидания в X секунд
type=X — установить тип запроса (пр. A,AAAA,A+AAAA,ANY,CNAME,MX ,NS,PTR,SOA,SRV)
querytype=X — то же, что и type
class=X — установить класс запроса ( IN (Internet), ANY)
[no]msxfr — использовать быструю зону MS для передачи
ixfrver=X — текущая версия, использующаяся в передаче запросов IXFR
server NAME — установить сервер по умолчанию NAME, используя текущий сервер по умолчанию
lserver NAME — установить сервер по умолчанию NAME, используя первоначальный сервер
root — сделать текущий сервер по умолчанию корневым сервером
ls [opt] DOMAIN [> FILE] — перечисление адресов в домене DOMAIN (необязательно: вывод в файл FILE)
-a — перечисление канонических имен и псевдонимов
-d — перечисление всех записей
-t TYPE — перечисление записей указанного типа RFC (пр. A,CNAME,MX,NS,PTR etc.)
view FILE — сортировка файла «ls» и его просмотр с помощью pg

exit — выход из программы

Примеры использования команды NSLOOKUP

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

nslookup yandex.ru. — выполнить запрос к DNS-серверу, заданному по умолчанию, на разрешение доменного имени yandex.ru . Для уменьшения количества ненужных запросов к серверам имен, имя домена нужно вводить в виде полностью определенного имени (fully qualified domain name) , т.е. с точкой в конце. Если этого не делать, то nslookup будет сначала выполнять запрос на разрешение имени относительно домена того компьютера, на котором она выполняется, т.е. yandex.ru.mydomain.ru если имя локального домена — mydomain.ru.

nslookup -type=mx yandex.ru — то же, что и в предыдущем примере, но с указанием типа запрашиваемой записи -type=mx . Сервер DNS ответит на запрос утилиты nslookup перечислением почтовых серверов, обслуживающих домен yandex.ru

nslookup odnoklassniki.ru 8.8.8.8 — определить IP-адрес узла odnokassniki.ru с использованием DNS-сервера 8.8.8.8 (публичный DNS-сервер Google), вместо DNS-сервера, заданного в настройках сетевого подключения.

nslookup -type=mx -timeout=8 vk.com 208.67.220.220 — отобразить запись MX для домена vk.com из базы данных сервера с IP-адресом 208.67.220.220 (сервер OpenDNS). При выполнении команды, максимальное время ожидания ответа сервера — 8 секунд.

nslookup -type=any -timeout=8 vk.com 208.67.220.220 — то же, что и в предыдущем примере, но выполняется запрос на отображение любых типов записей.

Пример отображаемых данных:

Сервер: 208.67.220.220
Не заслуживающий доверия ответ:
vk.com internet address = 87.240.131.119
vk.com internet address = 87.240.131.99
vk.com nameserver = ns2.vkontakte.ru
vk.com nameserver = ns4.vkontakte.ru
vk.com nameserver = ns1.vkontakte.ru
vk.com nameserver = ns4.vkontakte.ru
vk.com nameserver = ns2.vkontakte.ru
vk.com nameserver = ns1.vkontakte.ru
ns1.vkontakte.ru internet address = 93.186.237.2
ns2.vkontakte.ru internet address = 93.186.224.100

Для разных версий nslookup и разных DNS-серверов, обслуживающих запрос, отображаемая информация может незначительно отличаться. Тот же запрос, сформированный англоязычной версией утилиты nslookup.exe и направленный на обработку DNS-серверу компании Google приведет к отображению следующих данных:

Non-authoritative answer:
vk.com internet address = 87.240.131.120
vk.com internet address = 87.240.143.244
vk.com

primary name server = ns1.vkontakte.ru
responsible mail addr = ncc.vkontakte.ru
serial = 2013100501
refresh = 3600 (1 hour)
retry = 900 (15 mins)
expire = 604800 (7 days)
default TTL = 900 (15 mins)
vk.com AAAA IPv6 address = 2a00:bdc0:3:103:1:0:403:901
vk.com AAAA IPv6 address = 2a00:bdc0:3:103:1:0:403:902
vk.com AAAA IPv6 address = 2a00:bdc0:3:103:1:0:403:903
vk.com nameserver = ns1.vkontakte.ru
vk.com nameserver = ns2.vkontakte.ru
vk.com nameserver = ns4.vkontakte.ru
vk.com MX preference = 10, mail exchanger = mail.vk.com
vk.com text =»v=spf1 ip4:93.186.224.0/20 ip4:87.240.128.0/18 mx include:aspmx.googlemail.com

Сообщение «Не заслуживающий доверия ответ:» (Non-authoritative answer: ) говорит о том, что выполняющий запрос DNS-сервер, не является владельцем зоны vk.com т.е. записи для узла vk.com в его базе отсутствуют, и для разрешения имени использовался рекурсивный запрос к другому DNS-серверу. Если отправить запрос DNS-серверу ns1.vkontakte.ru, то будет получен авторитетный ответ (authoritative answer) :

Server: ns1.vkontakte.ru
Address: 93.186.237.2

primary name server = ns1.vkontakte.ru
responsible mail addr = ncc.vkontakte.ru
serial = 2013100501
refresh = 3600 (1 hour)
retry = 900 (15 mins)
expire = 604800 (7 days)
default TTL = 900 (15 mins)
vk.com internet address = 87.240.131.118
vk.com AAAA IPv6 address = 2a00:bdc0:3:103:1:0:403:904
vk.com AAAA IPv6 address = 2a00:bdc0:3:103:1:0:403:905
vk.com AAAA IPv6 address = 2a00:bdc0:3:103:1:0:403:906
vk.com nameserver = ns4.vkontakte.ru
vk.com nameserver = ns1.vkontakte.ru
vk.com nameserver = ns2.vkontakte.ru
vk.com MX preference = 10, mail exchanger = mail.vk.com
vk.com text = «v=spf1 ip4:93.186.224.0/20 ip4:87.240.128.0/18 mx include:aspmx.googlemail.com

all»
ns4.vkontakte.ru internet address = 93.186.239.253
ns4.vkontakte.ru AAAA IPv6 address = 2a00:bdc0:ff:4::2
ns1.vkontakte.ru internet address = 93.186.237.2
ns1.vkontakte.ru AAAA IPv6 address = 2a00:bdc0:ff:1::2
ns2.vkontakte.ru internet address = 93.186.224.100
ns2.vkontakte.ru AAAA IPv6 address = 2a00:bdc0:ff:2::2
mail.vk.com internet address = 93.186.236.94

Использование опции отладки (debug) позволяет получить дополнительную информацию, содержащуюся в заголовках запросов клиента и ответов сервера (время жизни, флажки, типы записей и т.п.): > server ns1.vkontakte.ru
————

Got answer:
HEADER:

opcode = QUERY, rcode = NXDOMAIN
header flags: response, want recursion, recursion avail.
questions = 1, answers = 0, authority records = 1, additional = 0

ns1.vkontakte.ru, type = A, >
AUTHORITY RECORDS:

-> (root)
ttl = 440 (7 mins 20 secs)
primary name server = a.root-servers.net
responsible mail addr = nstld.verisign-grs.com
serial = 2013101600
refresh = 1800 (30 mins)
retry = 900 (15 mins)
expire = 604800 (7 days)
default TTL = 86400 (1 day)

opcode = QUERY, rcode = NOERROR
header flags: response, want recursion, recursion avail.
questions = 1, answers = 1, authority records = 0, additional = 0

ns1.vkontakte.ru, type = A, >
ANSWERS:

-> ns1.vkontakte.ru
internet address = 93.186.237.2
ttl = 6350 (1 hour 45 mins 50 secs)

————
Default Server: ns1.vkontakte.ru
Address: 93.186.237.2

> vk.com
Server: ns1.vkontakte.ru
Address: 93.186.237.2

opcode = QUERY, rcode = REFUSED
header flags: response, want recursion
questions = 1, answers = 0, authority records = 0, additional = 0

opcode = QUERY, rcode = NOERROR
header flags: response, auth. answer, want recursion
questions = 1, answers = 11, authority records = 0, additional = 7

vk.com, type = ANY, >
ANSWERS:

-> vk.com
ttl = 900 (15 mins)
primary name server = ns1.vkontakte.ru
responsible mail addr = ncc.vkontakte.ru
serial = 2013100501
refresh = 3600 (1 hour)
retry = 900 (15 mins)
expire = 604800 (7 days)
default TTL = 900 (15 mins)
-> vk.com
internet address = 87.240.131.99
ttl = 900 (15 mins)
-> vk.com
internet address = 87.240.131.119
ttl = 900 (15 mins)
-> vk.com
AAAA IPv6 address = 2a00:bdc0:3:103:1:0:403:901
ttl = 900 (15 mins)
-> vk.com
AAAA IPv6 address = 2a00:bdc0:3:103:1:0:403:902
ttl = 900 (15 mins)
-> vk.com
AAAA IPv6 address = 2a00:bdc0:3:103:1:0:403:903
ttl = 900 (15 mins)
-> vk.com
nameserver = ns1.vkontakte.ru
ttl = 900 (15 mins)
-> vk.com
nameserver = ns2.vkontakte.ru
ttl = 900 (15 mins)
-> vk.com
nameserver = ns4.vkontakte.ru
ttl = 900 (15 mins)
-> vk.com
MX preference = 10, mail exchanger = mail.vk.com
ttl = 900 (15 mins)
-> vk.com
text = «v=spf1 ip4:93.186.224.0/20 ip4:87.240.128.0/18 mx include:aspmx.googlemail.com

all»
ttl = 900 (15 mins)
ADDITIONAL RECORDS:
-> ns1.vkontakte.ru
internet address = 93.186.237.2
ttl = 9000 (2 hours 30 mins)
-> ns1.vkontakte.ru
AAAA IPv6 address = 2a00:bdc0:ff:1::2
ttl = 9000 (2 hours 30 mins)
-> ns2.vkontakte.ru
internet address = 93.186.224.100
ttl = 9000 (2 hours 30 mins)
-> ns2.vkontakte.ru
AAAA IPv6 address = 2a00:bdc0:ff:2::2
ttl = 9000 (2 hours 30 mins)
-> ns4.vkontakte.ru
internet address = 93.186.239.253
ttl = 9000 (2 hours 30 mins)
-> ns4.vkontakte.ru
AAAA IPv6 address = 2a00:bdc0:ff:4::2
ttl = 9000 (2 hours 30 mins)
-> mail.vk.com
internet address = 93.186.236.94
ttl = 900 (15 mins)

————
vk.com
ttl = 900 (15 mins)
primary name server = ns1.vkontakte.ru
responsible mail addr = ncc.vkontakte.ru
serial = 2013100501
refresh = 3600 (1 hour)
retry = 900 (15 mins)
expire = 604800 (7 days)
default TTL = 900 (15 mins)
vk.com
internet address = 87.240.131.99
ttl = 900 (15 mins)
vk.com
internet address = 87.240.131.119
ttl = 900 (15 mins)
vk.com
AAAA IPv6 address = 2a00:bdc0:3:103:1:0:403:901
ttl = 900 (15 mins)
vk.com
AAAA IPv6 address = 2a00:bdc0:3:103:1:0:403:902
ttl = 900 (15 mins)
vk.com
AAAA IPv6 address = 2a00:bdc0:3:103:1:0:403:903
ttl = 900 (15 mins)
vk.com
nameserver = ns1.vkontakte.ru
ttl = 900 (15 mins)
vk.com
nameserver = ns2.vkontakte.ru
ttl = 900 (15 mins)
vk.com
nameserver = ns4.vkontakte.ru
ttl = 900 (15 mins)
vk.com
MX preference = 10, mail exchanger = mail.vk.com
ttl = 900 (15 mins)
vk.com
text = «v=spf1 ip4:93.186.224.0/20 ip4:87.240.128.0/18 mx include:aspmx.googlemail.com

all»
ttl = 900 (15 mins)
ns1.vkontakte.ru
internet address = 93.186.237.2
ttl = 9000 (2 hours 30 mins)
ns1.vkontakte.ru
AAAA IPv6 address = 2a00:bdc0:ff:1::2
ttl = 9000 (2 hours 30 mins)
ns2.vkontakte.ru
internet address = 93.186.224.100
ttl = 9000 (2 hours 30 mins)
ns2.vkontakte.ru
AAAA IPv6 address = 2a00:bdc0:ff:2::2
ttl = 9000 (2 hours 30 mins)
ns4.vkontakte.ru
internet address = 93.186.239.253
ttl = 9000 (2 hours 30 mins)
ns4.vkontakte.ru
AAAA IPv6 address = 2a00:bdc0:ff:4::2
ttl = 9000 (2 hours 30 mins)
mail.vk.com
internet address = 93.186.236.94
ttl = 900 (15 mins)

nslookup 8.8.4.4 — отобразить имя узла, соответствующее IP-адресу 8.8.4.4

Сообщения: 3
Благодарности: 0

Здравствуйте. Есть машинка, на ней стоит свежая Win7 Максимальная x64, билд 7600 RU.

На ней с перебоями работает разрешение имен. Инет приходит через Ethernet от домашнего роутера (Acorp W422G_v3), к которому машинка цепляется по DHCP. DHCP наряду с айпишниками раздает клиентам адреса DNS-серверов в явном виде, то есть не relay самого роутера, а в моем случае OpenDNS (208.67.222.222, 208.67.220.220).

Аналогично не резолвятся имена в других приложениях.

Вывод ipconfig /all:

Я, если честно, не понимаю, как такое вообще возможно — разве механизм разрешения имен в ping и nslookup не один и тот же?

И да, пробовал прописать другие DNS (провайдерские, гугловский, и т.п.) — то же самое. Пробовал статически вписать DNS и айпишники — все равно то же самое.

Причем данная ситуация наблюдается случайным образом — иногда резолвинг работает, иногда нет. Подозреваю, что это что-то связанное со сбросом какого-либо кэша по времени (ARP, DNS), но не знаю куда копать. ipconfig /flushdns ничего не дает.

В Linux и WinXP все нормально работает.

Сообщения: 52416
Благодарности: 15170

Конфигурация компьютера
Процессор: Intel Core i7-3770K
Материнская плата: ASUS P8Z77-V LE PLUS
Память: Crucial Ballistix Tactical Tracer DDR3-1600 16 Гб (2 x 8 Гб)
HDD: Samsung SSD 850 PRO 256 Гб, WD Green WD20EZRX 2 Тб
Видеокарта: ASUS ROG-STRIX-GTX1080-O8G-11GBPS
Звук: Realtek ALC889 HD Audio
Блок питания: be quiet! Straight Power 11 650W
CD/DVD: ASUS DRW-24B5ST
Монитор: ASUS VG248QE 24″
ОС: Windows 8.1 Pro x64
Индекс производительности Windows: 8,1
Прочее: корпус: Fractal Design Define R4

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

Сообщения: 3
Благодарности: 0

Петя, ю а май хиро.

В общем, дело не в ipv6 (ping -4 тоже не работает), дело в службе dnscache, которая, видимо, за каким-то дьяволом пытается резолвить имена через netbios, а не DNS.
По ссылке что вы дали, люди решили проблему, но у кого-то не работало, у кого-то работало. ну его нафиг.
Я поступил топорней — вырубил DNS-кэш нафиг (net stop dnscache), и пустил DNS-запросы через привычный dnsmasq на отдельной машине.

Проблема решена, хоть и костыльно, конечно.

Последний раз редактировалось mexico, 20-06-2010 в 01:08 .

Сообщения: 1961
Благодарности: 304

mexico,
А серверов провайдера без всяких заморочек не хватает?
При чем тут netbios?

По команде
ping yandex.ru
делается запрос UDP на адрес сервера DNS который указан в настройках сетевой карты — IP:53 (порт 53 Dns — Query) передается параметр yandex.ru, потом получаем ответ UDP от сервера DNS (порт 53 DNS — Response — 78.110.50.103), далее уже протокол ICMP на полученный IP пробует достучаться.

Сообщения: 3
Благодарности: 0

А серверов провайдера без всяких заморочек не хватает? »

Не-а. Я и их ставил, не в них дело. Про UDP 53 не надо — азы же.

Объяснение, которое вижу я: nslookup, видимо, работает мимо кэша, тогда как остальное пользуется службой DNS-клиент. По команде ping yandex.ru, насколько я понимаю, никаких запросов не делается, а имя просто берется из кэша, что хорошо видно из листинга, приведенного мной, так как после отключения dnscache все прекрасно заработало. Кстати, отключение службы Модуль поддержки NetBIOS через TCP/IP дает тот же результат (она ведь за WINS-резолвинг отвечает, или нет. ). А вот уже dnscache хрен знает откуда резолвит имена.

Поскольку у меня есть сторонний DNS-кэш на Linux, я не стал заморачиваться и искать причины (я не в ладах с вендой, да и время — деньги), а просто отключил виндовый кэш. Работает — и ладно.

Если предложите 100% работающий способ обойтись без этого костыля — буду только рад.

Последний раз редактировалось mexico, 20-06-2010 в 01:13 .

Сообщения: 1961
Благодарности: 304

mexico,
Nslookup действительно кэш DNS не нужен.

cmd>ipconfig /displaydns
(проверка кэша)
cmd>ipconfig /flushdns
(очистка кэша)
cmd>nslookup www.yandex.ru
cmd>ipconfig /displaydns

Nslookup работает на прямую с сервером DNS (а именно с записью о доменной зоне вытаскивая из нее нужные данные).
Так по команде
Nslookup www.yandex.ru
1.Сначала из свойств сетевой будет вытащен адрес DNS сервера, потом будет запрос на определение записи PTR (т.е. обратное преобразование из IP в имя), чисто для того работает ли сервер DNS и как его зовут.
Вы получили —

╤хЁтхЁ: resolver1.opendns.com
Address: 208.67.222.222

Не заслуживающий доверия ответ:
╚ь*: yandex.ru
Addresses: 87.250.251.11
93.158.134.11
213.180.204.11
213.180.204.211
77.88.21.11

При отключении windows кэша DNS вы заставляете лишний раз ПК клиента определять IP по мнемонике используя запросы по сети на ваш DNS (если они есть у него в кэше, то он просто их отправит), по времени это доли секунд.

Теперь команда ping yandex.ru
cmd>ipconfig /flushdns
(очистка кэша)
cmd>ping yandex.ru
cmd>ipconfig /displaydns
(проверка кэша)
Кеш заполнен на yandex.ru через нормальный запрос на DNS сервер.
При попытки второго раза выполнить команду
cmd>ping yandex.ru
Запроса на DNS сервер не будет, будет работа с кэшем DNS

Реестр по кэшу DNS
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservicesDnscache

Устранение неполадок с DNS-серверами

В этой статье описывается, как устранять неполадки на DNS-серверах.

Проверка IP-конфигурации

Выполните ipconfig /all команду из командной строки и проверьте IP-адрес, маску подсети и шлюз по умолчанию.

Проверьте, является ли DNS-сервер полномочным для имени, которое ищется. Если это так, см. раздел Проверка на наличие проблем с достоверными данными.

Выполните следующую команду.

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

Очистка кэша сопоставителя. Для этого выполните следующую команду в окне командной строки с правами администратора:

Или в окне администрирования PowerShell выполните следующий командлет:

Повторите шаг 3.

Проверка неполадок DNS-сервера

Журнал событий

Проверьте следующие журналы, чтобы узнать, есть ли записанные ошибки:

Тестирование с помощью запроса nslookup

Выполните следующую команду и проверьте, доступен ли DNS-сервер с клиентских компьютеров.

Если сопоставитель возвращает IP-адрес клиента, у сервера нет проблем.

Если сопоставитель возвращает ответ «сбой сервера» или «Запрос отклонен», зона может быть приостановлена или сервер может быть перегружен. Чтобы узнать, приостановлен ли он, перейдите на вкладку Общие окна свойств зоны в консоли DNS.

Если сопоставитель возвращает ответ «запрос на превышение времени ожидания сервера» или «нет ответа от сервера», возможно, служба DNS не запущена. Попробуйте перезапустить службу DNS-сервера, введя следующую команду в командной строке на сервере:

Если проблема возникает при запуске службы, сервер может не прослушивать IP-адрес, который использовался в запросе nslookup. На вкладке интерфейсы страницы свойств сервера консоли DNS администраторы могут ограничить DNS-сервер прослушиванием только выбранных адресов. Если DNS-сервер настроен для ограничения службы указанным списком настроенных IP-адресов, то возможно, что IP-адрес, используемый для связи с DNS-сервером, отсутствует в списке. Можно попробовать использовать другой IP-адрес в списке или добавить IP-адрес в список.

В редких случаях DNS-сервер может иметь расширенную конфигурацию безопасности или брандмауэра. Если сервер расположен в другой сети, доступной только через промежуточный узел (например, маршрутизатор фильтрации пакетов или прокси-сервер), DNS-сервер может использовать нестандартный порт для прослушивания и получения клиентских запросов. По умолчанию программа nslookup отправляет запросы на DNS-серверы через порт UDP 53. Поэтому, если DNS-сервер использует любой другой порт, запросы nslookup завершатся ошибкой. Если вы считаете, что это может быть проблема, проверьте, используется ли промежуточный фильтр для блокировки трафика на хорошо известных портах DNS. Если это не так, попробуйте изменить фильтры пакетов или правила портов в брандмауэре, чтобы разрешить трафик через порт UDP/TCP 53.

Проверка на наличие проблем с достоверными данными

Проверьте, является ли сервер, который возвращает неверный ответ, основным сервером для зоны (основным сервером-источником для зоны или сервером, который использует интеграцию Active Directory для загрузки зоны) или сервер, на котором размещена дополнительная копия зоны.

Если сервер является сервером-источником

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

Если на сервере размещается дополнительная копия зоны

Изучите зону на сервере-источнике (сервере, с которого этот сервер извлекает зоны).

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

Если на сервере-источнике указано неправильное имя, перейдите к шагу 4.

Если на сервере-источнике указано правильное имя, убедитесь, что серийный номер на сервере-источнике меньше или равен серийному номеру на сервере-получателе. Если это так, измените либо сервер-источник, либо сервер-получатель, чтобы серийный номер на сервере-источнике был больше, чем серийный номер на сервере-получателе.

На сервере-получателе выполните принудительную пересылку зоны с помощью консоли DNS или выполните следующую команду:

Например, если зона — corp.contoso.com, введите: dnscmd /zonerefresh corp.contoso.com .

Изучите сервер-получатель еще раз, чтобы узнать, правильно ли передана зона. В противном случае у вас, вероятно, возникает проблема с переносом зоны. Дополнительные сведения см. в статье проблемы зонных передач.

Если зона была передана правильно, проверьте, правильно ли указаны данные. В противном случае данные в основной зоне неверны. Проблема может быть вызвана ошибкой пользователя при вводе пользователем данных в зону. Кроме того, это может быть вызвано проблемой, которая влияет на Active Directory репликацию или динамическое обновление.

Проверка проблем с рекурсией

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

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

Сервер, используемый во время запроса, не отвечает.

Сервер, используемый во время запроса, предоставляет неверные данные.

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

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

Если сервер находится в работоспособном состоянии и может пересылать запросы, повторите этот шаг и проверьте сервер, на который сервер пересылает запросы.

Если этот сервер не перенаправляет запросы на другой сервер, проверьте, может ли этот сервер запрашивать корневой сервер. Для этого выполните следующую команду:

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

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

Тестирование неработающего делегирования

Начните тесты в следующей процедуре, запросив допустимый корневой сервер. Этот тест позволяет выполнить запрос всех DNS-серверов из корня к серверу, который тестируется для неработающего делегирования.

В командной строке на тестируемом сервере введите следующее:

Тип записи ресурса — это тип записи ресурса, для которой был выполнен запрос в исходном запросе, а полное доменное имя — полное доменное имя, для которого выполнялись запросы (заканчивающиеся точкой).

Если ответ содержит список записей ресурсов «NS» и «A» для делегированных серверов, повторите шаг 1 для каждого сервера и используйте IP-адрес из записей ресурсов «A» в качестве IP-адреса сервера.

Если ответ не содержит запись ресурса NS, делегирование будет разорвано.

Если ответ содержит записи ресурсов «NS», но нет записей ресурсов «A», введите » задать рекурсию» и выполните запрос по отдельности для записей ресурсов «a» серверов, перечисленных в записях NS. Если вы не нашли по меньшей мере один допустимый IP-адрес записи ресурса «A» для каждой записи ресурса NS в зоне, то у вас есть неработающее делегирование.

Если вы определили, что вы используете неработающее делегирование, исправьте его, добавив или обновив запись ресурса «A» в родительской зоне, используя допустимый IP-адрес для соответствующего DNS-сервера для делегированной зоны.

Просмотр текущих корневых ссылок

Запустите консоль DNS.

Добавьте или подключитесь к DNS-серверу, который не прошел рекурсивный запрос.

Щелкните правой кнопкой мыши сервер и выберите пункт Свойства.

Щелкните корневые ссылки.

Проверьте наличие базовых подключений к корневым серверам.

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

Если корневые серверы не отвечают на проверку связи по IP-адресу, IP-адреса для корневых серверов могли измениться. Однако нередко можно увидеть перенастройку корневых серверов.

Проблемы с зонными ошибками

Выполните следующие проверки:

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

Проверьте сервер источника, чтобы узнать, не отправит ли он передачу данных для безопасности.

Проверьте вкладку зонные передачи свойств зоны в консоли DNS. Если сервер ограничит передачу зоны на список серверов, например на вкладке серверы имен в свойствах зоны, убедитесь, что сервер-получатель находится в этом списке. Убедитесь, что сервер настроен на отправку зонных передач.

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

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

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

если зона прямого просмотра на Windows сервере содержит тип записи (например, запись SRV), которую сервер-получатель не поддерживает, то на сервере-получателе могут возникнуть проблемы с извлечением зоны.

Проверьте, запущена ли на сервере-источнике другая реализация сервера DNS, например BIND. если да, то возможно, что зона на сервере источника включает несовместимые записи ресурсов, которые Windows не распознает.

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

Источник

Добавить комментарий