Это Канонический вопрос о распространении DNS
Сколько времени требуется для распространения различных типов записей?
Некоторые распространяются быстрее, чем другие?
Почему для распространения записей DNS требуется время и как это работает?
«Распространение DNS» само по себе не является реальным явлением. Скорее, это явный эффект функции кэширования, указанной в протоколе DNS. Утверждение, что изменения «распространяются» между DNS-серверами, является удобной ложью, которую, возможно, легче объяснить нетехническим пользователям, чем описывать все детали протокола DNS. Однако на самом деле протокол работает не так.
Рекурсивные DNS-серверы делают запросы от имени клиентов. Рекурсивные DNS-серверы, обычно управляемые интернет-провайдерами или ИТ-отделами, используются клиентскими компьютерами для разрешения имен Интернет-ресурсов. Рекурсивные DNS-серверы кэшируют результаты запросов, которые они делают, чтобы повысить эффективность. На запросы уже сохраненной в кэше информации можно ответить без дополнительных запросов. Продолжительность кеширования результата в секундах: предполагаемый основываться на настраиваемом значении, которое называется «Время жизни» (TTL). Это значение указывается официальным DNS-сервером для запрошенной записи.
На все задаваемые вопросы нет однозначного ответа, потому что DNS - это распределенный протокол. Поведение DNS зависит от конфигурации полномочного DNS-сервера для данной записи, конфигурации рекурсивных DNS-серверов, выполняющих запросы от имени клиентских компьютеров, и функции кэширования DNS, встроенной в операционные системы клиентских компьютеров.
Рекомендуется указывать значение TTL, достаточно короткое для внесения необходимых повседневных изменений в записи DNS, но достаточно длинное, чтобы добиться "выигрыша" в кэшировании (т.е. не настолько короткого, чтобы срок хранения кеша был слишком быстрым, чтобы обеспечить любое повышение эффективности). Использование сбалансированной стратегии со значениями TTL приводит к «победе» для всех. Это снижает нагрузку и использование полосы пропускания для авторитетных серверов DNS для данного домена, корневых серверов и серверов TLD. Это снижает использование полосы пропускания восходящего потока для оператора рекурсивного DNS-сервера. Это приводит к более быстрым ответам на запросы для клиентских компьютеров.
Поскольку TTL записи DNS установлен на более низкую нагрузку, и использование полосы пропускания на авторитетных DNS-серверах будет увеличиваться, потому что рекурсивные DNS-серверы не смогут кэшировать результат в течение длительного времени. Поскольку TTL записи выше, изменения записей не будут «вступать в силу» быстро, поскольку клиентские компьютеры будут продолжать получать кэшированные результаты, хранящиеся на их рекурсивных DNS-серверах. Установка оптимального TTL сводится к балансированию между использованием и возможностью быстро изменять записи и видеть, как эти изменения отражаются на клиентах.
Стоит отметить, что некоторые интернет-провайдеры злоупотребляют и игнорируют значения TTL, указанные авторитетными DNS-серверами (заменяя их собственным административным переопределением, что является нарушением RFC). С технической точки зрения тут ничего не поделаешь. Если удастся найти операторов злонамеренных DNS-серверов, жалобы к их системным администраторам могут привести к внедрению передовых методов (возможно, что является здравым смыслом для любого сетевого инженера, знакомого с DNS). Этот конкретный тип злоупотреблений не является технической проблемой.
Если все «играют по правилам» меняют записи DNS жестяная банка "вступают в силу" очень быстро. В случае изменения IP-адреса, назначенного, например, записи «A», будет выполняться экспоненциальный откат значения TTL до того момента, когда будет выполнено изменение. TTL может начинаться, например, с 1 дня и уменьшаться до 12 часов в течение 24 часов, затем 6 часов в течение 12 часов, 3 часов в течение 6 часов и т. Д., Вплоть до некоторого подходящего небольшого интервала. Как только TTL был отключен, запись может быть изменена, а TTL восстановлен до желаемого значения для повседневных операций. (Нет необходимости использовать экспоненциальный откат, однако эта стратегия минимизирует время, в течение которого запись будет иметь низкий TTL, и снижает нагрузку на полномочный DNS-сервер.)
После внесения изменений в записи DNS необходимо отслеживать попытки доступа, сделанные в результате использования старой записи DNS. В примере изменения записи «A» для ссылки на новый IP-адрес сервер должен оставаться на старом IP-адресе, чтобы обрабатывать попытки доступа, возникающие в результате того, что клиентские компьютеры все еще используют старую запись «A». Как только попытки доступа на основе старой записи достигли приемлемо низкого уровня, старый IP-адрес можно не использовать. Если запросы, относящиеся к старой записи, не исчезают быстро, возможно, что (как описано выше) рекурсивный DNS-сервер игнорирует авторитетный TTL. Однако знание исходного IP-адреса попытки доступа не дает прямой информации о рекурсивном DNS-сервере, ответственном за предоставление старой записи. Если все IP-адреса ошибочных попыток доступа относятся к одному Интернет-провайдеру, возможно, удастся найти проблемный DNS-сервер и связаться с его оператором.
Лично я видел, как изменения «вступают в силу» немедленно, через несколько часов, а в некоторых случаях с конкретным провайдером с повреждением мозга - через несколько дней. Отказ от TTL и осознание того, как работает этот процесс, увеличит ваши изменения для успеха, но вы никогда не можете быть уверены, что какой-то благонамеренный идиот может делать со своими рекурсивными DNS-серверами.