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

4u PRO

Парни как это понимать, сервис mail.ru сидит на 4 айпишниках? и что значит не заслуживающий доверия ответ

    А у яндыкса их около 50

C:UsersSlavikgt;nslookup ya.ru
#9572;хтх: WL-E0CB4EED2927
Address: 192.168.1.1

Не заслуживающий доверия ответ:
#9562;ь : ya.ru
Addresses: 87.250.251.3
93.158.134.3
213.180.204.3
77.88.21.3
87.250.250.3

Все в порядке, так и должно быть.
Это просто означает, что ваш dns сервер получил этот адрес у другого dns сервера, поэтому такой адрес считается не заслуживающим доверия. А вот если бы ваш dns сервер был ответственный за зону .ru тогда ответ был бы заслуживающим доверия.
На самом деле это просто тупой (и неправильный) перевод с английского.

Не заслуживающий доверия ответ — это просто ответ установленного вручную DNS-сервера
А как получают заслуживающий доверия: Идут к главному DNS-серверу, ответственному за европу, он говорит, кто ответственнен за зону .ru, идут к нему, и он уже говорит кто такой ya.ru или перенаправляет дальше (если домен 3 уровня)
Это тот же nslookup умеет делать, сейчас ключи для этого не вспомню правда.. . Но это дольше, и поэтому обычно используют обычные DNS-сервера, а не получают такой ответ

Да, как можно делать — из nslookup запустить root, он как раз установит вместо ручного корневой сервер и далее рекурсивно искать.. . Будет расово верный ответ) )

Источник:
4u PRO
Парни как это понимать, сервис mail.ru сидит на 4 айпишниках? и что значит не заслуживающий доверия ответ А у яндыкса их около 50 C:UsersSlavikgt;nslookup ya.ru #9572;хтх:
http://4u-pro.ru/tehnologii/kompyuteri/internet/parni-kak-eto-ponimat-servis-mailru-sidit-na-4-ajpishnikah-i-chto-znachit-ne-zasluzhivayushij-doveriya-otvet

H Конспект админа Домены, адреса и Windows: смешивать, но не взбалтывать

H [Конспект админа] Домены, адреса и Windows: смешивать, но не взбалтывать

В очередном «конспекте админа» остановимся на еще одной фундаментальной вещи – механизме разрешения имен в IP-сетях. Кстати, знаете почему в доменной сети nslookup на все запросы может отвечать одним адресом? И это при том, что сайты исправно открываются. Если задумались – добро пожаловать под кат. .

Для преобразования имени в IP-адрес в операционных системах Windows традиционно используются две технологии – NetBIOS и более известная DNS.

NetBIOS (Network Basic Input/Output System) – технология, пришедшая к нам в 1983 году. Она обеспечивает такие возможности как:

регистрация и проверка сетевых имен;

установление и разрыв соединений;

связь с гарантированной доставкой информации;

