Сколько времени занимает распространение DNS-записей?

Это канонический вопрос о распространении DNS

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

«Распространение DNS» само по себе не является реальным явлением. Скорее, это явный эффект от функции кэширования, указанной в протоколе DNS. Сказать, что изменения «распространяются» между DNS-серверами, - это удобная ложь, которую, вероятно, легче объяснить нетехническим пользователям, чем описывать все детали протокола DNS. Это не совсем то, как работает протокол.

Рекурсивные DNS-серверы делают запросы от имени клиентов. Рекурсивные DNS-серверы, обычно используемые интернет-провайдерами или ИТ-отделами, используются клиентскими компьютерами для разрешения имен интернет-ресурсов. Рекурсивные DNS-серверы кэшируют результаты запросов, которые они делают для повышения эффективности. На запросы уже кэшированной информации можно ответить без каких-либо дополнительных запросов. Продолжительность в секундах, что результат кэшируются будет должен быть на основе настраиваемого значения называется Time To Live (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-сервере, отвечающем за предоставление старой записи.

Лично я видел, что изменения «вступают в силу» сразу, через несколько часов, а в некоторых случаях с конкретным провайдером, поврежденным мозгом, через несколько дней. Отказ от своего TTL и помнить о том, как этот процесс работает, увеличит ваши изменения для успеха, но вы никогда не сможете быть уверенными в том, что может делать какой-то благий идиот со своими рекурсивными DNS-серверами.