Долго не обновляется dns

Обновлено: 04.07.2024

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

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

Откройте окно командной строки от имени администратора на клиентском компьютере.

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

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

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

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

Если у клиента нет допустимой конфигурации TCP/IP, используйте один из следующих методов.

Для динамически настроенных клиентов используйте ipconfig /renew команду, чтобы вручную обновить конфигурацию IP-адресов на DHCP-сервере.

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

Проверка сетевого подключения

Проверка связи

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

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

Если ни один настроенный DNS-сервер не отвечает на прямую проверку связи с IP-адресом, это означает, что источником проблемы является более вероятное сетевое подключение между клиентом и DNS-серверами. В этом случае выполните основные действия по устранению неполадок сети TCP/IP, чтобы устранить проблему. Помните, что для работы команды ping трафик ICMP должен быть разрешен через брандмауэр.

Тесты запросов DNS

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

Тестирование клиента

Например, если клиентский компьютер имеет имя КЛИЕНТ1, выполните следующую команду:

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

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

если Windows успешно найдет полное доменное имя, но не сможет найти его, проверьте конфигурацию dns-суффикса на вкладке dns расширенного протокола TCP/IP Параметры сетевого адаптера. Дополнительные сведения см. в разделе Настройка разрешения DNS.

Тестирование DNS-сервера

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

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

Тестирование записи, в которой происходит сбой

Проверка общедоступного адреса в Интернете

Чтобы устранить эту проблему, очистите кэш, выполнив ipconfig /flushdns .

Следующий шаг

Если разрешение имен по-прежнему не выполняется, перейдите к разделу Устранение неполадок 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 в течение дня или двух.

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

Применяется к: Windows Server 2012 R2
Исходный номер КБ: 3069564

Симптомы

Динамические обновления регистраций DNS, выполняемые сервером DHCP от имени компьютера с поддержкой DHCP, обрабатываются или не обрабатываются после выполнения службы DHCP некоторое время.

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

Причина

В версиях Windows Server, которые находятся раньше Windows Server 2008, сервер DHCP использует DNS-серверы, настроенные в свойствах TCP/IP сетевых подключений в качестве цели динамических обновлений.

Изменение поведения динамического обновления DHCP заставляет серверы DHCP в Windows Server 2008 и более поздних версиях выбрать DNS-сервер по следующим критериям в заданном порядке:

Параметры Области
Параметры сервера
Конфигурация TCP/IP сетевых подключений

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

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

Решение

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

Обходной путь

Чтобы переопредить поведение по умолчанию в Windows Server, используйте следующее значение реестра.

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

Дополнительная информация

По крайней мере один администратор сообщил об успешном предотвращении задержки регистрации обновлений DNS, выбрав параметрЫ записей DNS A и PTR на сервере DHCP. Мы не считаем это действие жизнеспособным обходным путем и не определили, почему оно может быть эффективным. Однако эта информация может оказаться полезной.

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

Сколько по времени обновляется DNS? На этот вопрос, точного ответа вам никто не даст, так как обновление dns зависит от того, как часто именно ваш интернет провайдер производит очистку кэша dns. Некоторые провайдеры, такую очистку производят 1 раз в день (чаще всего после полуночи), другие 1 раз в 2 дня, а бывает и такое, что 1 раз в 7 дней.

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

Есть 2 выхода из этой ситуации:

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

Как быстрее обновить DNS?

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

Теперь можно приступать к процедуре. Для ее реализации, вам понадобится знать:

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

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

После того, как его нашли, нужно его открыть. Можно открыть даже блокнотом, но я предпочитаю пользоваться Notepad ++. Затем в самом конце документа необходимо дописать строчку, которая будет состоять из вашего IP-адреса и через пробел дописывается доменное имя. Что-то типа такого:

В самом файле же, это будет выглядеть вот так:

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

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

Теперь, когда вы знаете, сколько обновляются DNS и как этот процесс можно обойти, вы сможете, пока идет это обновление, настроить, или наполнить свой сайт материалами.

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