Вы обновляете DNS-записи домена, сохраняете изменения и ожидаете, что новый сайт или почтовый сервис начнут работать немедленно. Однако коллега всё ещё видит старый сайт, онлайн-проверка показывает другой адрес, а доставка электронной почты ведёт себя нестабильно. Эта задержка обычно называется Распространение DNS.
Фраза может создавать впечатление, будто одно обновление проходит через центральную систему Интернета. Однако DNS является распределённой системой. Информация о доменах хранится и кэшируется на авторитетных серверах имён, рекурсивных резолверах, маршрутизаторах, операционных системах и приложениях. Каждая система может обновлять свою информацию в разное время.
Большинство изменений в DNS становятся видимыми по мере истечения времени кэширования и получения резолверами новых записей. Длительность этого процесса зависит от предыдущего значения Time to Live (TTL) записи, поведения резолверов и корректности конфигурации авторитативного DNS. Не существует универсального времени, которое гарантировало бы, что каждый пользователь увидит новый ответ.
Это руководство объясняет, что люди подразумевают под распространением DNS, почему изменения в DNS появляются в разное время, как проверить текущие ответы домена и что делать, если обновление всё ещё кажется неполным.
Что означает распространение DNS?
Распространение DNS — это общепринятый термин, обозначающий период, в течение которого различные пользователи или DNS-резолверы могут получать разные ответы после изменения DNS-записей. Пользователь в одной сети уже может видеть новый IP-адрес, тогда как резолвер другого пользователя продолжает возвращать закэшированный старый адрес.
Фактическое изменение DNS выполняется на авторитативных серверах имен для домена. Рекурсивные резолверы затем получают и кэшируют записи для своих пользователей. Эти резолверы не обязательно запрашивают авторитативные серверы каждый раз, когда кто-то посещает домен. Они могут повторно использовать кэшированный ответ, пока он остается действительным.
Именно поэтому «пропагацию» лучше понимать как срок действия кэша и обновление. Нет единой центральной копии, которая должна обновляться одновременно на всех устройствах, подключённых к Интернету. Авторитетная запись может уже быть корректной, в то время как некоторые резолверы продолжают обслуживать более старые данные из кэша.
Как работает кэширование DNS
Когда браузеру нужно найти IP-адрес домена, он просит операционную систему выполнить разрешение имени. Операционная система может иметь кэшированный ответ. Если его нет, она обращается к настроенному рекурсивному резолверу, например, тому, который обслуживается интернет-провайдером, компанией или публичной DNS-службой.
Рекурсивный резолвер также может иметь закэшированный ответ. Если этот ответ всё ещё находится в пределах времени жизни кэша, он может вернуть его без обращения к авторитетным серверам имён. Когда срок действия закэшированной записи истечёт, резолвер может выполнить запрос к системе авторитетных DNS и сохранить обновлённый ответ.
Кэширование сокращает время поиска и нагрузку на DNS-инфраструктуру. Это также означает, что изменения записей не обязательно становятся видимыми для всех резолверов одновременно. Старый ответ остаётся доступным для резолвера до истечения срока его кэширования или пока резолвер не обновит его иным образом.
Разные пользователи могут использовать различные рекурсивные резолверы. Даже люди в одном доме могут видеть разные ответы, если их устройства используют разные DNS-сервисы, VPN, мобильные сети или локальные кэши.
Что такое TTL в DNS?
TTL означает Время жизни. Это значение, обычно измеряемое в секундах, которое указывает рекурсивным резолверам, как долго они могут кэшировать DNS-запись перед проверкой обновлённого ответа.
Например, TTL 3600 означает один час. Если резолвер получает запись с таким TTL, он обычно может продолжать использовать ответ в течение часа, прежде чем потребуется его обновление. Значение TTL 300 означает пять минут.
TTL, который имеет значение после изменения, обычно является TTL старой записи, которую резолверы уже закэшировали. Снижение TTL непосредственно перед изменением записи может не сократить время ожидания для резолверов, которые закэшировали предыдущую запись с более высоким TTL. Эти резолверы могут продолжать использовать старый ответ до истечения первоначального периода кэширования.
Для запланированных миграций администраторы часто заранее уменьшают значение TTL, выжидают достаточно времени для истечения предыдущего значения TTL, а затем вносят изменения в DNS. После стабилизации изменений они могут снова увеличить TTL, чтобы сократить количество повторяющихся запросов. Подходящие значения зависят от сервиса и процесса внесения изменений оператором.
Почему изменения DNS занимают разное время?
Наиболее распространённая причина заключается в том, что резолверы имеют разные кэшированные копии. Некоторые уже обновили запись, тогда как другие всё ещё используют неистёкший ответ. Резолвер также может применять собственное поведение обновления или кэшировать отрицательные ответы — то есть ответы, указывающие на отсутствие записи.
Локальное кэширование может добавить ещё один уровень. Компьютер, маршрутизатор, браузер или приложение безопасности могут временно сохранять информацию DNS. Перезапуск браузера или очистка кэша DNS операционной системы может помочь в некоторых случаях, но это не изменит то, что рекурсивный резолвер всё ещё имеет в своём кэше.
Изменения провайдера DNS могут вносить дополнительные временные факторы. Если вы измените авторитетные серверы домена у регистратора, резольверам может потребоваться обновить информацию о делегировании, а также записи, обслуживаемые этими серверами. Это отличается от изменения записи A или AAAA в рамках одного и того же сервиса DNS-хостинга.
Наконец, обновление может быть некорректным на авторитативном источнике. Если был отредактирован неверный запись, изменение не было сохранено, домен использует другие авторитативные серверы имён или в записи содержится синтаксическая ошибка, ожидание не исправит базовую конфигурацию.
Распространение DNS против обновлений авторитативного DNS
Авторитетный DNS-сервер предоставляет официальные записи для домена или зоны. Когда вы редактируете запись в панели управления вашего провайдера DNS, провайдер должен обновить авторитетные данные, которые он обслуживает.
Рекурсивный резолвер предоставляет ответы DNS клиентским устройствам. Он может содержать кэшированные данные, полученные до изменения. Таким образом, авторитативный сервер может возвращать новый адрес, в то время как рекурсивный резолвер продолжает возвращать старый.
Это различие полезно при устранении неполадок. Сначала проверьте, что возвращают авторитетные серверы имён. Если они уже содержат ожидаемую запись, значит, изменение опубликовано в источнике, а оставшиеся расхождения, вероятно, вызваны кэшированием или поведением резолвера. Если авторитетные серверы всё ещё возвращают старое значение или отсутствие значения, следует проверить конфигурацию поставщика DNS и сами записи.
Изменение серверов имён добавляет ещё один уровень. Родительская зона DNS должна указывать на предполагаемые авторитетные серверы имён, и эти серверы должны обслуживать правильную зону. Правильная запись у поставщика DNS не будет иметь эффекта, если домен делегирован серверам имён другого провайдера.
Общие изменения DNS и их последствия
Изменение Запись changes the IPv4 address returned for a hostname. Changing an Запись AAAA изменяет свой IPv6-адрес. Если оба присутствуют, клиенты могут использовать любое семейство адресов в зависимости от их сетевых параметров и поведения подключения.
Изменение Запись CNAME изменяет имя хоста, на которое указывает псевдоним. Резолверам может потребоваться выполнить поиск целевого имени и его адреса. Изменение записей целевого имени может повлиять на конечный результат, даже если сам CNAME остаётся неизменным.
Изменение MX-запись Влияет на то, какие почтовые серверы получают электронную почту для домена. Почтовые системы могут кэшировать эти записи, и маршрутизация электронной почты может занять время для отражения изменений. При смене почтовых провайдеров администраторам следует отдельно проверять MX-записи и любые связанные записи аутентификации почты, такие как SPF, DKIM или DMARC.
Изменение имена серверов Изменение провайдера DNS, ответственного за домен. Это требует правильной делегации на уровне регистратора и корректной настройки зоны у нового провайдера. Переход на другие серверы имён следует планировать тщательно, поскольку отсутствие необходимых записей у нового провайдера может привести к недоступности веб-сайтов, электронной почты или других сервисов.
Как проверить, появились ли изменения в DNS
Начните с запроса домена с компьютера, который вы используете. В Windows, macOS и Linux nslookup широко доступен:
nslookup example.comДля проверки записи IPv4-адреса используйте:
nslookup -type=A example.comДля IPv6:
nslookup -type=AAAA example.comДля записей почтового сервера:
nslookup -type=MX example.comНа macOS и Linux, копать предоставляет более подробный вывод:
dig example.com AПоказывать только раздел с ответом:
dig example.com A +noall +answerВы можете запросить конкретный рекурсивный резолвер, чтобы сравнить ответы. Например:
dig @1.1.1.1 example.com AВ Windows можно указать DNS-сервер с помощью:
nslookup example.com 1.1.1.1Заменить example.com с вашим доменом. Адрес резолвера в этих примерах — лишь один из возможных публичных резолверов; вы также можете использовать DNS-сервис, предоставляемый вашей организацией или провайдером.
Запишите резолвер, который вы запросили, ответ и время. Сравнение результатов от нескольких резолверов помогает определить, является ли разница локальной для одного резолвера или проявляется более широко.
Как запросить авторитетный сервер имен
Чтобы найти авторитетные серверы имён для домена, используйте:
dig example.com NSЗатем выполните запрос к одному из этих серверов имён напрямую для записи, которую вы изменили:
dig @ns1.example-dns.com example.com AЗаменить ns1.example-dns.com с авторитетным сервером, указанным для вашего домена. Если прямой запрос возвращает ожидаемый адрес, но рекурсивный резолвер возвращает старый, данные на авторитетном сервере обновлены, а резолвер может всё ещё использовать кэшированный ответ.
Вы также можете спросить копать отследить процесс делегирования:
dig +trace example.comЭто следует иерархии DNS от корневого уровня к авторитетным серверам домена. Это может помочь выявить проблемы делегирования, хотя его вывод более детализирован, чем требуется для большинства базовых проверок.
Если вы используете панель управления DNS-провайдера, убедитесь, что домен действительно делегирован на те серверы имён, которые указаны там. Запись может быть корректной в панели одного провайдера, тогда как публичный домен указывает на другого провайдера.
Что делать, если некоторые пользователи видят старый сайт?
Сначала убедитесь, что авторитетная запись A или AAAA имеет ожидаемое значение. Затем выполните запрос к нескольким рекурсивным резольверам и проверьте, возвращают ли они тот же ответ. Если авторитетные данные верны, но некоторые резольверы возвращают более старый адрес, вероятной причиной является кэширование.
Далее проверьте локальную конфигурацию пользователя. VPN, корпоративный DNS-резолвер, средство безопасности, кэш браузера или локальный файл hosts могут влиять на то, какой адрес возвращается. Сравните результат с другого сетевого подключения, например мобильного, чтобы увидеть, меняется ли поведение.
Также следует проверить, отвечают ли как старый, так и новый серверы. Миграция может выглядеть несогласованной, если старый хост всё ещё обслуживает кэшированную копию или перенаправляет запросы иным образом. Запись DNS может быть корректной, однако старый сервер остаётся доступным для пользователей, чьи резолверы ещё не обновились.
Если проблема затрагивает только IPv4 или только IPv6, сравнивайте записи A и AAAA отдельно. Устройство может подключаться через IPv6, в то время как другое использует IPv4. Одна адресная семья может указывать на новый сервер, а другая — по-прежнему на старый.
Что делать, если сайт недоступен после изменения DNS?
Проверьте, что авторитетные серверы имён домена корректны и доступны. Затем убедитесь, что соответствующие записи существуют на этих серверах. Если вы недавно изменили серверы имён, убедитесь, что новый провайдер DNS содержит все необходимые записи, включая записи для сайта, электронной почты, верификации и служб.
Убедитесь, что целевой сервер готов принимать соединения для домена. Обновление DNS только изменяет направление клиентов. Оно не настраивает веб-сервер, не устанавливает сертификат, не открывает порт в брандмауэре и не копирует файлы сайта.
Если DNS возвращает ожидаемый IP-адрес, но сайт всё равно не работает, протестируйте сервер и приложение отдельно. Проблема может быть связана с веб-сервером, брандмауэром, сертификатом TLS, настройками хостинга или приложением. Проверка DNS подтверждает разрешение имени; она не гарантирует работоспособность сервиса.
Для общей проверки маршрута между вашим устройством и пунктом назначения см. наше руководство использование traceroute для диагностики проблем с сетевым соединениемТрассировка маршрута и поиск DNS проверяют различные части соединения, поэтому их совместное использование полезно при сужении круга возможных проблем.
Отрицательное кэширование и результаты «Запись не найдена»
Резолверы могут кэшировать факт отсутствия записи. Это называется отрицательным кэшированием. Если резолвер запросил имя до создания записи, он может временно продолжать возвращать ответ «не найдено», даже после того как запись была добавлена.
Отрицательное кэширование также имеет TTL, основанный на информации из SOA-записи зоны и правилах резолвера. Точное поведение может различаться. Если вновь созданный поддомен не разрешается немедленно, сначала проверьте авторитативный DNS-сервер. Если он возвращает новую запись, подождите, пока истечёт срок действия отрицательных кэшей, и сравните результаты с другими резолверами.
Ответ «запись не найдена» также может указывать на то, что запись была добавлена в неправильную зону, имя хоста было введено неверно или домен использует другие авторитетные серверы имён. Перед тем как предположить, что проблема заключается только в задержке распространения DNS-данных, убедитесь в правильности полного имени хоста, типа записи и поставщика услуг DNS.
Как спланировать миграцию DNS
Перед изменением записей для производственного сервиса перечислите все имена хостов и запишите, от каких записей зависит сервис. Веб-сайт может использовать записи A и AAAA, тогда как почта зависит от записей MX, SPF, DKIM и DMARC. Приложения также могут опираться на записи проверки подлинности или обнаружения сервисов.
Если изменение запланировано, заранее уменьшите соответствующее значение TTL и подождите как минимум предыдущий период TTL перед переключением назначения. Подготовьте новый сервер или провайдера до обновления DNS. Протестируйте напрямую, где это возможно, и убедитесь, что сертификаты, правила брандмауэра, настройки приложения и почтовые службы готовы.
После внесения изменений проверьте авторитетные ответы и несколько рекурсивных резолверов. Отслеживайте доступность веб-сайта, доставку электронной почты и ошибки в приложениях. По возможности сохраняйте старый сервис во время перехода, поскольку некоторые пользователи могут продолжать обращаться к нему до истечения срока действия закэшированных ответов.
После стабилизации новой конфигурации восстановите подходящее значение TTL. Постоянное использование очень низкого значения TTL может увеличить объём DNS-запросов, не принося существенной пользы для службы, которая редко изменяется.
Распространённые заблуждения о распространении DNS
Одно из распространённых заблуждений заключается в том, что каждое изменение DNS занимает ровно 24 или 48 часов. Не существует фиксированной универсальной продолжительности. Фактическая задержка зависит от предыдущих значений TTL, кэширования резолверов, изменений делегирования и корректности конфигурации авторитативных серверов.
Ещё одно заблуждение заключается в том, что очистка кэша браузера обновляет DNS повсеместно. Она может очистить информацию, сохранённую на этом устройстве, но не способна очистить кэш удалённого рекурсивного резолвера. Аналогичным образом, перезапуск маршрутизатора может очистить его локальный кэш, но не изменяет авторитетные записи.
Третье заблуждение заключается в том, что DNS-чекер, показывающий разные ответы, доказывает, что домен сломан. Разные ответы могут возникать во время запланированной миграции, особенно когда резолверы кэшируют данные в разное время. Важный вопрос — правильны ли авторитетные записи и соответствуют ли оставшиеся различия предыдущему TTL.
Наконец, распространение DNS не настраивает целевой сервис. Даже при правильном IP-адресе сайт может быть недоступен, если сервер, брандмауэр, TLS-сертификат или приложение не готовы.
Часто задаваемые вопросы о распространении DNS
Сколько времени занимает распространение DNS?
Нет единой гарантированной продолжительности. Некоторые изменения проявляются быстро, тогда как другие остаются нестабильными до истечения срока действия кэшированных записей. На время распространения влияют предыдущее значение TTL, поведение резолверов и то, были ли изменены серверы имён.
Приводит ли снижение TTL к мгновенному изменению?
Нет. Снижение значения TTL влияет на последующее кэширование после того, как резолверы получат новый TTL. Резолверы, которые уже закэшировали старый рекорд, могут продолжать его использовать до истечения предыдущего TTL.
Почему DNS-чекеры показывают разные результаты?
Они могут обращаться к различным рекурсивным резолверам из разных мест. Эти резолверы могут иметь разные закэшированные ответы, обновляться в разное время или получать различные ответы из-за географических политик DNS.
Следует ли очищать кэш DNS на компьютере?
Это может помочь, когда ваше собственное устройство кэшировало старый ответ. Это не очищает кэши, удерживаемые вашим интернет-провайдером, корпоративным резолвером или публичной службой DNS.
Почему мой сайт разрешается, но всё равно не загружается?
DNS может возвращать правильный адрес, но на стороне целевого сервера или приложения возникает проблема. Проверьте веб-сервер, брандмауэр, сертификат TLS и конфигурацию хостинга отдельно.
Могут ли изменения имен серверов занимать больше времени, чем изменения записей?
Они могут включать дополнительную информацию о делегировании у регистратора и в родительской зоне DNS. Новый провайдер также должен предоставлять полную и корректную зону. Проверьте как делегирование, так и записи на новых авторитетных серверах.
Изменения DNS могут проявляться в разное время, поскольку авторитативные серверы имён и рекурсивные резолверы выполняют разные функции, а резолверы кэшируют ответы в соответствии со значениями TTL. Один пользователь может видеть старый адрес, тогда как другой уже получает новый.
Для проведения расследования сначала проверьте авторитетные серверы имён, а затем сравните ответы от нескольких рекурсивных резолверов. Подтвердите тип записи, имя хоста, время жизни (TTL) и делегирование серверам имён. Если DNS возвращает ожидаемый адрес, но служба остаётся недоступной, проверьте целевой сервер и приложение как отдельные компоненты проблемы.
Понимание принципов кэширования упрощает планирование и устранение неполадок при изменении DNS. Для получения дополнительных сведений об основах работы сетей продолжайте изучать наши руководства по Адреса IP, стандартные шлюзы, и traceroute.