связь с негарантированной доставкой информации;

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

    Широковещательным называют такой запрос, который предназначен для получения всеми компьютерами сети. Для этого запрос посылается на специальный IP или MAC-адрес для работы на третьем или втором уровне модели OSI.

    Для работы на втором уровне используется MAC-адрес FF:FF:FF:FF:FF:FF, для третьего уровня в IP-сетях адрес, являющимся последним адресом в подсети. Например, в подсети 192.168.0.0/24 этим адресом будет 192.168.0.255

    Естественно, постоянно рассылать широковещательные запросы не эффективно, поэтому существует кэш NetBIOS – временная таблица соответствий имен и IP-адреса. Таблица находится в оперативной памяти, по умолчанию количество записей ограничено шестнадцатью, а срок жизни каждой – десять минут. Посмотреть его содержимое можно с помощью команды nbtstat -c, а очистить – nbtstat -R.

    Пример работы кэша для разрешения имени узла «хр».

    Что происходило при этом с точки зрения сниффера.

    В крупных сетях из-за ограничения на количество записей и срока их жизни кэш уже не спасает. Да и большое количество широковещательных запросов запросто может замедлить быстродействие сети. Для того чтобы этого избежать, используется сервер WINS (Windows Internet Name Service). Адрес сервера администратор может прописать сам либо его назначит DHCP сервер. Компьютеры при включении регистрируют NetBIOS имена на сервере, к нему же обращаются и для разрешения имен.

    В сетях с *nix серверами можно использовать пакет программ Samba в качестве замены WINS. Для этого достаточно добавить в конфигурационный файл строку «wins support = yes». Подробнее – в документации.

    В отсутствие службы WINS можно использовать файл lmhosts, в который система будет «заглядывать» при невозможности разрешить имя другими способами. В современных системах по умолчанию он отсутствует. Есть только файл-пример-документация по адресу %systemroot%\System32\drivers\etc\lmhost.sam. Если lmhosts понадобится, его можно создать рядом с lmhosts.sam.

    Сейчас технология NetBIOS не на слуху, но по умолчанию она включена. Стоит иметь это ввиду при диагностике проблем.

    DNS (Domain Name System) – распределенная иерархическая система для получения информации о доменах. Пожалуй, самая известная из перечисленных. Механизм работы предельно простой, рассмотрим его на примере определения IP адреса хоста www.google.com:

    если в кэше резолвера адреса нет, система запрашивает указанный в сетевых настройках интерфейса сервер DNS;

    сервер DNS смотрит запись у себя, и если у него нет информации даже о домене google.com – отправляет запрос на вышестоящие сервера DNS, например, провайдерские. Если вышестоящих серверов нет, запрос отправляется сразу на один из 13 (не считая реплик) корневых серверов, на которых есть информация о тех, кто держит верхнюю зону. В нашем случае – com.

    после этого наш сервер спрашивает об имени www.google.com сервер, который держит зону com;

  • затем сервер, который держит зону google.com уже выдает ответ.
  • Наглядная схема прохождения запроса DNS.

    Разумеется, DNS не ограничивается просто соответствием «имя – адрес»: здесь поддерживаются разные виды записей, описанные стандартами RFC. Оставлю их список соответствующим статьям.

    Сам сервис DNS работает на UDP порту 53, в редких случаях используя TCP.

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

    Также как и у NetBIOS, у DNS существует кэш, чтобы не обращаться к серверу при каждом запросе, и файл, где можно вручную сопоставить адрес и имя – известный многим %Systemroot%\System32\drivers\etc\hosts.

    В отличие от кэша NetBIOS в кэш DNS сразу считывается содержимое файла hosts. Помимо этого, интересное отличие заключается в том, что в кэше DNS хранятся не только соответствия доменов и адресов, но и неудачные попытки разрешения имен. Посмотреть содержимое кэша можно в командной строке с помощью команды ipconfig /displaydns, а очистить – ipconfig /flushdns. За работу кэша отвечает служба dnscache.

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

    При попытке разрешения имени обычно используются сервера DNS, настроенные на сетевом адаптере. Но в ряде случаев, например, при подключении к корпоративному VPN, нужно отправлять запросы разрешения определенных имен на другие DNS. Для этого в системах Windows, начиная с 7\2008 R2, появилась таблица политик разрешения имен (Name Resolution Policy Table, NRPT). Настраивается она через реестр, в разделе HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DnsClient\DnsPolicyConfig или групповыми политиками.

    Настройка политики разрешения имен через GPO.

    При наличии в одной сети нескольких технологий, где еще и каждая – со своим кэшем, важен порядок их использования.

    Операционная система Windows пытается разрешить имена в следующем порядке:

    проверяет, не совпадает ли имя с локальным именем хоста;

    смотрит в кэш DNS распознавателя;

    если в кэше соответствие не найдено, идет запрос к серверу DNS;

    если имя хоста «плоское», например, «servername», система обращается к кэшу NetBIOS. Имена более 16 символов или составные, например «servername.domainname.ru» – NetBIOS не используется;

    если не получилось разрешить имя на этом этапе – происходит запрос на сервер WINS;

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

  • последняя попытка – система ищет записи в локальном файле lmhosts.
  • Для удобства проиллюстрирую алгоритм блок-схемой:

    Алгоритм разрешения имен в Windows.

    То есть, при запуске команды ping server.domain.com NetBIOS и его широковещательные запросы использоваться не будут, отработает только DNS, а вот с коротким именем процедура пойдет по длинному пути. В этом легко убедиться, запустив простейший скрипт:

    Выполнение второго пинга происходит на несколько секунд дольше, а сниффер покажет широковещательные запросы.

    Сниффер показывает запросы DNS для длинного имени и широковещательные запросы NetBIOS для короткого.

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

    Active Directory тесно интегрирована с DNS и не функционирует без него. Каждому компьютеру домена создается запись в DNS, и компьютер получает полное имя (FQDN — fully qualified domain name) вида name.subdomain.domain.com.

    Для того чтоб при работе не нужно было вводить FQDN, система автоматически добавляет часть имени домена к хосту при различных операциях – будь то регистрация в DNS или получение IP адреса по имени. Сначала добавляется имя домена целиком, потом следующая часть до точки.

    При попытке запуска команды ping servername система проделает следующее:

    если в кэше DNS имя не существует, система спросит у DNS сервера о хосте servername.subdomain.domain.com;

  • если ответ будет отрицательный – система запросит servername.domain.com, на случай, если мы обращаемся к хосту родительского домена.
  • При этом к составным именам типа www.google.com суффиксы по умолчанию не добавляются. Это поведение настраивается групповыми политиками.

    Настройка добавления суффиксов DNS через групповые политики.

    Настраивать DNS суффиксы можно также групповыми политиками или на вкладке DNS дополнительных свойств TCP\IP сетевого адаптера. Просмотреть текущие настройки удобно командой ipconfig /all.

    Суффиксы DNS и их порядок в выводе ipconfig /all.

    Однако утилита nslookup работает немного по-другому: она добавляет суффиксы в том числе и к длинным именам. Посмотреть, что именно происходит внутри nslookup можно, включив диагностический режим директивой debug или расширенный диагностический режим директивой dc2. Для примера приведу вывод команды для разрешения имени ya.ru:

    Из-за суффиксов утилита nslookup выдала совсем не тот результат, который выдаст например пинг:

    Это поведение иногда приводит в замешательство начинающих системных администраторов.

    Лично сталкивался с такой проблемой: в домене nslookup выдавал всегда один и тот же адрес в ответ на любой запрос. Как оказалось, при создании домена кто-то выбрал имя domain.com.ru, не принадлежащее организации в «большом интернете». Nslookup добавляла ко всем запросам имя домена, затем родительский суффикс – com.ru. Домен com.ru в интернете имеет wildcard запись, то есть любой запрос вида XXX.com.ru будет успешно разрешен. Поэтому nslookup и выдавал на все вопросы один ответ. Чтобы избежать подобных проблем, не рекомендуется использовать для именования не принадлежащие вам домены.

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

    Отсюда частые вопросы – почему ping не работает, а nslookup работает.

    В плане поиска и устранения ошибок разрешения имен могу порекомендовать не бояться использовать инструмент для анализа трафика – сниффер. С ним весь трафик как на ладони, и если добавляются лишние суффиксы, то это отразится в запросах DNS. Если запросов DNS и NetBIOS нет, некорректный ответ берется из кэша.

    Если же нет возможности запустить сниффер, рекомендую сравнить вывод ping и nslookup, очистить кэши, проверить работу с другим сервером DNS.

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

    Про политику разрешения имен с локальными суффиксами — ой мама, какие грабли! Реально, кому нужен такой функционал? Разве что типа проксировать запросы в Интернет, запретив на локальных станциях внешний DNS resolve. (Хотя чем не способ применения?)

    Про DNS-курьезы: Недавно один из серверов DNS стал отдавать внутренние адреса по запросам извне. Долго бились, оказалось, в ответы или пакеты передачи зоны (сервер secondary) влезала циска, за которой он сидел за натом, и правила адреса. Исправили, настроив NAT с флагом no-payload.

    В статье хорошо бы еще смотрелось описание проблемы на Windows 10:

    И было бы интересно почитать про резолв, если есть несколько VPN-подключений.

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

    Суффикс добавляется только к неполным именам без точки на конце.

    А вообще, Microsoft писал отличную документацию во времена Windows Server 2003 в которой можно почерпнуть особенности реализации.

    У вас на каждом скрине сниффера видны какие-то буковки LLMNR. В 2017 году подробно рассказывать про netbios и WINS и не упомянуть про это?

    В крупных сетях из-за ограничения на количество записей и срока их жизни кэш уже не спасает. Да и большое количество широковещательных запросов запросто может замедлить быстродействие сети. Для того чтобы этого избежать, используется сервер WINS (Windows Internet Name Service).

    Уменьшение количества броадкастов — это, конечно, хорошо, но WINS решает куда более серьезную проблему — разрешение имен NetBIOS работает только в пределах одного широковещательного сегмента.

    Но в ряде случаев, например, при подключении к корпоративному VPN, нужно отправлять запросы разрешения определенных имен на другие DNS. Для этого в системах Windows, начиная с 7\2008 R2, появилась таблица политик разрешения имен

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

    Для удобства проиллюстрирую алгоритм блок-схемой:

    По вашей блок-схеме ни одно имя короче 16 байт и не разрешимое через NetBIOS или WINS вообще не будет разрешено. Что, очевидно, не так.

    То есть, при запуске команды ping server.domain.com NetBIOS и его широковещательные запросы использоваться не будут, отработает только DNS, а вот с коротким именем процедура пойдет по длинному пути.

    Это не так. Причем ответ на вопрос «почему не так» лежит у вас чуть ниже по тексту, но в очень узком контексте. Вы почему-то наличие у хоста доменных суффиксов привязали к членству в домене AD, политикам и т.п., что неверно.

    Однако утилита nslookup работает немного по-другому: она добавляет суффиксы в том числе и к длинным именам.

    Неверно. Она добавляет суффиксы не к «коротким» или «длинным» в каком-либо смысле именам, а просто к любым неполным (без точки в конце).

    Источник:
    H Конспект админа Домены, адреса и Windows: смешивать, но не взбалтывать
    В очередном «конспекте админа» остановимся на еще одной фундаментальной вещи – механизме разрешения имен в IP-сетях. Кстати, знаете почему в доменной сети nslookup на все запросы может отвечать одним…
    http://sohabr.net/habr/post/330944/

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

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

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

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

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

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

    При запуске с некоторыми из выше перечисленных параметров, команда 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, id = 5, rcode = NXDOMAIN
    header flags: response, want recursion, recursion avail.
    questions = 1, answers = 0, authority records = 1, additional = 0

    ns1.vkontakte.ru, type = A, class = IN

    -> (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, id = 6, rcode = NOERROR
    header flags: response, want recursion, recursion avail.
    questions = 1, answers = 1, authority records = 0, additional = 0

    ns1.vkontakte.ru, type = A, class = IN

    -> 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, id = 7, rcode = REFUSED
    header flags: response, want recursion
    questions = 1, answers = 0, authority records = 0, additional = 0

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

    vk.com, type = ANY, class = IN

    -> 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

    Источник:
    Команда NSLOOKUP — работа с сервером DNS из командной строки
    Команда NSLOOKUP — работа с сервером DNS из командной строки &nbsp &nbsp Утилита NSLOOKUP присутствует в операционных системах Windows, начиная с Windows NT , и предназначена для формирования
    http://ab57.ru/cmdlist/nslookup.html

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

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

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

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

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

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

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

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

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

    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 .

    Источник:
    Не заслуживающий доверия ответ
    Интернет — [решено] Проблема с DNS: имена резолвятся только через nslookup
    http://forum.oszone.net/post-1437615.html

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

    Периодически в сети перестают разрешаются днс имена.Вот например со своего пк пытаюсь пропинговать хост portal.cpn.vwg по айпи все работает
    C:\>ping portal.cpn.vwg

    При проверке связи не удалось обнаружить узел portal.cpn.vwg.
    Проверьте имя узла и повторите попытку.
    тут же ввожу nslookup portal.cpn.vwg все прекрасно разрешается

    nslookup portal.cpn.vwg
    TхЁтхЁ: UnKnown
    Address: 10.18.224.242

    Не заслуживающий доверия ответ:
    Lь : portal.cpn.vwg
    Address: 10.112.198.242

    Через минут 5 все начинает функционировать.Так может несколько раз в день происходить или через день закономерности нет никакой

    ОС на рабочей станции win7 на днс сервере win2008 serv/Днс 10.112.198.242 настроен на пересылку запросов cpn.wvg на сервера 10.112.192.123 и 10.112.192.25.Нашел инфу

    порядок в котором Windows пытается разрешить любое имя:

    1. При разрешении имени сверяется с локальным именем компьютера.
    2. Если локальное имя не совпадает с запрашиваемым, то выполняется поиск в DNS Cash. ВАЖНО: в DNS кэш динамически загружается данные из файла HOSTS ( поэтому поиск по файлу hosts не происходит, его данные всегда в памяти ПК, что ускоряет обработку ). Файл Hosts расположен в %systemroot%\System32\Drivers\Etc
    3. Если имя не разрешилось в IP адрес, то пересылается на DNS сервер, который задан в сетевых настройках.
    4. Если имя сервера плоское ( к примеру: server1 ) и не может быть разрешено с помощью DNS, то имя конвертируется в NetBIOS имя и ищется в локальном кэше
    5. Если имя не может разрешиться, то ищется на WINS серверах
    6. Если имя не может быть определено и на WINS сервере, то ищется с помощью BROADCAST запроса в локальной подсети
    7. Если имя не определилось, то ищется в файле LMHOSTS

    Источник:
    Не заслуживающий доверия ответ
    Периодически в сети перестают разрешаются днс имена.Вот например со своего пк пытаюсь пропинговать хост portal.cpn.vwg по айпи все работает C:\>ping portal.cpn.vwg При проверке
    http://social.technet.microsoft.com/Forums/azure/ru-RU/8416bdc4-7301-4fa3-b40d-7c801ce14d77/-?forum=windows7ru

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

    DNS (система доменных имён) — это система, позволяющая преобразовывать символьные имена доменов в IP-адреса (и наоборот) в сетях TCP/IP.

    и сори за не рабочую ссылку вот рабочая

    вот такое с ним творится:

    C:\Users\grant>nslookup dhl.com
    TхЁтхЁ: cronoz.server.com.ua
    Address: 192.168.2.241

    Не заслуживающий доверия ответ:
    Lь : dhl.com.com.ua
    Address: 77.120.122.115

    C:\Users\grant>nslookup dhl.com 8.8.8.8
    TхЁтхЁ: google-public-dns-a.google.com
    Address: 8.8.8.8

    Не заслуживающий доверия ответ:
    Lь : dhl.com.com.ua
    Address: 77.120.122.115

    C:\Users\grant>nslookup dhl.com 208.67.222.222
    TхЁтхЁ: resolver1.opendns.com
    Address: 208.67.222.222

    Не заслуживающий доверия ответ:
    Lь : dhl.com.server.com.ua
    Address: 67.215.65.132

    А то нет? Ни твой сервер, ни гугловский не являются авторитетными серверами для вышеупомянутого домена.

    nslookup dhl.com
    Server: ns.soft.ru
    Address: 10.1.1.1

    Неофициальный ответ:
    Name: dhl.com
    Address: 165.72.192.235

    nslookup -type=ns dhl.com
    Server: ns.soft.ru
    Address: 10.1.1.1

    Неофициальный ответ:
    dhl.com nameserver = ns6.dhl.com
    dhl.com nameserver = ns4.dhl.com

    ns6.dhl.com internet address = 199.40.254.166
    ns4.dhl.com internet address = 165.72.192.16

    nslookup dhl.com 199.40.254.166
    Server: ns6.dhl.com
    Address: 199.40.254.166

    Name: dhl.com
    Address: 199.40.254.85

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

    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору vlary
    да что тут нормального, дописываются суффиксы, я то могу в сетевой карте на локальной тачке отключить дописывание суффиксов, но это не выход. надо сделать чтобы корректно отрабатывал во всем домене. да и вообще почему так себя ведет днс?

    Ах вон оно чо, Михалыч! То есть, она ко всем запросам твой домен добавляет?
    Ну это ты у себя в конфигах где-то точку не поставил или неправильно поставил.
    Точка в делах DNS — вещь офигенно важная.

    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Grant2k Похоже, это у виндузявого ДНС родовая травна, либо какая-то распространенная ошибка при конфигурации. Вот тут Ссылка один товарисч жаловался на такую же проблему.
    Я бы решил проблему кардинально. Снес бы нафиг это мелкомягкое мелкоумие, и поставил нормальный ISC BIND9 для винды.

    Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору Да это фигня какая-то несусветная. Вот у меня суффикс дописан — но все равно днс без проблем работает.

    C:\Users\sysadmin>nslookup dhl.com
    ╤хЁтхЁ: gw.dmz
    Address: 192.168.44.1

    Не заслуживающий доверия ответ:
    ╚ь : dhl.com
    Address: 165.72.192.235

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

    Дальше настройка сетевой платы на станции или сервере с которого вы запускаете nslookup

    Дальше где расположен ваш dns сервер и его настройки.

    Чего нужно в эфекте побиться?

    У меня мастер живет на CentOS, слейв — на Debian (их же использует АД). Есть, правда, второй слейв на вин2003, исключительно для нужд CommuniGate. Вот он как раз ISC BIND9. Поставил — и забыл.

    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Есть 2 локальных домена с почтовыми серверами. Старый GUKRSK на Win2003 и новый KYAR-CUKS на Win2012 с Exchange2013.
    Старый домен не видит MX запись нового.
    При nslookup -type=mx kyar-cuks.sibirrc.mchs.ru пишет:
    DNS request timed out.
    timeout was 2 seconds.
    ╤хЁтхЁ: UnKnown
    Address: ::1

    KYAR-CUKS.SIBIRRC.MCHS.RU
    primary name server = kyar-cuks-dc0.KYAR-CUKS.SIBIRRC.MCHS.RU
    responsible mail addr = hostmaster.KYAR-CUKS.SIBIRRC.MCHS.RU
    serial = 112
    refresh = 900 (15 mins)
    retry = 600 (10 mins)
    expire = 86400 (1 day)
    default TTL = 3600 (1 hour)
    ничего не говорит про МХ запись.
    При dcdiag /test:dns пишет:
    TEST: Delegations (Del)
    Ошибка: DNS-сервер: kyar-cuks-dc0.kyar-cuks.sibirrc.mchs.ru.
    IP-адрес:10.116.4.106
    [Broken delegated domain KYAR-CUKS.SIBIRRC.MCHS.RU.KYAR-CUKS.SIBIRRC.MCHS.RU.]
    Откуда взялось двойное имя домена?
    Что не так?

    Подскажите советом, где мог ошибиться в настройках DNS сервера:

    Имеется вот такая задача — есть сервис в локальной сети, который необходимо опубликовать в интернет, но так чтоб у него было доменное имя одно.

    имеется домен второго уровня (domen.ru) и внутри локальной сети развернут domen.local

    на днс сервере добавляю прямую зону domen.ru создаю запись A для сервиса внутри локальной сети. (т.е. сам сервис в этом случае имеет третий уровень вида srv.domen.ru)
    На регистраторе в настройках домена добавляю запись srv.domen.ru) и наш сервис доступен как в локальной сети, так и в Интернете.

    НО. Сам домен domen.ru внутри локальной сети становится недоступным. на Хостинге у него расположен сайт и почтовый сервер
    Так вот подскажите где еще я промахнулся с настройками, и как правельнее такое реализовывать.

    За ранее спасибо

    Вы не должны этого делать. На основном нэймсервере, который держит зону domen.ru вы должны описать и/или создать зону srv.domen.ru (как master или slave, вам нужно делать как slave, если поднимаете у себя виндовый домен) и настроить передачу зон), и в ней указать, что ответственный нэймсервер за нее — ваш сервер в записи NS (если сделаете как master). Если создали зону domen.ru у себя, то вы должны внести в нее сами все записи из настоящей зоны domen.ru. Основную зону, кто держит?
    Пример для BIND9

    У меня такая ситуация что при добавлении прямой зоны, в Виндовый ДНС domen.ru
    и назначении записи А для внутри сетевого ресурса ресурс srv.domen.ru становится доступен по внуртилокалочному адресу в локалке и по внешнему адресу из Интернета

    при переходе на этот адрес из локалной сети он ссылается на адрес ДНС сервера который внутри локалки

    nslookup domen.ru
    Domen dc1
    address 192.168.1.2

    Ответ
    domen domen.ru
    Address 192.168.1.2

    получается что при обращении на адрес domen.ru пользователи попадают на адрес ДНС сервера внутри локалки.
    Но сам сервер то расположен у регистратора и сам крутится там же и соответственно адрес то другой.

    Тут то собственно и вопрос как сделать — чтоб стал доступен адрес domen.ru

    когда srv.domen.ru доступен как в локальной сети так и в среде интернет.

    А зачем? Если нужнен доступ к каким-то конкретным сервисам, то нужно просто добавить нужные хосты в зону.
    Скажем, www.domain.ru, mail.domain.ru.
    Во внутренней зоне domain.ru это будут А записи, указывающие на айпи хостра, а во внешней — просто CNAME .на domain.ru.
    Если кого-то сильно ломает набирать www.domain.ru вместо domain.ru,
    то никто не мешает присвоить и во внутренней зоне domain.ru айпи хостера.
    Дабы вместо
    Ответ
    domen domen.ru
    Address 192.168.1.2
    иметь
    Ответ
    domen domen.ru
    Address х.х.х.х

    Как вы подсказали — сделал. и все работает, спасибо огромное

    Источник:
    Не заслуживающий доверия ответ
    Компьютерный форум Ru.Board
    http://forum.ru-board.com/topic.cgi?forum=8&topic=0227&start=1040

    (Visited 1 times, 1 visits today)

    CATEGORIES