Запись DNS, которая будет часто меняться?

Это называется Записи Fast Flux DNS. И обычно именно так авторы вредоносных программ скрывают свои серверы инфраструктуры.

Хотя это сработает для вашего плана, это не лучший план. Скорее всего, вам понадобится запасной сервер или более, подключенный к сети и почти все время бездействующий. Только когда у вас возникнут проблемы с основным сервером, вы переключитесь на следующий.

Даже если у вас TTL в 1 минуту, одна запись, скорее всего, будет действительна и дольше:

1. Кеши браузера

   Браузеры обычно кэшируют записи DNS в течение переменного периода времени. Firefox использует 60 секунд, Chrome использует 60 секунд также IE 3.x и более ранние версии кешируются для 24 часа, IE 4.x и выше кэшируются в течение 30 минут.

2. Кеш ОС

   Windows будет обычно не соблюдают TTL. TTL для режима "Не беспокоить" не похож на TTL для пакета IPv4. Это скорее показатель свежести, чем обязательное обновление. В Linux можно настроить nscd, чтобы установить время, которое хочет пользователь, без учета TTL DNS. Например, он может кэшировать записи на неделю.

3. Кеш ISP

   Интернет-провайдеры могут (и некоторые будут) использовать агрессивное кеширование для уменьшения трафика. Они могут не только изменять TTL, но и кэшировать записи и возвращать их клиентам, даже не запрашивая вышестоящие DNS-серверы. Это чаще встречается у мобильных интернет-провайдеров, так как они меняют TTL, чтобы мобильные клиенты не жаловались на задержку трафика.

Балансировщик нагрузки создан для того, чтобы делать именно то, что вы хотите. При наличии балансировщика нагрузки вы можете одновременно подключать 2, 4 или 10 серверов, разделяя нагрузку. Если один из них отключится, это не повлияет на работу сервиса. При изменении записей DNS будет время простоя между моментом выключения сервера и изменением DNS. Это займет более одной минуты, потому что вам нужно определить время простоя, изменить записи и дождаться их распространения.

Так что используйте балансировщик нагрузки. Он создан для того, чтобы делать то, что вы хотите, и вы точно знаете, чего ожидать. Настройка fast flux DNS приведет к смешанным и противоречивым результатам.

DNS и то, как он работает, возможно, сопровождается большим количеством недоразумений, легенд, суеверий и мифов, как и любой другой аспект ИТ.

Даже те из нас, кто знает, что мы, по сути, лжем (или, по крайней мере, сильно упрощаем), когда говорим о «распространении» изменений, по-прежнему склонны использовать этот термин для описания чего-то, что является - одновременно - чрезвычайно простым и понятным ... пока сложно объяснить ... и не имеет ничего общего с распространением как таковой, но все, что связано с кешированием и отрицательным кешированием, которые являются важным компонентом того, как работает система (и, возможно, как она избегает полного коллапса под собственным весом) - по сути, вывернутый наизнанку, противоположный фактическому " распространение "тянуть - не толкать".

Несмотря на все беспокойство по поводу коротких TTL, они, как правило, работают чаще, чем нет, до такой степени, что в ваших интересах просто попробовать их. В $ {day_job}, когда наши сайты переходят со «старой» платформы на «новую», это часто означает, что они переносятся таким образом, что ничто в инфраструктуре не используется совместно. Мой первый шаг в такой миграции - это понижение TTL до 60 секунд достаточно далеко до сокращения, чтобы у старого TTL было несколько кратных самому себе, чтобы исчерпать, что дает мне разумную уверенность в том, что эти переходные RR с короткими TTL будут "распространяться. . " Когда я готов к сокращению, я перенастраиваю старый балансировщик ¹ для закрепления трафика в новой системе - через Интернет - таким образом, балансировщик больше не балансирует несколько внутренних систем, а вместо этого «балансирует» все запросы к единая внешняя система - балансир новой платформы².

Затем я переключаю DNS и смотрю новый балансировщик и старый.

Меня всегда приятно удивляет, насколько быстро происходит переход. Похоже, что противниками почти всегда являются поисковые пауки и сторонние сайты «проверки работоспособности», которые необъяснимым образом цепляются за старые записи.

