Как обновить dns на компьютере

Обновлено: 02.07.2024

В этой статье описывается, как устранять неполадки на 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-именах.

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

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

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

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

Cisco Umbrella (OpenDNS)

Достоинства:

Давно представлен на рынке
Блокирует фишинг-сайты
Дополнительная веб-фильтрация

Служба OpenDNS была запущена в 2005 году, и в последствии приобретена компанией Cisco, а сейчас является одним из самых известных имен среди общедоступных DNS.

Бесплатный сервис предлагает множество преимуществ: высокая скорость работы, 100% время непрерывной работы, блокировка фишинг-сайтов по умолчанию, веб-фильтрация по типу родительского контроля, бесплатная поддержка по электронной почте.

Коммерческие тарифы позволяют просматривать историю посещений за последний год и настраивать блокировки доступа к определенным ресурсам. Обычному пользователю данные функции могут не понадобиться, а заинтересованным лицам придется потратить порядка 20 долларов в год.

Опытные пользователи может мгновенно начать работу с OpenDNS, перенастроив свое оборудования. Для новичков OpenDNS предлагает инструкции по настройке ПК Windows, Mac, мобильных устройств, маршрутизаторов и др.

Cloudflare (1.1.1.1)

Достоинства:

Отличная производительность
Строгие правила конфиденциальности
Поддержка на форуме сообщества

Компания Cloudflare, известная благодаря своей сети доставки контента, расширила диапазон своих услуг и запустила общедоступную службу DNS под названием 1.1.1.1.

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

Что касается конфиденциальности, то Cloudflare обещает, что не будет использовать данные посещений для показа рекламы и обязуется никогда не записывать IP-адреса источника запросов на диск. Все существующие журналы будут удалены в течение 24 часов. Эти заявления не являются просто маркетинговым ходом. Cloudflare ежегодно привлекает аудиторскую компанию KPMG для анализа своих сервисов и открыто публикуют отчеты.

На веб-сайте 1.1.1.1 собраны инструкции по настройке сервиса на устройствах Windows, Mac, Android, iOS, Linux и на маршрутизаторах. Руководства носят общий характер: например, вы получаете один набор инструкций для всех версий Windows. В таком подходе есть некоторые плюсы, ведь пользователь без особых сложностей сможет выяснить, где настраиваются серверы DNS в его системе. Мобильные пользователи могут использовать приложение WARP, который защищает весь интернет-трафик телефона.

Продукт не предлагает блокировку рекламы и не пытается отслеживать ваши запросы. Однако, Cloudflare ввел фильтрацию вредоносного ПО – серверы 1.1.1.2/1.0.0.2 – и блокировку контента для взрослых – серверы 1.1.1.3/1.0.0.3.

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

Google Public DNS

Достоинства:

Высокая надежность и скорость работы
Прозрачность и соблюдение конфиденциальности

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

Google Public DNS соблюдает довольно строгие правила конфиденциальности. Служба сохраняет полную информацию об IP-адресе запрашивающего устройства в течение примерно 24-48 часов для устранения неполадок и диагностики. «Постоянные» журналы не принимают личную информацию и сокращают сведения о местоположении до уровня города. Более того, все данные, кроме небольшой случайной выборки, удаляются через две недели.

Google предлагает еще одно преимущество для опытных пользователей. Если вы хотите оценить значимость политики конфиденциальности Google, то при желании можете ознакомиться с содержимым журналов сервиса.

Сайт поддержки Google Public DNS предлагает только самые базовые рекомендации, ориентированные на опытных пользователей и предупреждает, что изменения должны вносить только те пользователи, которые умеют настраивать операционную систему. Вы всегда можете обратиться к инструкциями от другого сервиса, например OpenDNS, не забывая заменить IP-адреса DNS-серверов на Google: 8.8.8.8 и 8.8.4.4.

Comodo Secure DNS

Достоинства:

Фокус на безопасность
Обработка припаркованных доменов

Недостатки:

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

Как и следовало ожидать, Comodo Secure DNS уделяет большое внимание безопасности. Сервис не только блокирует фишинговые сайты, но и предупреждает, если вы пытаетесь посетить сайты с вредоносными, шпионскими программами и даже припаркованными доменами, которые могут перегружать вас рекламой (всплывающие окна, рекламные баннеры и др.). Кроме того, вы можете попробовать сервис Comodo Dome Shield, который добавляет дополнительные функции к Comodo Secure DNS.

Comodo говорит об «интеллектуальности» своего DNS-сервиса. Comodo Secure DNS выявляет неиспользуемые припаркованные домены и автоматически перенаправляет вас туда, куда вы хотите попасть.

