Определение IP-адреса по доменному имени (разрешение DNS-имени) выполняется в следующем порядке:

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

- просматривается содержимое файла hosts, и если в нем имеется запись для данного имени, - используется заданный в ней IP-адрес. Этот файл обычно хранится в папке \windows\system32\drivers\etc\

- выполняется запрос на разрешение доменного имени к серверу DNS, задаваемому в настройках сетевого подключения. Соединение выполняется по протоколу UDP на порт 53 сервера. Используется IP-адрес из ответа DNS - сервера.

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

ping mail.ru

Результат выполнения ping:

Обмен пакетами с mail.ru [94.100.191.242] по 32 байт:

Ответ от 94.100.191.242: число байт=32 время=38мс TTL=54
Ответ от 94.100.191.242: число байт=32 время=29мс TTL=54
Ответ от 94.100.191.242: число байт=32 время=30мс TTL=54
Ответ от 94.100.191.242: число байт=32 время=29мс TTL=54

Статистика Ping для 94.100.191.242:
Пакетов: отправлено = 4, получено = 4, потеряно = 0 (0% потерь),
Приблизительное время передачи и приема:
наименьшее = 29мс, наибольшее = 38мс, среднее = 31мс

На заметку. Некоторые узлы настроены таким образом, что блокируют протокол ICMP и не отвечают на эхо-запрос. В результатах выполнения команды будет сообщение об ошибке ("превышен интервал ожидания ответа" . . . ) Кроме того, довольно часто подобные настройки используются брандмауэрами на клиентских компьютерах, в сетях небольших провайдеров и т.п. Отсутствие ответа в результатах выполнения ping совсем не означает недоступность сайта.

Как видно из результатов выполнения ping.exe, доменному имени mail.ru, разрешенному на данном компьютере, соответствует IP-адрес = 94.100.191.242. На следующем шаге нужно определить реальную принадлежность данного адреса домену mail.ru . Для этого можно воспользоваться онлайн - сервисами Whois, которые можно найти на сайтах интернет-провайдеров, хостинговых компаний, регистраторов доменных имен и т.п., или специальными программами, как например, Win32Whois. В поле ввода заносится доменное имя или IP - адрес и нажимается кнопка Go или клавиша Enter



Как видим, IP-адрес 94.100.191.242 в самом деле принадлежит подсети mail.ru
inetnum: 94.100.184.0 - 94.100.191.255
Имя подсети:
netname: MAILRU-NET09
Описание:
descr: Mail.Ru

Если адрес сайта определяется верно, то проблема с созданием соединения по протоколу HTTP между вашим компьютером и сервером mail.ru. Локализация проблемы рассматривается во второй части статьи.

Если же IP-адрес не определен или не имеет никакого отношения к подсети mail.ru то, очевидно, именно в этом кроется причина недоступности сайта. Здесь возможны различные варианты анализа ситуации и применяемых методик для ее исправления.

- IP адрес не может быть определен

Если при выполнении ping получено сообщение, что не удалось обнаружить узел mail.ru, то это означает, что ни один из трех вышеперечисленных способов разрешения доменного имени не дал положительного результата. Поскольку в данном примере рассматривается случай недоступности только одного конкретного сайта, то причиной может быть лишь синтаксическая ошибка в имени или отсутствие записи в базе имен DNS-сервера. Если, например, в имени сервера букву a набрать в русской раскладке, то внешне, отображаемое на экране монитора имя сервера, останется прежним, но не будет соответствовать никакому IP-адресу. Второй вариант может быть вызван несколькими причинами:

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

- произошла подмена DNS-сервера вашего сетевого подключения сторонним (вредоносным) программным обеспечением. Этот вариант довольно экзотический, как и вариант с удалением записей из кэш службы разрешения имен. Особенно в среде Windows 7

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

После запуска, утилита переходит в режим ожидания ввода. Ввод символа ? или команды help позволяет получить подсказку по использованию утилиты.

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

nslookup - запуск утилиты и ожидание ввода в команд.
mail.ru. - отобразить IP-адрес (а) узла с именем mail.ru . Точка в конце имени желательна для минимизации числа запросов на разрешение имени к серверу DNS. Если завершающей точки нет, то NSLOOKUP сначала попытается разрешить указанное имя как часть доменного имени компьютера, на котором она запущена.
server 8.8.4.4 - установить в качестве сервера имен общедоступный DNS-сервер Google с IP-адресом 8.8.4.4 (также можно использовать адрес 8.8.8.8)
mail.ru. - повторить запрос с использованием разрешения имени DNS-сервером Google.

exit - команда завершения работы nslookup

Возможно использование утилиты NSLOOKUP не в интерактивном режиме:

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

В рассматриваемом примере доменному имени mail.ru соответствует группа IP-адресов - это обычная ситуация для крупных доменов. Если доменное имя разрешается с использованием стороннего DNS - сервера, то проблема - в используемом по умолчанию сервере (обычно - DNS сервере вашего провайдера). Для смены используемого DNS сервера можно воспользоваться командой netsh (синтаксис для Windows 7):

netsh interface ipv4 set dnsservers name="Подключение по локальной сети 2" static 8.8.8.8 primary

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

В качестве публичных DNS-серверов, также, можно использовать:

208.67.222.222
208.67.220.220
67.138.54.100
207.225.209.66
156.154.70.1
156.154.71.1
4.2.2.1 - 4.2.2.6


- IP адрес сайта определяется неверно

Здесь, как и в предыдущем случае, возможны варианты:

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

Первые 2 варианта можно разрешить таким же способом, как и рассмотренный выше. Желательно также в подобных случаях обратиться в службу технической поддержки серверов (обычно - к вашему провайдеру), поскольку они могут даже не знать о наличии данной проблемы.

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

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

