Почему поменялся dns сервер
Обновлено: 06.07.2024
Многие путаются в обновлении записей DNS, когда изменяют IP-адрес своего сайта. Почему эти записи медленно обновляются? Неужели действительно нужно ждать два дня, чтобы всё обновилось? Почему одни посетители видят новый IP, а другие — старый?
Перевели статью разработчика и автора статей Джулии Эванс, где она отвечает на эти вопросы и популярно рассказывает, что происходит во время обновления DNS с точки зрения фронтендера.
Вот краткое исследование того, что происходит за кулисами, когда вы обновляете запись DNS.
Как работает DNS: рекурсивные и авторитетные DNS-серверы
Во-первых, нам нужно немного объяснить систему DNS. Существует два вида DNS-серверов: авторитетные и рекурсивные
Рекурсивные DNS-серверы сами по себе ничего не знают о том, кому принадлежит какой IP-адрес. Они вычисляют IP-адрес для домена, запрашивая его у соответствующих авторитетных DNS-серверов, а затем кэшируют этот IP-адрес на случай, если их снова спросят о нем. Так, 8.8.8.8 — это рекурсивный DNS-сервер.
Когда люди посещают ваш веб-сайт, они, вероятно, делают DNS-запросы к рекурсивному DNS-серверу. Итак, как же работают рекурсивные DNS-серверы? Давайте посмотрим!
Шаг 1: IP-адреса для корневых DNS-серверов жестко закодированы в его исходном коде. Вы можете увидеть это в исходном коде unbound. Допустим, для начала он выберет 198.41.0.4. Вот официальный источник этих жестко закодированных IP-адресов, также известный как «корневой файл подсказок» (root hints file).
Детали ответа DNS немного сложнее — в этом случае есть раздел авторитетности (authority section) с некоторыми записями NS и дополнительный раздел с записями A, так что вам не нужно делать дополнительный поиск, чтобы получить IP-адреса этих серверов имен.
Мы почти закончили!
Как увидеть все шаги рекурсивного DNS-сервера: dig +trace
Чтобы посмотреть, что рекурсивный DNS-сервер будет делать для резолвинга домена, можно запустить:
Эта команда показывает все DNS-записи, которые запрашивает рекурсивный сервер, начиная с корневых DNS-серверов, то есть все четыре шага, которые мы только что прошли.
Обновим записи DNS
Теперь, когда мы знаем основы работы DNS, давайте обновим некоторые записи DNS и посмотрим, что произойдет.
При обновлении записей DNS существует два основных варианта
- сохранить те же серверы имен;
- изменить серверы имен.
Поговорим о TTL
Но мы забыли кое-что важное. Это пакеты TTL. Как мы сказали ранее, рекурсивный DNS-сервер будет кэшировать записи до истечения срока их действия. Он принимает решение об истечении срока действия записи в зависимости от ее TTL (time to live, времени жизни).
В этом примере сервер имен GitHub для его DNS-записи возвращает TTL 60, что означает 60 секунд:
Вариант 1: обновление записи DNS на тех же серверах имен
Во-первых, я обновила свои серверы имен (Cloudflare), чтобы получить новую запись DNS — запись A, которая сопоставляет test.jvns.ca на 1.2.3.4:
Это сработало немедленно! Не было никакой необходимости ждать вообще, потому что перед этим не было никакой DNS-записи test.jvns.ca, которая могла быть кэширована. Отлично. Но похоже, что новая запись кэшируется в течение примерно пяти минут (299 секунд)
Итак, а если мы попытаемся изменить этот IP-адрес? Я изменила его на 5.6.7.8, а затем запустила тот же DNS-запрос:
Похоже, что на этом DNS-сервере запись 1.2.3.4 всё еще кэшируется в течение 144 секунд. Интересно, что если запросить 8.8.8.8 несколько раз, вы получите противоречивые результаты — иногда он выдает новый IP, а иногда старый. Вероятно, 8.8.8.8 на самом деле распределяет нагрузку на кучу разных бэкендов, у каждого из которых собственный кэш.
После пяти минут ожидания все кэши 8.8.8.8 обновились и всегда возвращали новую запись 5.6.7.8. Потрясающе. Это довольно быстро!
Не всегда можно полагаться на TTL
Как и в большинстве интернет-протоколов, не всё подчиняется спецификации DNS. Некоторые DNS-серверы интернет-провайдеров будут кэшировать записи дольше, чем указано в TTL. Например, в течение двух дней вместо пяти минут. И люди всегда могут жестко закодировать старый IP-адрес в своем файле /etc/hosts.
На практике при обновлении записи DNS с пятиминутным TTL можно ожидать, что большой процент клиентов быстро перейдет на новые IP-адреса (например в течение 15 минут), а затем появится куча отставших, которые будут медленно обновляться в течение следующих нескольких дней.
Вариант 2: обновление ваших серверов имен
Итак, мы видели, что когда вы обновляете IP-адрес, не меняя свои серверы имен, многие DNS-серверы довольно быстро получают новый IP-адрес. Отлично. Но что произойдет, если вы измените свои серверы имен? Давайте попробуем!
В этой статье описывается, как устранять неполадки на 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 или выполните следующую команду:
Изучите сервер-получатель еще раз, чтобы узнать, правильно ли передана зона. В противном случае у вас, вероятно, возникает проблема с переносом зоны. Дополнительные сведения см. в статье проблемы зонных передач.
Если зона была передана правильно, проверьте, правильно ли указаны данные. В противном случае данные в основной зоне неверны. Проблема может быть вызвана ошибкой пользователя при вводе пользователем данных в зону. Кроме того, это может быть вызвано проблемой, которая влияет на 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-именах.
Загрузка цп на 100%, но в других прогах, проц загружен от 1 до 5%
Ребят, сегодня заметил вот такую проблему, полазил в инете, понял только, что загрузка это.
DNS Spoofing - DNS не посылает ответ на адрес, который указан в $src_ip
Здрастье. Есть у меня скрипт, который спуфит DNS пакет и отправляет open resolver'у. Прилагаю.
Как определить IP-адрес сети, зная IP-адрес узла назначения и маску сети
Добрый вечер, форумчане! Дали задачку одну: "Найти IP-адрес сети, зная IP-адрес узла.
Решение
Внимание! Рекомендации написаны специально для пользователя sergeydel. Если рекомендации написаны не для вас, не используйте их - это может повредить вашей системе.
Если у вас похожая проблема - создайте тему в разделе Лечение компьютерных вирусов и выполните Правила запроса о помощи.
______________________________________________________
Пожалуйста, перезагрузите компьютер вручную.
После перезагрузки, выполните такой скрипт:
Возможно следовало об этом этом сообщить раньше, но, как говорят лучше позже, чем никогда.
Это виртуальная машина на которой установлен Microsoft Exchange. Возможно это имеет какое-то значение.
Решение
Пробуйте выполнить тот же скрипт из безопасного режима. Если получится, повторный лог соберите из нормального режима. В безопасном режиме все получилось. Архив quarantine.7z отправил по назначению. Сюда прикрепляю новый лог.Решение
Проверьте уязвимые места:
Выполните скрипт в AVZ при наличии доступа в интернет:
После его работы, если будут найдены уязвимости, в блокноте откроется файл avz_log.txt со ссылками на обновления системы и критичных к безопасности программ, которые нужно загрузить и установить.
В первую очередь это относится к браузерам, Java, Adobe Acrobat/Reader и Adobe Flash Player.
Пройдитесь по ссылкам из файла avz_log.txt и установите все рекомендуемые обновления (если таковые будут).
Перезагрузите компьютер.
Снова выполните этот скрипт и убедитесь, что уязвимости устранены.
Вопрос: Этот скрипт можно выполнять на любом компьютере?
Спасибо.
Перенаправление DNS запросов из локальной сети к DNS серверу провайдера
Добрый день! Необходимо настроить простейший инет шлюз на freebsd и PF. Может кто сможет.
Dhcp+ad+dns+win_srv08 не прописывается gateway в настройках
Поднял ради текста на виртуалбокс виндовс 08 р2 с dhcp+dns+ad. Чтоб поиграться поднял хп и вин7. На.
В настройках Google Chrome поисковая система GetSeach не меняется
В настройках GoogleChrome стоит параметр "Этот параметр включен администратором". Установлен.
На ноутбуке DNS не идут многие игры, даже на минимальных настройках
Здравствуйте, я не знаю куда еще написать и у кого спросить, купила ноутбук 17.3" Ноутбук DNS.
Самопроизвольно устанавливаются программы, в настройках chrome меняется поисковик по умолчанию
Добрый вечер. Устанавливал garena, где-то упустил из внимания галочку, получил в комплекте пачку.
Не могу найти адрес планшета в настройках роутера
Есть админка и пароль от вайфая, но вот в чем проблемау меня нет айпи адрессов, и мак тоже. Я хочу.
Одной из самых частых ошибок связанных с подключением к интернету в Windows, является ошибка: "DNS-сервер не отвечает". При этом, пропадает доступ к интернету. На значке подключения скорее всего будет желтый треугольник, а в браузере, при попытке открыть сайт, вы скорее всего увидите ошибку "Не удается найти DNS-адрес", "err name not resolved ", или что-то в этом роде. Проблема эта вызвана сбоем в работе DNS-сервера, который отвечает за перенаправленные IP-адреса на домен. Если говорить о причинах возникновения этой ошибки, то виновником может быть как сам компьютер, так и маршрутизатор, или оборудование на стороне провайдера.
Сама ошибка "DNS-сервер не отвечает" появляется в результате диагностики сетей Windows. Запустить диагностику очень просто. Достаточно нажать правой кнопкой мыши на значок подключения к интернету, и выбрать "Диагностика неполадок".
Иногда, может появляться ошибка: "Параметры компьютера настроены правильно, но устройство или ресурс (DNS-сервер) не отвечает".
Вот такие ошибки. Если вы не знаете что делать, то сейчас мы рассмотрим несколько эффективных советов, которые должны помочь избавится от данных ошибок. В итоге, интернет на вашем компьютере заработает, и сайты начнут открываться. Решения будут одинаковыми для Windows 10, Windows 8, и Windows 7.
Для начала, я советую выполнить несколько простых решений. Есть шанс, что они помогут, и вам не придется разбираться с более сложными настройками.
- Если у вас интернет подключен через роутер, или модем (по Wi-Fi, или по кабелю) , и вы наблюдаете ошибку "DNS-сервер не отвечает", то попробуйте просто перезагрузить роутер. Отключите питание роутера где-то на минуту, и включите обратно. Не важно какой у вас роутер, TP-Link, D-link, ASUS, или еще какой-то.
- Перезагрузите свой компьютер, или ноутбук. В данном случае не важно, интернет у вас идет через роутер, или кабелем напрямую от провайдера. Просто выполните перезагрузку.
- Если интернет подключен через роутер, то проверьте, работает ли интернет на других устройствах. Нет ли там ошибки с ответом DNS-сервера.
- При подключении через маршрутизатор, если есть возможность, можно подключить интернет напрямую к компьютеру. Для проверки.
- Постарайтесь вспомнить, после чего появилась ошибка DNS, и проблемы с доступом к интернету. Может после смены каких-то настроек, или установки программ.
Если эти советы не помогли, то попробуйте применить решения, о которых я напишу ниже.
Проверяем службу DNS-клиент
Прежде чем что-то менять, я рекомендую посмотреть, работает ли служба "DNS-клиент". Нажмите на клавиатуре сочетание клавиш Win + R. В появившемся окне введите команду services.msc, и нажмите Ok.
В новом окне ищем службу "DNS-клиент", нажимаем на нее правой кнопкой мыши, и выбираем "Свойства".
Тип запуска должен быть "Автоматически". И если у вас кнопка "Запустить" будет активной, то нажмите на нее. Дальше: "Применить" и "Ok".
Если служба у вас была отключена, и вы ее включили, то после перезагрузки компьютера интернет должен заработать.
Меняем настройки DNS-серверов в свойствах подключения
Дальше мы проверим настройки DNS-серверов в свойствах подключения, через которое компьютер подключен к интернету. Если там прописаны какие-то адреса, то можно попробовать выставить автоматическое получение, либо прописать DNS-адреса от Google. Этот способ очень часто позволяет избавится от ошибки "DNS-сервер не отвечает".
Нам нужно открыть окно со всеми подключениями. Для этого можно нажать правой кнопкой мыши на значок подключения к интернету, и выбрать "Центр управления сетями. ". Дальше переходим в "Изменение параметров адаптера".
Дальше правой кнопкой мыши нажимаем на то подключение, через которое вы подключены к интернету (к роутеру) , и выбираем "Свойства". Если подключение по Wi-Fi, то это подключение "Беспроводная сеть", если по кабелю, то "Ethernet" (Подключение по локальной сети) .
У меня, например, проблема с DNS при подключении по Wi-Fi сети через роутер.
В новом окне выделите "IP версии 4 (TCP/IPv4)", и нажмите "Свойства". Если в новом окне у вас прописан какой-то DNS-сервер, то можно попробовать выставить автоматическое получение адресов, и проверить подключение к интернету после перезагрузки компьютера.
Но чаще всего помогает следующее: ставим переключатель возле "Использовать следующие адреса DNS-серверов", и прописываем DNS от Google:
Нажимаем "Ok" и перезагружаем компьютер.
Такое решение помогает очень часто. Если у вас проблема с получение DNS на всех устройствах, которые подключены через один роутер, то эти адреса можно прописать в настройках роутера, тогда они будут применяться для всех устройств. Как правило, сделать это можно в настройках вашего роутера, в разделе "Интернет", или "WAN". Где задаются параметры для подключения к провайдеру.
Для примера, покажу как это сделать на роутере TP-Link:
Не забудьте сохранить настройки.
Очищаем кэш DNS и другие сетевые параметры
Нужно просто запустить командную строку, и по очереди выполнить несколько команд, которые выполнять очистку кэша DNS-адресов, и других сетевых настроек. Этот способ подойдет как для Windows 10, так и для Windows 7 (8).
Командную строку нужно запустить от имени администратора. Если у вас Windows 10, то просто нажмите правой кнопкой мыши на меню пуск, и выберите "Командная строка (администратор)". В Windows 7, в поиске можно набрать "cmd", нажать правой кнопкой на "cmd" в результатах поиска, и выбрать "Запустить от имени администратора".
По очереди копируем и выполняем такие команды:
ipconfig /flushdns
ipconfig /registerdns
ipconfig /renew
ipconfig /release
В Windows 10 можно еще попробовать выполнить сброс сетевых настроек. Это практически то же самое.
После этого перезагрузите компьютер.
Обновление: отключаем или удаляем антивирус Avast
В комментариях Сергей написал, что ему помогло только удаление антивируса Avast. Если у вас установлен именно этот антивирус, то возможно он стал причиной того, что DNS-сервер перестал отвечать.
По своему опыту могу сказать, что антивирус Avast очень часто вмешивается в сетевые настройки Windows, из-за чего появляются разные проблемы с подключением к интернету. То интернет перестает работать после удаления антивируса, то ошибка DNS, или сетевой адаптер не имеет допустимых параметров настройки IP.
Можно попробовать для начала полностью остановить работу антивируса. Если это не решит проблему, то удалить его. Можно переустановить его, только без дополнительных модулей. Как это сделать, я писал в статье по ссылке выше (о решении проблемы с параметрами IP) .
Если вы все проделали правильно, но Windows по прежнему пишет что DNS-сервер не отвечает, то у меня есть еще пару советов:
Обязательно напишите, если у вас получилось избавится от этой ошибки. Напишите какой способ помог. Может у вас сработало какое-то другое решение, которого нет в статье. Ну и оставляйте свои отзывы в комментариях.
Читайте также: