Comments 42
Если с вашим сервером может произойти жопа, то почему бы его не зарезервировать и поставить перед ним балансировщик нагрузки? Если с вашим балансировщиком может произойти жопа, то почему бы не зарезервировать балансировщики, каждый со своей DNS-записью?
Потому что денег на это нет, а на белкового админа, которые будет перетыкивать руками в три часа ночи — есть :(
А от того что хобби проект полежит час, что произойдёт?
Если вам по какой-то причине надо срочно обновить А запись то ждать вам придется как раз весь TTL. И хорошо если у вас есть полный контроль над роутингом у себя и "плавающие" IP-адреса, а если это vps?
Чаще всего, почему-то, проблема была заметна на доменах каких-то российских рекламных сетей (сейчас уже не вспомню кто это был). Я посчитал, что они собирают статистику на своих DNS-серверах.
Автор статьи упорно не хочет замечать проблему, которую он обозначил вскользь и не хочет предложить какой-то способ для её решения.
Современный бизнес не готов терпеть сутки убытка, пока сайт переключится если он неожиданно упадёт и его придётся подымать на другом месте. Поэтому сейчас все такие умные и стали ставить значения как можно меньше — вот и все дела. И это самый дешёвый способ способ снизить время переключения, поэтому неважно, что у вас в ближайших планах на полгода нет повода для смены хостинга: просто тупо держите TTL поменьше на всякий пожарный случай.
Все другие способы сделать более качественно страдают одним мааааленьким недостатком: они намного более дороги. Все ли готовы вкладываться в это? Не все. А требовать хотят все.
Вот отсюда и описанная ситуация.
В айти всего две действительно сложные проблемы: нейминг и инвалидация кеша. В протоколе DNS инвалидация кеша есть? Ну вот потому ситуация и не меняется.
С хостингом в облаках как раз всё намного хуже.
Я до сих пор помню чудесное от digitalocean — «ну у нас кнопки reinstall пока нет, вы дроплет удалите, создайте заново с теми же параметрами, может быть повезет и он будет с тем же адресом» (кнопки reinstall на тот момент действительно не было).
А сейчас минималка в 2 минуты на непроксируемых, и 5 минут — на proxied ресурсах
Я недавно менял ip сайта в CF, так после смены он мгновенно стал доступен. Подозреваю, что там TTL для недоступных сайтов снижается, чтобы при возобновлении работы сразу отдать его клиентам.
Загрузка одной страницы типичного сайта генерирует более 1 Мб трафика. Если ради нее приходится делать DNS-запрос, то это + 300 байт трафика — менее 0,1%.
Статья предлагает вам тратить время ради оптимизации менее 0,1% трафика. И получить проблемы при падениях, ДДОС-атаках, проблемах с хостером.
Не уж, пусть будет 5-15 минут, и вам не придется объяснять владельцу бизнеса, что поднять сайт нельзя, так как какой-то гений, начитавшись советов в Интернете, поставил TTL в 12 часов.
И генерируя 5 днс запросов (cname, cdn, ресурсы партнеров, счетчики) с задержкой в 200мс вы легко получаете более 1 секунды до загрузки страницы каждые { ваше/cdn/партнеров значение ttl }.
DNS-ресолвинг — для клиента это в первую задержка перед отображением страницы, а не объём трафика
поднять сайт нельзя, так как какой-то гений, начитавшись советов в Интернете, поставил TTL в 12 часов.
Я вполне себе застал времена в начале 2000-х, когда TTL обычно стоял 86400. И были постоянные факапы, когда люди пуляли ошибочное обновление в зону, которое роняло корпоративную почту или сайт на сутки.
Работал в то время в телекоме и сполна насмотрелся на эти ужасы.
Пусть уж лучше TTL в 60-120 секунд.
Вторая: в общем случае, у вас нету надёжного способа управления трафиком, кроме GeoDNS. Предупреждая вопросы, anycast — это не управление, т.к. решение в итоге принимает провайдер на основе ваших предложений, но далеко не всегда в соответствии с вашими желаниями.
Из этих двух вводных и возникает низкий TTL в большинстве CDN (включая AWS, Google Cloud и т.д.).
Про проблемы быстрого переключения на другой пул адресов/балансеров/etc уже писали выше, это уже касается не-CDN доменов.
И уж тем более это добро несопоставимо с часами простоя, в случае протухшей DNS записи.
Петь песни про резервирование, кэширование и управление траффиком все горазды, а вот когда припрет — каждому клиенту на дом «сделайте, пожалуйста ipconfig /flushdns» носить не будешь.
Кэширование DNS штука, конечно, клевая, но фарш обратно не провернешь: если закэшировало — то все, жди пока протухнет.
Сейчас кэш DNS просто ушел в прошлое имхо. Для ускорения загрузки нынче куда более эффективнее кэширование на уровне CDN с проверками по 304 коду или чем-нибудь подобным.
В конце концов пропускная способность сети и скорости загрузки контента для конечного пользователя постоянно растут и влияние задержек от DNS запросов будет становится все менее и менее заметным.
а еще бывает, не оплатит бухгалтерия вовремя домен, и один крупный провайдер с названием в названии быстренько подставляет ip адреса со своей рекламой, которые кэшируются у клиентов и некоторые потом сутками жалуются на недоступность сервиса.
Когда мои коллеги-программисты где-то вкорячивают кеширование но забывают приделать к нему инвалидацию — я отрываю им руки.
Создателям DNS руки вовремя никто не оторвал, а про инвалидацию кеша они вообще были не в курсе.
Запонимать всех кто (и когда) спрашивал и слать «сбросить кэш»? При этом, без криптографии тут не обойдётся — все запросы на сброс кэша должны быть подписаны, а резолверы должны их валидировать, и это не считая того что эту «память» нужно хранить где-то постоянно — иначе холодный рестарт сервера (или переход на другой сервер в пуле) не сбросит кэш.
Технически это конечно реализуемо, но усложняет систему неимоверно, а если учесть что клиенты иногда запрашивают кэширующие резолверы совсем не первого уровня, да и самих резолверов могут быть не тысячи а десятки тысяч, то всё становится очень мрачно.
1) Маленькие TTL на популярных доменах не вредят телеком-провайдерам с большим количеством Абонентов. При условии того, что эти телеком-провайдеры агрегируют трафик 400+ тысяч Абонентов на сервер. Давление на кеш на таком сервере позволяет держать все популярные домены в кеше. Сервер может отвечать на запросы к популярным доменам 100% из кеша, если используются проактивное кеширование.
У телеком-провайдеров с небольшой нагрузкой на кешируюшие DNS сервера популярные домены часто вымываются из кеша, вследствии небольшого на него давления от клиентов. И проактивное кеширование при небольшом давлении на кеш уже не помогает.
2) В среднем TTL все время снижается, так как все больше ресурсов переезжает в «облака», в которых короткие TTL используются по умолчанию.
В среднем никогда не стоит делать TTL меньше 15 секунд, иначе и проактивное кеширование на стороне резолвера ISP может не успевать обновлять кеш, до того как запись умрет по TTL.
Хм, а причем здесь серверы? Нельзя ли сделать просто долгосрочный кеш на стороне клиента? И сбрасывать его если произошла ошибка соединения.
Или я фундаментально не понимаю что нибудь?
Хватит использовать смехотворно малый TTL для DNS