Стандартно, в операционных системах семейства Windows, файл hosts находится в папке \windows\system32\drivers\etc\ и представляет собой обычный текстовый файл с комментариями (строки, начинающиеся с символа # ) и одной записью в виде:

127.0.0.1 localhost

Запись означает, что для имени localhost используется IP-адрес равный 127.0.0.1 Это, так называемый, петлевой интерфейс ( или внутренняя петля (loopback) , при сетевом обмене через который, реальная передача данных не выполняется. Обычно данный интерфейс используется для межпрограммной передачи данных по IP-протоколу внутри системы, когда и клиент, и сервер находятся на одном компьютере. Если в файл hosts, например, добавить строку: 127.0.0.1 mail.ru

то доменному имени mail.ru будет сопоставлен IP-адрес внутренней петли и сайт станет недоступным. Если же вместо адреса 127.0.0.1 указать, например, IP-адрес поддельного сервера, то посетитель попадет совсем не туда, куда он предполагал попасть. Данный прием нередко используется вредоносными программами для воровства паролей с применением метода подмены страниц регистрации пользователей популярных социальных сетей (vk.com, odnoklassniki.ru, mail.ru... и т.п.)

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

HKLM\System\CurrentControlSet\services\Tcpip\Parameters\DataBasePath

Стандартное значение - строка типа REG_EXPAND_SZ %SystemRoot%\System32\drivers\etc т.е. указывает на каталог, где должен находиться файл hosts. Если запись изменить, например, на %TEMP% то для определения IP-адресов узлов будет использоваться файл hosts из каталога, заданного значением переменной TEMP (каталог временных файлов). Значение переменной TEMP можно посмотреть с использованием команд:

echo %temp%
или
set temp

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

Довольно необычный подход к подмене содержимого файла hosts появился в некоторых вредоносных программах, в частности, семейства Win32/Vundo. Троянец переименовывает "настоящий" файл hosts в файл hоsts, где латинская буква "o" заменена на точно такую же по отображаемому виду, кириллическую "o" и создает поддельный скрытый файл hosts, с правильным именем и поддельным содержанием. Естественно, файл, имя которого содержит русскую букву "о", в разрешении доменных имен не принимает никакого участия и предназначен для введения в заблуждение пользователя, который попытается проверить его содержимое. При ручном просмотре каталога %SystemRoot%\System32\drivers\etc ( стандартно C:\windows\system32\drivers\etc) пользователь либо видит единственный файл hоsts (c измененной буквой в имени) , либо, если включен режим отображения скрытых файлов, - два, одинаковых по написанию имени, файла hosts.



Файловая система Windows не позволяет создать 2 файла с одним и тем же именем. Просто один из них, размером 173 кб и имеющий атрибут "скрытый" - это измененный вирусом файл с правильным именем, а второй - файл, в имени которого изменена латинская буква "o" на русскую букву "о". В файле с неверным именем, который не будет использоваться для разрешения имен в IP-адреса, вирус оставил его исходное содержание, а в файл с правильным - занес нужные для перенаправления записи вроде:

31.214.145.172 mail.ru - для подмены адреса сайта mail.ru
127.0.0.1 avast.com - для блокировки доступа к сайту антивируса Avast!

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

В дополнение.

Для выяснения причин недоступности сайта удобно использовать общедоступные прокси- серверы. Здесь подробности и свежие списки прокси. Дело в том, что при заходе на сайт через прокси сервер, разрешении имен в адреса выполняется программными средствами прокси, а не с использованием службы разрешения имен вашего компьютера. Если через прокси сайт доступен, то проблему нужно искать на вашем компьютере. Если же сайт не доступен и через прокси - возможны варианты, как, например, реконструкция или технические работы, DDoS - атака на сайт, блокировка сайта прокси-сервером в соответствии с его политикой доступа, блокировка по финансовым причинам и т.п. Удобнее всего использовать анонимайзеры (eevropa.ru, http://2ip.ru/anonim/ , http://www.kalarupa.com/ и др.)

Что делать, если причиной недоступности сайта является невозможность соединения по протоколу HTTP

...

В соответствии с первой строкой при соединении с адресами 74.55.40.0 - 74.55.40.255 будет использоваться адрес маршрутизатора 192.168.1.0, т.е. адрес, который является номером сети и никак не может быть использован при обмене данными. Программные средства IP-протокола, определив, что IP-адрес из этого диапазона, например, 74.55.40.226, принадлежащий серверу антивирусного продукта Avast!, не входит в диапазон адресов собственной локальной сети и проверят наличие статического маршрута для нее. Если бы этой записи не было в таблице маршрутизации, то обмен пошел бы через шлюз по умолчанию, но статический маршрут имеет более высокий приоритет и как раз для того и предназначен, чтобы использовать конкретный шлюз, а не общий, принятый для всех внешних (по отношению к своей сети ) адресатов. А поскольку такого шлюза не существует, сервер avast.com с IP=74.55.40.226 станет недоступным для данного компьютера. Если быть точным, то у avast несколько десятков серверов, и конкретно этот адрес принадлежит узлу a529sm.avast.com. При чем в соответствии с маской 255.255.255.0 станут недоступными все адреса в диапазоне 74.55.40.0 - 74.55.40.255, куда попадают не только адреса серверов антивирусной компании, но и адреса других узлов, не имеющих к ней никакого отношения.
Последующие строки в таблице маршрутизации заблокируют новый диапазон IP-адресов
74.55.143.0 - 74.55.143.255
74.86.125.0 - 74.86.125.255
И т.д.
При чем, в одном конкретном случае, таблица маршрутизации содержала более 400 записей подобного вида, что позволило заблокировать более 100000 адресов узлов. Естественно, авторы вируса не особо заботились тем фактом, что кроме антивирусных серверов блокируется и доступ к сайтам, не имеющим к ним никакого отношения. В их числе оказались довольно популярные ресурсы. Мне приходилось сталкиваться с такими случаями, когда "под раздачу" попадали mail.ru, odnoklassniki.ru, vk.com, интернет-поисковики и торрент-трекеры, т.е. популярные ресурсы, регулярно посещаемые пользователями. В какой-то степени, это даже можно считать удачей, поскольку, недоступность случайно посещаемых сайтов, вряд ли была бы логически связана с последствиями вирусного заражения.

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

route delete 74.55.40.0 - удалит первый маршрут в примере.
route delete 74.55.74.0 - удалит второй
и т.д.

Процесс можно упростить, выдав таблицу маршрутизации в файл с использованием перенаправления вывода:

route print > C:\routes.txt

После выполнения команды на диске C: будет создан текстовый файл routes.txt с таблицей маршрутизации. Не обращайте внимания на нечитаемые символы в DOS-кодировке - они вам не нужны. Остается удалить лишнее и перед каждым маршрутом добавить route delete. После чего остается переименовать расширение файла в .bat или .cmd и запустить его на выполнение двойным щелчком. Для тех кто пользуется файловым менеджером FAR задача значительно упрощается. Встроенный редактор FAR, вызываемый по F4 позволяет выделять прямоугольник текста и вырезать его, что позволит быстро отсечь правую часть после адреса. Затем можно выполнить замену всех пробелов на пустой символ (комбинация CTRL-F7), и занести пробел в первую позицию каждой строки. После чего с помощью CTRL-F7 заменить его на route delete (с пробелом после delete). В результате у вас должен получиться командный файл со строками :

route delete 74.50.0.0
route delete 74.52.233.0
route delete 74.53.70.0
route delete 74.53.201.0
route delete 74.54.46.0
...


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

route -f

Параметр -f используется для удаления из таблицы маршрутизации всех записей, которые не являются узловыми маршрутами (маршруты с маской подсети 255.255.255.255), сетевым маршрутом петлевого интерфейса (маршруты с конечной точкой 127.0.0.0 и маской подсети 255.0.0.0) и маршрутами для широковещательной рассылки (с сетевым адресом 255.255.255.255).
Таким образом, маршруты, добавленные вирусом, будут удалены. Естественно, будут удалены и вручную прописанные статические маршруты (если они у вас были) и шлюз по умолчанию (основной шлюз), что приведет к временной недоступности сети. Для пересоздания таблицы маршрутизации на данной конфигурации сетевых интерфейсов, можно просто остановить и снова запустить сетевые адаптеры или перезагрузить систему. После перезагрузки, нормальный доступ в сеть должен быть восстановлен.

Восстановление настроек TCP/IP можно выполнить с помощью антивирусной утилиты AVZ (Пункт 20 меню восстановления системы "Настройки TCP/IP. Удалить статические маршруты").

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

    Статистика Ping дает полную картину обмена между вашим компьютером и пингуемым узлом. Поле TTL в эхо-ответе зависит от реализации IP-протокола отвечающего узла (упрощенно, можно считать, что от типа и версии операционной системы). Необходимо учитывать, что некоторые узлы настроены таким образом, что на ping не отвечают (microsoft.com, например)

Еще примеры использования ping.exe:

ping -t yandex.ru - выполнять ping до нажатия комбинации CTRL-C или CTRL-Break
ping -n 1000 -l 500 192.168.1.1 - выполнить ping 1000 раз с использованием сообщений, длиной 500 байт.
ping -a -n 1 -r 9 yandex.ru - выполнить ping 1 раз (ключ -n 1), определять адрес по имени (ключ -a), выдавать маршрут для первых 9 переходов (-r 9)

    Использование ключа -r, в какой-то степени, позволяет получить трассировку маршрута, аналогичную получаемой с помощью команды tracert.exe, но максимальное число переходов может быть равно 9, чего, обычно, бывает недостаточно. Поэтому желательно использовать tracert.exe.

tracert google.com - трассировка маршрута к узлу google.com

Результат:


Трассировка маршрута к google.com [74.125.45.100] с максимальным числом прыжков 30:
1 1 ms <1 <1 192.168.1.1
2 498 ms 444 ms 302 ms ppp83-237-220-1.pppoe.mtu-net.ru [83.237.220.1]
3 * * * .
4 282 ms * * a197-crs-1-be1-53.msk.stream-internet.net [212.188.1.113]
5 518 ms 344 ms 382 ms ss-crs-1-be5.msk.stream-internet.net [195.34.59.105]
6 462 ms 440 ms 335 ms m9-cr01-po3.msk.stream-internet.net [195.34.53.85]
7 323 ms 389 ms 339 ms bor-cr01-po4.spb.stream-internet.net [195.34.53.126]
8 475 ms 302 ms 420 ms anc-cr01-po3.ff.stream-internet.net [195.34.53.102]
9 334 ms 408 ms 348 ms 74.125.50.57
10 451 ms 368 ms 524 ms 209.85.255.178
11 329 ms 542 ms 451 ms 209.85.250.140
12 616 ms 480 ms 645 ms 209.85.248.81
13 656 ms 549 ms 422 ms 216.239.43.192
14 378 ms 560 ms 534 ms 216.239.43.113
15 511 ms 566 ms 546 ms 209.85.251.9
16 543 ms 682 ms 523 ms 72.14.232.213
17 468 ms 557 ms 486 ms 209.85.253.141
18 593 ms 589 ms 575 ms yx-in-f100.google.com [74.125.45.100]

Трассировка завершена.


    Напомню, как это работает. При разработке IP-протокола, для достижения узлов, адреса которых не принадлежат текущей сети, была предусмотрена маршрутизация, предназначенная для передачи IP-пакетов между разными сетями. Когда вы выполняете команду "tracert google.com", сначала определяется IP-адрес google.com (74.125.45.100), который не принадлежит диапазону адресов вашей локальной сети, задаваемого значением IP-адреса сетевой карты и маской подсети (192.168.1.0-192.168.1.255). Такой пакет будет отправлен маршрутизатору, адрес которого, задан в качестве шлюза по умолчанию. В результатах трассировки вы видите его первым (192.168.1.1). Затем (упрощенно конечно) работает тот же алгоритм - если узел google.com не достижим локально, определяется, через какой маршрутизатор должен быть отправлен пакет, и выполняется его отправка.
    В результатах трассировки, приведенных выше для достижения узла google.com понадобилось 18 переходов. А теперь представьте, что на узле номер 10 (209.85.255.178) для достижения узла google.com ошибочно прописан маршрут не к узлу номер 11, а например, к узлу номер 5. Результатом такой ошибки стало бы зацикливание и вечное циркулирование пакета между узлами 5 и 10. Для того, чтобы подобная ситуация не возникала, разработчики IP-протокола предусмотрительно ввели в заголовок IP-пакетов поле TTL ("Время жизни" - Time To Live) длиной в 1 байт, принимающее значения от 0 до 255. На самом деле это поле не имеет отношения к времени, а является счетчиком числа возможных переходов при передаче маршрутизируемого пакета. Каждый маршрутизатор, получив пакет, вычитает из этого поля 1 и проверяет значение счетчика TTL. Если значение стало равным нулю, такой пакет отбрасывается и отправителю посылается ICMP-сообщение о превышении времени жизни ("Time Exceeded" - значение 11 в заголовке ICMP).
    При выполнении команды tracert.exe сначала выполняется отправка ICMP пакета с полем TTL равным 1 и первый в цепочке маршрутизатор (ваш модем) обнуляет TTL и сообщает о превышении времени жизни. Эта последовательность повторяется трижды, поэтому в строке результата, формируемой tracert.exe, после номера перехода отображаются три значения времени отклика:
1     1 ms     <1     <1     192.168.1.1
1 - номер перехода (1 - первый маршрутизатор, т.е. ваш модем)
1 ms <1 <1 - время его ответа для 3-х попыток (1ms и 2 ответа менее чем 1 ms)
192.168.1.1 - его адрес (или имя)
    Затем процедура повторяется, но TTL устанавливается равным 2 - ваш маршрутизатор его уменьшит до 1 и отправит следующему в цепочке - т.е. маршрутизатору провайдера. Тот после вычитания 1 обнулит TTL и сообщит о превышении времени жизни. И так далее, пока не будет достигнут заданный узел (google.com) или не будет обнаружена неисправность, не позволяющая доставить пакет получателю.
    В результатах трассировки могут присутствовать записи об узлах в виде звездочек (узел номер 3 в примере) - это не является признаком неисправности и скорее всего, говорит о том, что настройки данного узла запрещают ICMP-протокол из соображений безопасности (борьба с DDoS - атаками)

источник:  https://admcomp.ru/nosite.html