--- id: "dns-propagation" kind: "glossary-term" title: "распространение DNS" language: "ru" category: "DNS и технические основы" updated: "2026-10-10T23:12:43Z" canonical: "https://tldlog.com/ru/glossariy/rasprostranenie-dns/" translations: en: "https://tldlog.com/glossary/dns-propagation/" es: "https://tldlog.com/es/glosario/propagacion-dns/" de: "https://tldlog.com/de/glossar/dns-propagation/" fr: "https://tldlog.com/fr/glossaire/propagation-dns/" it: "https://tldlog.com/it/glossario/propagazione-dns/" pt-BR: "https://tldlog.com/pt/glossario/propagacao-dns/" zh-Hans: "https://tldlog.com/zh/cihui/dns-chuanbo/" --- # распространение DNS Неофициальное название задержки, после которой изменение DNS становится видно всем. На самом деле ничего по интернету не распространяется: резолверы просто хранят старые ответы, пока не истечет срок их сохраненных копий. Время ожидания зависит от TTL записей, а при смене DNS-серверов также от собственных настроек TLD. Когда меняются настройки DNS домена, например при переносе сайта или переходе на новые DNS-серверы, не все пользователи видят изменение одновременно. Какое-то время одни попадают на старую конфигурацию, а другие на новую. Это ожидание и называют распространением DNS. ## Что понимают под распространением DNS «Распространение» – неформальное слово. Оно наводит на мысль, что изменение расходится по интернету, но на самом деле никуда ничего не рассылается. Резолверы, то есть серверы, которые ищут имена для пользователей, хранят копии уже полученных ответов и используют их, пока не истечет срок. Только после этого они запрашивают данные снова. В RFC 9499, документе IETF с терминологией DNS, понятия «propagation» нет. Обычно этим словом обозначают изменения двух видов: - Изменение записи в собственной зоне домена, например новая запись A, которая направляет имя на новый веб-сервер. - Смена DNS-серверов. Ее выполняют у регистратора, который передает изменение в регистратуру; затем регистратура публикует новое делегирование в зоне TLD. ## Почему изменения происходят не сразу: кэширование и TTL Основные кэши находятся на рекурсивных резолверах, которые работают у интернет-провайдеров, компаний и общедоступных сервисов. Тупиковый резолвер (stub resolver) на телефоне или компьютере обычно обращается к одному из них. Каждая запись DNS содержит TTL: число секунд, которое задает тот, кто управляет зоной, и которое определяет, как долго можно хранить копию. Время жизни копии в кэше отсчитывается вниз, на нуле копия удаляется, и при следующем запросе запись загружается заново. TTL, равный 0, означает, что запись кэшировать нельзя. TTL – это максимум, а не гарантия. Резолверы могут ограничивать слишком длинные TTL (RFC 8767 рекомендует предел в семь дней), а многие хранят ответы хотя бы несколько десятков секунд, даже если TTL меньше. А главное, никто не может удалить кэшированную копию с чужого резолвера. Именно поэтому и приходится ждать. ## Сколько это занимает на самом деле и как сократить ожидание перед изменением Единой универсальной цифры нет: все зависит от используемых TTL. При изменении записи старый ответ может сохраняться в резолвере не дольше старого TTL записи, считая с момента, когда этот резолвер последний раз ее получил. При TTL 3 600 резолвер может выдавать старый ответ до одного часа после изменения. При смене DNS-серверов складываются три задержки: 1. Регистратор отправляет изменение в регистратуру. 2. Регистратура публикует его в зоне TLD. Для gTLD, работающих по базовому Соглашению об администрировании реестра ICANN (редакция от 21 января 2024 года), уровень обслуживания по состоянию на октябрь 2026 года составляет 60 минут не менее чем для 95% проверочных зондов ICANN. Эта цифра не относится ни к старым gTLD, например .com, у которых свои соглашения, ни к ccTLD. 3. Истекает срок кэшированных записей NS. Зона TLD хранит собственную копию записей NS домена с TTL, который владелец домена изменить не может. Стандартный способ сократить ожидание, описанный в RFC 1034 в 1987 году, – заранее снизить TTL, как минимум за один полный период старого TTL до изменения, внести изменение, а затем снова повысить TTL. Для зон .es Red.es рекомендует обычные значения TTL и Minimum в записи SOA 3 600 секунд и временные значения вплоть до 900 секунд (15 минут) перед крупными изменениями (по состоянию на октябрь 2026 года). Снижение собственных TTL не сокращает срок хранения копии записей NS в зоне TLD. ## Негативное кэширование: почему новое имя может оставаться «несуществующим» Резолверы запоминают и то, что чего-то не существует. Если имя запросили до того, как для него создали записи, резолвер может закэшировать ответ NXDOMAIN (имя не существует) или NODATA (имя существует, но записи такого типа у него нет). Отрицательный ответ хранится в течение меньшего из двух значений в записи SOA зоны: ее собственного TTL и поля Minimum. При обычных значениях Red.es 3 600 и 3 600 (по состоянию на октябрь 2026 года) это до одного часа. RFC 2308 предлагает резолверам по умолчанию ограничивать негативное кэширование сроком от одного до трех часов. Практический вывод: записи нужно создать до того, как проверять или объявлять новое имя. Слишком ранняя проверка может сделать имя «несуществующим» на все время негативного кэширования. ## Как проверить, видно ли изменение - Запросить напрямую авторитативные серверы домена. Они отвечают из зоны, а не из кэша. - Затем запросить один или несколько рекурсивных резолверов. Если они все еще возвращают старые данные, показанный ими TTL означает время, оставшееся до следующего запроса. - При смене DNS-серверов проверить, что серверы TLD возвращают новые записи NS. Именно этот момент измеряет время обновления ICANN. ## Как спланировать переезд без простоя 1. Сначала подготовить новый хостинг или DNS-серверы и убедиться, что новые серверы уже правильно и авторитативно отвечают для домена. Red.es рекомендует это для .es. 2. Заранее снизить TTL, как описано выше. 3. Внести изменение: отредактировать записи или сменить DNS-серверы через регистратора. Для .es изменения делегирования запрашиваются у Red.es по установленной процедуре. 4. Держать старые серверы или хостинг работающими с правильными данными как минимум в течение большего из двух сроков: TTL в зоне TLD и собственного TTL домена. 5. Проверить результат, затем снова повысить TTL. Пример с условными значениями: у example.com есть запись A с TTL 86 400 секунд (одни сутки). За два дня до переноса сайта владелец снижает TTL до 900. Когда истекают сутки старого TTL, владелец меняет запись A, и примерно через 15 минут резолверы, соблюдающие TTL, получают новый адрес. ## Источники - [Domain names - concepts and facilities (RFC 1034)](https://www.rfc-editor.org/rfc/rfc1034.txt) - [Negative Caching of DNS Queries (DNS NCACHE) (RFC 2308)](https://www.rfc-editor.org/rfc/rfc2308.txt) - [Considerations for Large Authoritative DNS Server Operators (RFC 9199)](https://www.rfc-editor.org/rfc/rfc9199.txt) - [Registry Agreement (ICANN base gTLD Registry Agreement, version of 21 January 2024), Specification 10](https://itp.cdn.icann.org/en/files/registry-agreements/base-registry-agreement-21-01-2024-en.html) - [Guía informativa DNS, Versión 1.1 (dominios.es, Red.es)](https://www.dominios.es/sites/dominios/files/2026-02/dns-guia-informativa-y-requisitos-de-configuracion.pdf) ## связанные термины - [кэширование DNS](https://tldlog.com/ru/glossariy/keshirovanie-dns/) - [TTL](https://tldlog.com/ru/glossariy/ttl/) - [резолвер](https://tldlog.com/ru/glossariy/rezolver/) - [NS-запись](https://tldlog.com/ru/glossariy/ns-zapis/) - [негативное кэширование](https://tldlog.com/ru/glossariy/negativnoe-keshirovanie/)