Но есть один сценарий, который предсказуемо нарушается: когда окна браузера пользователя остаются открытыми, они, как правило, фиксируются на уже обнаруженном адресе, и часто это сохраняется до тех пор, пока все окна браузера не будут закрыты.

Но в приведенном выше описании вы найдете решение проблемы: «балансировщик нагрузки» - а точнее, обратный прокси - может быть системой, на которую указывает ваша открытая запись DNS.

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

Обратной стороной является то, что вы можете направлять трафик через ненужную дополнительную инфраструктуру или переплачивать за транспортировку через несколько границ сети с избыточностью.

Существуют сервисы, которые предоставляют такие возможности в глобальном масштабе, и мне больше всего знакома CloudFront. (Скорее всего, Cloudflare будет служить точно той же цели, поскольку небольшое сомнение в тестировании, которое я провел, указывает на то, что он также ведет себя правильно, и я уверен, что есть и другие.)

Хотя CloudFront в основном продается как CDN, он по своей сути представляет собой глобальную сеть обратных прокси-серверов с возможностью необязательно кеширование ответов. Если www.example.com указывает на CloudFront, а CloudFront настроен на пересылку этих запросов на backend.example.com, и запись DNS для backend.example.com использует короткий TTL, тогда CloudFront поступит правильно, потому что соблюдает этот короткий TTL. Когда внутренняя запись изменяется, весь трафик будет мигрировать к моменту истечения TTL.

TTL на внешней записи, указывающей на CloudFront, и то, соблюдают ли браузеры и распознаватели кеширования, это неважно, потому что изменения внутреннего назначения не требуют изменений в www.example.com запись ... так что понятие "Интернет" в отношении правильной цели для www.example.com согласован, независимо от того, где находится серверная система.

На мой взгляд, это полностью решает проблему, избавляя браузер от необходимости «следить» за изменениями IP-адреса исходного сервера.

tl; dr: направлять запросы в систему, которая служит прокси-сервером для реального веб-сервера, так что только конфигурация прокси-сервера должна учитывать изменение IP-адреса исходного сервера, а не DNS, доступный браузеру.

Обратите внимание, что CloudFront также минимизирует задержку с помощью некоторой магии DNS, которую он накладывает на лицевую сторону, что приводит к www.example.com определение наиболее оптимального пограничного местоположения CloudFront в зависимости от местоположения запрашивающего браузера www.example.com, поэтому вероятность того, что трафик будет идти по излишне обходным путем от браузера до края к источнику, минимальна ... но эта часть является прозрачной и автоматической и выходит за рамки вопроса.

И, конечно же, кэширование контента также может иметь значение, поскольку снижает нагрузку на исходный сервер или транспорт - я настроил веб-сайты на CloudFront, где исходный сервер находился в цепи ADSL, а ADSL по своей природе ограничен пропускной способностью восходящего потока. Исходный сервер, к которому CloudFront подключается для получения контента, не обязательно должен быть сервером внутри экосистемы AWS.

¹ Я говорю о балансировщике как о едином объекте, хотя на самом деле он имеет несколько узлов. Когда балансировщиком является ELB, машина за балансировщиком действует как фиктивный сервер приложений и выполняет фактическую привязку к балансировщику новой платформы, поскольку ELB не может сделать это самостоятельно.

² Единственное, что известно новому балансировщику о старом, это то, что ему необходимо доверять X-Forwarded-For старого балансировщика и что он не должен ограничивать скорость на основе IP для исходных адресов старого балансировщика.

³ Когда прокси - это один или несколько серверов, которыми вы управляете, у вас есть возможность пропустить использование DNS на задней стороне и просто использовать IP-адреса в конфигурации прокси, но обсуждаемый далее сценарий размещения / распределения требует этого второго уровня DNS. .

Когда я меняю записи DNS, старый IP-адрес часто используется месяцами. При этом TTL всего в несколько секунд - это то, что Amazon использует, например, для создания резервной службы.

Вместо того, чтобы менять DNS, вы можете поставить перед ним прокси-сервер / балансировщик нагрузки.

Вы можете изучить использование динамического DNS. Это предназначено именно для сценария, который @glglgl упомянул в комментарии выше. Я считаю, что они используют низкий TTL, который, как указывалось ранее, может не быть на 100% эффективным, поскольку клиенты могут его игнорировать. Но работает «неплохо».

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