Что касается производительности, то компания предлагает сеть серверов, расположенных по всему миру и технологию интеллектуальной маршрутизации.

Сервис Comodo интересен как дополнительный уровень веб-фильтрации. На сайте собрано несколько коротких, но полезных инструкций по настройке службы для ПК Windows, Mac, маршрутизаторов и Chromebook.

Quad9 DNS

Достоинства:

Высокий уровень производительности
Блокировка вредоносных доменов

Недостатки:

Quad9 — молодой DNS-сервис, предлагающий быстрые и бесплатные DNS-серверы с августа 2016 года.

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

Что касается производительности, то в рейтинге DNSPerf сервис Quad9 занимает 7-ую строчку, но в абсолютных показателях отстает от лидеров некритично. При разбивке по регионам наилучшие показатели наблюдаются в Северной Америке, но в других частых света задержка минимальная.

Quad9 предлагает инструкции только для последних версий Windows и macOS. Они достаточно подробные, поэтому нетрудно понять, что именно вам нужно делать.

Яндекс.DNS

Достоинства:

Защита от вредоносного ПО
Стабильность

Недостатки:

Яндекс.DNS — бесплатный DNS-сервис от популярной российской поисковой системы Яндекс, запущенный в 2013 году. Сервис предлагает три различных режима: базовый (без дополнительной фильтрации), безопасный (автоматическая защита от вредоносных запросов) и семейный (блокировка контента для взрослых).

Для защиты от вредоносных ресурсов Яндекс.DNS использует данные поиска, движок Sophos и собственный антивирус Яндекс.

Сервис предлагает 80 DNS-серверов, расположенных в разных локациях по всему миру. Запрос пользователя обрабатывает ближайший к нему сервер, что позволяет ускорить загрузку сайтов. На текущий момент в рейтинге DNSPerf Яндекс.DNS занимает только 10 место, что говорит о не самой высокой производительности по сравнению с другими провайдерами.

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

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

Adguard DNS

Достоинства:

Недостатки:

Блокируется не вся реклама из-за технологических ограничений

Adguard DNS — бесплатный DNS-сервис от компании AdGuard, финальная версия которого вышла в декабре 2018 года. Сервис предлагает два режима работы: стандартный и «Семейный контроль». Основное различие между стандартным и семейным режимом заключается в том, что в семейном режиме дополнительно блокируется неприемлемый контент для взрослых.

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

Comss.one DNS

Достоинства

Блокировка рекламы, счетчиков и фишинг-сайтов
Поддержка современных технологий безопасности

Недостатки:

Comss.one DNS использует быстрые и безопасные серверы, расположенные в Европе и России. Доступны отдельные серверы для пользователей из Сибири и Дальнего Востока. Судя по тестам DNS Jumper, Comss.one DNS может похвастаться высокой скоростью работы.

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

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

Что такое DNS?

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

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

Почему важно выбрать быстрый DNS?

DNS-серверы могут заметно отличаться по скорости работы. Особенно это актуально для регионов со слабым покрытием Интернета (Африка, Южная Америка, Океания). Согласно данным сервиса DNSPerf для региона «Океания» время отклика DNS-серверов Cloudflare составляет 6,71 миллисекунды, а DNS-серверов Яндекса — 309,28 миллисекунды. Таким образом, пользователю придется дополнительно ждать более трети секунды , прежде чем браузер сможет получить доступ к любому новому сайту.

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

Еще один важный критерий — стабильность, которую можно оценить по времени безотказной работы (uptime). Если DNS-сервер вашего провайдера не работает, вы не сможете получить доступ к своим любимым любимым сайтам. Крупные провайдеры, такие как OpenDNS, утверждают, что их uptime не снижался ниже 100% на протяжении нескольких лет.

Как выявить самый быстрый DNS?

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

DNS Jumper — бесплатная портативная утилита, позволяющая протестировать несколько публичных DNS-серверов, сравнить их и установить самый быстрый сервис в вашем случае.

Программа имеет много настроек, но очень проста в использовании. Выберите Быстрый DNS > Запустить тест DNS, и через несколько секунд вы получите список DNS-сервисов, отсортированных по скорости.

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

DNSPerf каждую минуту тестирует несколько служб DNS из более чем 200 точек по всему миру и открыто публикует результаты своих тестирований. Сервис дает хорошее общее представление о производительности и времени работы DNS-сервисов.

Как переключить DNS-серверы?

Способ настройки DNS зависит от оборудования и операционной системы.

