[Системное администрирование, Сетевые технологии, Серверное администрирование] Что происходит, когда вы обновляете свой DNS (перевод)
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Fenix by Takeda11
Многие путаются в обновлении записей DNS, когда изменяют IP-адрес своего сайта. Почему эти записи медленно обновляются? Неужели действительно нужно ждать два дня, чтобы всё обновилось? Почему одни посетители видят новый IP, а другие — старый?
Команда Mail.ru Cloud Solutions перевела статью разработчика и автора статей Джулии Эванс, где она отвечает на эти вопросы и популярно рассказывает, что происходит во время обновления DNS с точки зрения фронтендера.
Вот краткое исследование того, что происходит за кулисами, когда вы обновляете запись DNS.
Как работает DNS: рекурсивные и авторитетные DNS-серверы
Во-первых, нам нужно немного объяснить систему DNS. Существует два вида DNS-серверов: авторитетные и рекурсивные.
Авторитетные DNS-серверы (также известные как серверы имен) хранят базу данных IP-адресов для каждого домена, за который они отвечают. Например, прямо сейчас авторитетный DNS-сервер для github.com — это ns-421.awsdns-52.com. Вы можете спросить у него IP-адрес github.com вот таким запросом:
dig @ns-421.awsdns-52.com github.com
Рекурсивные DNS-серверы сами по себе ничего не знают о том, кому принадлежит какой IP-адрес. Они вычисляют IP-адрес для домена, запрашивая его у соответствующих авторитетных DNS-серверов, а затем кэшируют этот IP-адрес на случай, если их снова спросят о нем. Так, 8.8.8.8 — это рекурсивный DNS-сервер.
Когда люди посещают ваш веб-сайт, они, вероятно, делают DNS-запросы к рекурсивному DNS-серверу. Итак, как же работают рекурсивные DNS-серверы? Давайте посмотрим!
Как рекурсивный DNS-сервер запрашивает IP-адрес github.com
Давайте рассмотрим пример того, что делает рекурсивный DNS-сервер (например, 8.8.8.8), когда вы запрашиваете у него IP-адрес (запись А) для github.com. Во-первых, если у него уже есть кэшированный результат, он выдаст его. Но что, если все кэши просрочены? Вот что происходит.
Шаг 1: IP-адреса для корневых DNS-серверов жестко закодированы в его исходном коде. Вы можете увидеть это в исходном коде unbound. Допустим, для начала он выберет 198.41.0.4. Вот официальный источник этих жестко закодированных IP-адресов, также известный как «корневой файл подсказок» (root hints file).
Шаг 2: Спросить корневые серверы имен о github.com.
Мы можем приблизительно воспроизвести то, что происходит, с помощью команды dig. Она выдает нам новый авторитетный сервер имен для запроса: сервер имен для .com с IP-адресом 192.5.6.30.
$ dig @198.41.0.4 github.com
...
com. 172800 IN NS a.gtld-servers.net.
...
a.gtld-servers.net. 172800 IN A 192.5.6.30
...
Детали ответа DNS немного сложнее — в этом случае есть раздел авторитетности (authority section) с некоторыми записями NS и дополнительный раздел с записями A, так что вам не нужно делать дополнительный поиск, чтобы получить IP-адреса этих серверов имен.
На практике в 99,99% случаев там уже будет кэшированный адрес серверов имен .com, но мы делаем вид, что действительно начинаем с нуля.
Шаг 3: Спросить серверы имен .com о github.com.
$ dig @192.5.6.30 github.com
...
github.com. 172800 IN NS ns-421.awsdns-52.com.
ns-421.awsdns-52.com. 172800 IN A 205.251.193.165
...
У нас есть новый IP-адрес для отправки запроса! Это один из серверов имен для github.com.
Шаг 4: Спросить у серверов имен github.com об адресе github.com.
Мы почти закончили!
$ dig @205.251.193.165 github.com
github.com. 60 IN A 140.82.112.4
Итак, у нас есть запись А для github.com. Теперь у рекурсивного сервера есть IP-адрес github.com, и он может вернуть его вам. И он смог провернуть всю процедуру, начиная всего с нескольких жестко закодированных IP-адресов: адресов корневых серверов имен.
Как увидеть все шаги рекурсивного DNS-сервера: dig +trace
Чтобы посмотреть, что рекурсивный DNS-сервер будет делать для резолвинга домена, можно запустить:
$ dig @8.8.8.8 +trace github.com
Эта команда показывает все DNS-записи, которые запрашивает рекурсивный сервер, начиная с корневых DNS-серверов, то есть все четыре шага, которые мы только что прошли.
Обновим записи DNS
Теперь, когда мы знаем основы работы DNS, давайте обновим некоторые записи DNS и посмотрим, что произойдет.
При обновлении записей DNS существует два основных варианта:
- сохранить те же серверы имен;
- изменить серверы имен.
Поговорим о TTL
Но мы забыли кое-что важное. Это пакеты TTL. Как мы сказали ранее, рекурсивный DNS-сервер будет кэшировать записи до истечения срока их действия. Он принимает решение об истечении срока действия записи в зависимости от ее TTL (time to live, времени жизни).
В этом примере сервер имен GitHub для его DNS-записи возвращает TTL 60, что означает 60 секунд:
$ dig @205.251.193.165 github.com
github.com. 60 IN A 140.82.112.4
Это довольно короткий TTL. Теоретически, если бы все DNS-реализации следовали стандарту DNS, это означало бы, что если GitHub решил изменить IP-адрес для github.com, каждый получил бы новый IP-адрес в течение 60 секунд. Давайте посмотрим, как это происходит на практике.
Вариант 1: обновление записи DNS на тех же серверах имен
Во-первых, я обновила свои серверы имен (Cloudflare), чтобы получить новую запись DNS — запись A, которая сопоставляет test.jvns.ca на 1.2.3.4:
$ dig @8.8.8.8 test.jvns.ca
test.jvns.ca. 299 IN A 1.2.3.4
Это сработало немедленно! Не было никакой необходимости ждать вообще, потому что перед этим не было никакой DNS-записи test.jvns.ca, которая могла быть кэширована. Отлично. Но похоже, что новая запись кэшируется в течение примерно пяти минут (299 секунд).
Итак, а если мы попытаемся изменить этот IP-адрес? Я изменила его на 5.6.7.8, а затем запустила тот же DNS-запрос:
$ dig @8.8.8.8 test.jvns.ca
test.jvns.ca. 144 IN A 1.2.3.4
Похоже, что на этом 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-адрес. Отлично. Но что произойдет, если вы измените свои серверы имен? Давайте попробуем!
Я не хотела обновлять серверы имен для своего блога, поэтому вместо этого взяла другой свой домен и использовала его в примерах для журнала по HTTP это examplecat.com.
Раньше мои серверы были установлены на dns1.p01.nsone.net. Я решила изменить их на серверы Google с адресами ns-cloud-b1.googledomains.com и так далее.
Когда я внесла изменения, мой доменный регистратор несколько зловеще высветил сообщение: «Изменения в examplecat.com сохранены. Они вступят в силу в течение ближайших 48 часов». Затем я установила новую запись A для домена, чтобы она указывала на 1.2.3.4.
Ладно, давайте посмотрим, изменилось ли что-нибудь:
$ dig @8.8.8.8 examplecat.com
examplecat.com. 17 IN A 104.248.50.87
Никаких изменений. Если я спрошу другой DNS-сервер, то он знает новый IP:
$ dig @1.1.1.1 examplecat.com
examplecat.com. 299 IN A 1.2.3.4
Но 8.8.8.8 по-прежнему ничего не знает. Причина, по которой 1.1.1.1 видит новый IP, хотя я только что изменила его пять минут назад, вероятно, заключается в том, что никто никогда не спрашивал 1.1.1.1 об этом examplecat.com раньше — значит, у него в кэше ничего не было.
У серверов имен TTL намного больше
Причина, по которой мой регистратор говорил: «Это займёт 48 часов» в том, что TTL на NS-записях (сведения о том, к какому серверу имен должен обратиться рекурсивный сервер) намного больше.
Новый сервер имен определенно возвращает новый IP-адрес для examplecat.com:
$ dig @ns-cloud-b1.googledomains.com examplecat.com
examplecat.com. 300 IN A 1.2.3.4
Но вспомните, что произошло, когда мы запросили серверы имен github.com раньше:
$ dig @192.5.6.30 github.com
...
github.com. 172800 IN NS ns-421.awsdns-52.com.
ns-421.awsdns-52.com. 172800 IN A 205.251.193.165
...
172 800 секунд — это 48 часов! Таким образом, обновление сервера имен, как правило, занимает гораздо больше времени. Время нужно, чтобы закончился срок действия кэшей и распространился новый адрес. Это гораздо дольше, чем просто обновление IP-адреса без изменения вашего сервера имен.
Как обновляются ваши серверы имен
Когда я обновляю серверы имен для examplecat.com, сервер имен .com получает новую запись NS с новым доменом. Подобно этому:
dig ns @j.gtld-servers.net examplecat.com
examplecat.com. 172800 IN NS ns-cloud-b1.googledomains.com
Но как туда попадает эта новая запись NS? Фактически, я говорю своему регистратору доменов, какими хочу видеть новые серверы имен, обновляя их на веб-сайте, а затем мой регистратор доменов говорит серверам имен .com сделать обновление.
Для .com эти обновления происходят довольно быстро (в течение нескольких минут), но я думаю, что для некоторых других зон TLD серверы имен могут применять обновления не так быстро.
Библиотека 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 в течение дня или двух.
После публикации этой статьи я изменила серверы имен для examplecat.com обратно к старым значениям.
Что еще почитать:
- Go и кеши CPU.
- Какую базу данных выбрать для проекта, чтобы не пришлось выбирать снова.
- Наш канал в Телеграме о цифровой трансформации.
===========
Источник:
habr.com
===========
===========
Автор оригинала: Julia Evans
===========Похожие новости:
- [Системное администрирование, Серверное администрирование, DevOps, Kubernetes] Представляем Contour: направляем трафик к приложениям в Kubernetes (перевод)
- [IT-инфраструктура, Серверное администрирование, Облачные сервисы, IT-компании] Боли стартапов: как правильно развивать ИТ-инфраструктуру
- [Программирование, Отладка, C] Почему язык С не помешает вам делать ошибки (перевод)
- [Настройка Linux, Open source, Системное администрирование, Учебный процесс в IT] Сборник полезных ссылок для системного администратора
- [Системное администрирование, IT-инфраструктура, Nginx, DevOps] Как случайно продолжить писать Web-GUI для Haproxy
- [Научно-популярное, Искусственный интеллект] Сонм разумов: актуальные барьеры и трамплины на пути создания общего ИИ
- [Информационная безопасность, Сетевые технологии, Сетевое оборудование] Как траблшутить отечественный IPsec VPN. Часть 1
- [Сетевые технологии, Беспроводные технологии, Стандарты связи] Появились первые предварительные спецификации Wi-Fi 7
- [Системное администрирование, DevOps, Kubernetes] Полноценный Kubernetes с нуля на Raspberry Pi
- [Сетевые технологии, IPv6, Исследования и прогнозы в IT] Наш первый обзор отключения Интернета в Беларуси (перевод)
Теги для поиска: #_sistemnoe_administrirovanie (Системное администрирование), #_setevye_tehnologii (Сетевые технологии), #_servernoe_administrirovanie (Серверное администрирование), #_mail.ru_cloud_solutions, #_ttl, #_dnsserver (dns-сервер), #_obnovlenie_dns (обновление dns), #_ipadres (ip-адрес), #_blog_kompanii_mail.ru_group (
Блог компании Mail.ru Group
), #_sistemnoe_administrirovanie (
Системное администрирование
), #_setevye_tehnologii (
Сетевые технологии
), #_servernoe_administrirovanie (
Серверное администрирование
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 25-Ноя 21:00
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 Fenix by Takeda11 Многие путаются в обновлении записей DNS, когда изменяют IP-адрес своего сайта. Почему эти записи медленно обновляются? Неужели действительно нужно ждать два дня, чтобы всё обновилось? Почему одни посетители видят новый IP, а другие — старый? Команда Mail.ru Cloud Solutions перевела статью разработчика и автора статей Джулии Эванс, где она отвечает на эти вопросы и популярно рассказывает, что происходит во время обновления DNS с точки зрения фронтендера. Вот краткое исследование того, что происходит за кулисами, когда вы обновляете запись DNS. Как работает DNS: рекурсивные и авторитетные DNS-серверы Во-первых, нам нужно немного объяснить систему DNS. Существует два вида DNS-серверов: авторитетные и рекурсивные. Авторитетные DNS-серверы (также известные как серверы имен) хранят базу данных IP-адресов для каждого домена, за который они отвечают. Например, прямо сейчас авторитетный DNS-сервер для github.com — это ns-421.awsdns-52.com. Вы можете спросить у него IP-адрес github.com вот таким запросом: dig @ns-421.awsdns-52.com github.com
Рекурсивные DNS-серверы сами по себе ничего не знают о том, кому принадлежит какой IP-адрес. Они вычисляют IP-адрес для домена, запрашивая его у соответствующих авторитетных DNS-серверов, а затем кэшируют этот IP-адрес на случай, если их снова спросят о нем. Так, 8.8.8.8 — это рекурсивный DNS-сервер. Когда люди посещают ваш веб-сайт, они, вероятно, делают DNS-запросы к рекурсивному DNS-серверу. Итак, как же работают рекурсивные DNS-серверы? Давайте посмотрим! Как рекурсивный DNS-сервер запрашивает IP-адрес github.com Давайте рассмотрим пример того, что делает рекурсивный DNS-сервер (например, 8.8.8.8), когда вы запрашиваете у него IP-адрес (запись А) для github.com. Во-первых, если у него уже есть кэшированный результат, он выдаст его. Но что, если все кэши просрочены? Вот что происходит. Шаг 1: IP-адреса для корневых DNS-серверов жестко закодированы в его исходном коде. Вы можете увидеть это в исходном коде unbound. Допустим, для начала он выберет 198.41.0.4. Вот официальный источник этих жестко закодированных IP-адресов, также известный как «корневой файл подсказок» (root hints file). Шаг 2: Спросить корневые серверы имен о github.com. Мы можем приблизительно воспроизвести то, что происходит, с помощью команды dig. Она выдает нам новый авторитетный сервер имен для запроса: сервер имен для .com с IP-адресом 192.5.6.30. $ dig @198.41.0.4 github.com
... com. 172800 IN NS a.gtld-servers.net. ... a.gtld-servers.net. 172800 IN A 192.5.6.30 ... Детали ответа DNS немного сложнее — в этом случае есть раздел авторитетности (authority section) с некоторыми записями NS и дополнительный раздел с записями A, так что вам не нужно делать дополнительный поиск, чтобы получить IP-адреса этих серверов имен. На практике в 99,99% случаев там уже будет кэшированный адрес серверов имен .com, но мы делаем вид, что действительно начинаем с нуля. Шаг 3: Спросить серверы имен .com о github.com. $ dig @192.5.6.30 github.com
... github.com. 172800 IN NS ns-421.awsdns-52.com. ns-421.awsdns-52.com. 172800 IN A 205.251.193.165 ... У нас есть новый IP-адрес для отправки запроса! Это один из серверов имен для github.com. Шаг 4: Спросить у серверов имен github.com об адресе github.com. Мы почти закончили! $ dig @205.251.193.165 github.com
github.com. 60 IN A 140.82.112.4 Итак, у нас есть запись А для github.com. Теперь у рекурсивного сервера есть IP-адрес github.com, и он может вернуть его вам. И он смог провернуть всю процедуру, начиная всего с нескольких жестко закодированных IP-адресов: адресов корневых серверов имен. Как увидеть все шаги рекурсивного DNS-сервера: dig +trace Чтобы посмотреть, что рекурсивный DNS-сервер будет делать для резолвинга домена, можно запустить: $ dig @8.8.8.8 +trace github.com
Эта команда показывает все DNS-записи, которые запрашивает рекурсивный сервер, начиная с корневых DNS-серверов, то есть все четыре шага, которые мы только что прошли. Обновим записи DNS Теперь, когда мы знаем основы работы DNS, давайте обновим некоторые записи DNS и посмотрим, что произойдет. При обновлении записей DNS существует два основных варианта:
Поговорим о TTL Но мы забыли кое-что важное. Это пакеты TTL. Как мы сказали ранее, рекурсивный DNS-сервер будет кэшировать записи до истечения срока их действия. Он принимает решение об истечении срока действия записи в зависимости от ее TTL (time to live, времени жизни). В этом примере сервер имен GitHub для его DNS-записи возвращает TTL 60, что означает 60 секунд: $ dig @205.251.193.165 github.com
github.com. 60 IN A 140.82.112.4 Это довольно короткий TTL. Теоретически, если бы все DNS-реализации следовали стандарту DNS, это означало бы, что если GitHub решил изменить IP-адрес для github.com, каждый получил бы новый IP-адрес в течение 60 секунд. Давайте посмотрим, как это происходит на практике. Вариант 1: обновление записи DNS на тех же серверах имен Во-первых, я обновила свои серверы имен (Cloudflare), чтобы получить новую запись DNS — запись A, которая сопоставляет test.jvns.ca на 1.2.3.4: $ dig @8.8.8.8 test.jvns.ca
test.jvns.ca. 299 IN A 1.2.3.4 Это сработало немедленно! Не было никакой необходимости ждать вообще, потому что перед этим не было никакой DNS-записи test.jvns.ca, которая могла быть кэширована. Отлично. Но похоже, что новая запись кэшируется в течение примерно пяти минут (299 секунд). Итак, а если мы попытаемся изменить этот IP-адрес? Я изменила его на 5.6.7.8, а затем запустила тот же DNS-запрос: $ dig @8.8.8.8 test.jvns.ca
test.jvns.ca. 144 IN A 1.2.3.4 Похоже, что на этом 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-адрес. Отлично. Но что произойдет, если вы измените свои серверы имен? Давайте попробуем! Я не хотела обновлять серверы имен для своего блога, поэтому вместо этого взяла другой свой домен и использовала его в примерах для журнала по HTTP это examplecat.com. Раньше мои серверы были установлены на dns1.p01.nsone.net. Я решила изменить их на серверы Google с адресами ns-cloud-b1.googledomains.com и так далее. Когда я внесла изменения, мой доменный регистратор несколько зловеще высветил сообщение: «Изменения в examplecat.com сохранены. Они вступят в силу в течение ближайших 48 часов». Затем я установила новую запись A для домена, чтобы она указывала на 1.2.3.4. Ладно, давайте посмотрим, изменилось ли что-нибудь: $ dig @8.8.8.8 examplecat.com
examplecat.com. 17 IN A 104.248.50.87 Никаких изменений. Если я спрошу другой DNS-сервер, то он знает новый IP: $ dig @1.1.1.1 examplecat.com
examplecat.com. 299 IN A 1.2.3.4 Но 8.8.8.8 по-прежнему ничего не знает. Причина, по которой 1.1.1.1 видит новый IP, хотя я только что изменила его пять минут назад, вероятно, заключается в том, что никто никогда не спрашивал 1.1.1.1 об этом examplecat.com раньше — значит, у него в кэше ничего не было. У серверов имен TTL намного больше Причина, по которой мой регистратор говорил: «Это займёт 48 часов» в том, что TTL на NS-записях (сведения о том, к какому серверу имен должен обратиться рекурсивный сервер) намного больше. Новый сервер имен определенно возвращает новый IP-адрес для examplecat.com: $ dig @ns-cloud-b1.googledomains.com examplecat.com
examplecat.com. 300 IN A 1.2.3.4 Но вспомните, что произошло, когда мы запросили серверы имен github.com раньше: $ dig @192.5.6.30 github.com
... github.com. 172800 IN NS ns-421.awsdns-52.com. ns-421.awsdns-52.com. 172800 IN A 205.251.193.165 ... 172 800 секунд — это 48 часов! Таким образом, обновление сервера имен, как правило, занимает гораздо больше времени. Время нужно, чтобы закончился срок действия кэшей и распространился новый адрес. Это гораздо дольше, чем просто обновление IP-адреса без изменения вашего сервера имен. Как обновляются ваши серверы имен Когда я обновляю серверы имен для examplecat.com, сервер имен .com получает новую запись NS с новым доменом. Подобно этому: dig ns @j.gtld-servers.net examplecat.com
examplecat.com. 172800 IN NS ns-cloud-b1.googledomains.com Но как туда попадает эта новая запись NS? Фактически, я говорю своему регистратору доменов, какими хочу видеть новые серверы имен, обновляя их на веб-сайте, а затем мой регистратор доменов говорит серверам имен .com сделать обновление. Для .com эти обновления происходят довольно быстро (в течение нескольких минут), но я думаю, что для некоторых других зон TLD серверы имен могут применять обновления не так быстро. Библиотека 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 в течение дня или двух. После публикации этой статьи я изменила серверы имен для examplecat.com обратно к старым значениям. Что еще почитать:
=========== Источник: habr.com =========== =========== Автор оригинала: Julia Evans ===========Похожие новости:
Блог компании Mail.ru Group ), #_sistemnoe_administrirovanie ( Системное администрирование ), #_setevye_tehnologii ( Сетевые технологии ), #_servernoe_administrirovanie ( Серверное администрирование ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 25-Ноя 21:00
Часовой пояс: UTC + 5