Прежде всего, вас нужно узнать основной и вспомогательный DNS-серверы. Обычно они отображаются на официальном сайте. Например, Quad9 DNS использует серверы 9.9.9.9 и 149.112.112.112.

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

Для этого войдите в административную панель роутера (пароль по умолчанию обычно указан на самом устройстве) и найдите параметры основного и вспомогательного DNS серверов (в англоязычном интерфейсе: DNS primary и DNS secondary). Сохраните текущие настройки, чтобы, в случае необходимости, сделать откат изменений.

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

Если у вас нет возможности изменить настройки роутера или данный вариант вам не подходит по другим причинам, то вы можете изменить настройки DNS каждого отдельного устройства. Вы можете воспользоваться инструкциями от Cloudflare и OpenDNS.

Как проверить мои текущие DNS-серверы?

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

Далее возможны следующие варианты:

Устройство настроено на использование специфических DNS-серверов
Устройство запрашивает адреса лучших DNS-серверов у роутера при подключении
Обработкой DNS-серверов полностью занимается маршрутизатор

В системах Windows, чтобы проверить DNS-серверы, привязанные к сетевому адаптеру, выполните команду ipconfig /all

Если в записи DNS-серверы указан лишь один адрес – адрес вашего роутера (обычно 192.168.x.x), то обработкой DNS занимается роутер. Введите этот адрес в браузер, войдите в панель управления роутером и укажите необходимые DNS-серверы.

Как протестировать DNS-сервис?

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

Пользователи Windows могут использовать инструмент командной строки nslookup.exe для просмотра результатов любого DNS-сервера без изменения настроек системы:

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

Fenix by Takeda11

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

Как работает 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:

У серверов имен TTL намного больше

Причина, по которой мой регистратор говорил: «Это займёт 48 часов» в том, что TTL на NS-записях (сведения о том, к какому серверу имен должен обратиться рекурсивный сервер) намного больше.

172 800 секунд — это 48 часов! Таким образом, обновление сервера имен, как правило, занимает гораздо больше времени. Время нужно, чтобы закончился срок действия кэшей и распространился новый адрес. Это гораздо дольше, чем просто обновление IP-адреса без изменения вашего сервера имен.

Как обновляются ваши серверы имен

Библиотека DNS-резолвера вашей программы также может кэшировать записи DNS

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

Например, есть статья о настройке JVM TTL для поиска DNS-имен. Я сама писала не так много кода JVM для поиска DNS, но небольшой поиск в интернете о JVM и DNS создает впечатление, что вы можете настроить JVM так, чтобы он кэшировал каждый поиск DNS в течение бесконечного времени (например, см. этот тикет ElasticSearch).

Вот и всё!

Надеюсь, что это поможет вам понять, что происходит при обновлении вашего DNS.

Оговорюсь, что всю историю распространения DNS определяют не только TTL. Некоторые рекурсивные DNS-серверы наверняка не уважают TTL, даже такие основные серверы как 8.8.8.8. Так что даже если вы просто обновляете запись A, указав маленький TTL, возможно, что на практике всё равно будут приходить запросы на старый IP в течение дня или двух.

как еще входить на компы?
вместо имени компа - ip? (для сетевых обращений)
а вместо имени юзера - SID?

вам сударь в пещерный век наверное?

У вас скорее всего в DNS регистрируется сама машина, соответственно владелец DNS записи - аккаунт компьютера.
И другой компьютерный аккаунт его не может перезаписать-ибо нет прав.
Выхода здесь два:
1. Настроить scavenging\aging, чтобы устаревшие DNS записи вовремя удалялись.
2. Использовать в настройках DHCP сервера специальный сервисный AD аккаунт, у которого есть права на создание, удалению и модицификацию DNS записей. Тогда при выдаче адресов DHCP серверов, DNS записи будут создаваться не от имени каждой конкретной машинки, а от имени этого аккаунта. Опишу второй вариант решения подробнее.
1. Создаете в AD сервисный аккаунт типа user.
2. вводите его данные в DHCP консоли в свойствах IPv4

3. Открываете dnsmgmt и свойствах нужных зон во вкладке Security добавляете для аккаунта из пункта 1 права на create\delete all child objects.

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

Смотря кто у вас раздает IP адреса, если это контроллер домена, то вероятно у вас что-то с настройками DNS-сервера на нем.
Как вариант попробуйте поменять время аренды IP адреса в меньшую или большую стороны, в зависимости от текущих настроек.
Захватите запросы и ответы при помощи Wireshark, проанализируйте кто, чего, кому "говорит".
Как себя будут вести проблемные хосты при выполнении команд Win+R-->cmd:

Читайте также: