Google и OpenDNS представляют улучшение протокола DNS

Google и OpenDNS, две из самых популярных общедоступных служб разрешения имен в Интернете, предложили и реализовали Расширение протокола DNS что позволит улучшить скорость навигация при использовании ресурсов из сети распространения контента.


У крупных компаний по распространению контента есть серверы, разбросанные по всему миру в системах, называемых Content Delivery Network (CDN). Хорошим примером этого является, например, Akamai, который служит файловым хранилищем для сторонних компаний.

Если мы предположим, что у CDN есть эксклюзивный сервер для обслуживания страны с реплицированным всем доступным контентом, полученное большое преимущество по сравнению с централизованным размещением всего в одном месте состоит в том, что теоретически время доступа к контенту сведено к минимуму. (задержка), поскольку, например, пользователь в Севилье вместо того, чтобы связываться с центральным офисом в Соединенных Штатах, будет делать это с сервером, который у него есть в Испании.

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

Однако это уже не идеально, когда появляется все больше и больше пользователей сети, которые не используют DNS, предоставляемые их оператором, и настраивают на своем компьютере общедоступные, такие как Google или OpenDNS, Назовите два примера, фигурирующих в статье.

  1. Мы пишем веб-страницу loquesea.eu в строке браузера.
  2. Компьютер, который не знает, какой IP-адрес соответствует имени, запрашивает перевод у DNS-сервера (1), который он настроил (операторского или другого).
  3. Если предположить, что кеш этого сервера пуст, вам придется обратиться за помощью к так называемым корневым серверам, которые сообщат вам, какой из серверов отвечает за все адресное пространство.
  4. Затем операция повторяется. В этом случае настроенный нами DNS-сервер будет опрашивать (3) того, кто отвечает за все имена .eu о сервере, который имеет имя loquesea.eu и его поддомены под своим контролем (например, linebenchmark.loquesea.eu ).
  5. Наконец, последний DNS-запрос делается на этот последний сервер, который вернет IP-адрес loquesea.eu (4) и будет передан компьютеру, который отправил запрос в первом экземпляре (5), чтобы, наконец, открыть сеанс HTTP и загрузить сайт (6).

Как видите, это довольно сложный процесс, хотя в глазах пользователя сети он происходит прозрачно.

Повышение производительности DNS при доступе к CDN

Проблема систем DNS для традиционных сетей CDN, о которой мы упоминали, заключается в следующем: поскольку согласование DNS для получения IP-адреса желаемого пункта назначения выполняется промежуточным сервером, сети CDN обнаруживают серверы Google DNS как источник запроса, которые находятся в состояниях. United. Учитывая это, CDN отвечает IP-адресами своих серверов для США, а не для Испании. Мы теряем производительность из-за увеличения задержки.

Чтобы решить эту проблему, была разработана модификация протокола DNS, использующая преимущества расширений, предложенных в RFC 2671 чтобы сделать разрешение имен более интеллектуальным.

Идея, которая называется Глобальное ускорение Интернета и это все еще в черновая фаза, он помогает в исходном адресе клиента, который он добавляет в запрос как еще одно поле данных ("edns-client-subnet").

Хотя на самом деле, чтобы сохранить конфиденциальность пользователя, то, что отправляется, является частью общедоступного IP-адреса пользователя (биты удаляются с конца), поэтому вместо отправки 1.2.3.4 (если это был общедоступный IP-адрес пользователя) , усекается до версии 1.2.3.0 (все промежуточные DNS-серверы смогут читать эту информацию) и сопровождается 24-битной сетевой маской.

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

Для тех, кто более подозрительно относится к своей конфиденциальности, можно настроить так, чтобы не отправлялась никакая часть IP-адреса пользователя (отправляется 0.0.0.0/0). В этих случаях мы понимаем, что сервис будет работать как традиционный DNS в CDN. То есть, не имея представления о своем реальном происхождении, CDN ответит IP-адресом, ближайшим к DNS-серверу, выполняющему запрос.

На данный момент и Google, и OpenDNS уже установили эту новую функцию в своих системах, которую они разработали вместе с CDNetworks, EdgeCast, BitGravity и самим Akamai, что помогло в написании проекта.

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

источник: широкополосный


Содержание статьи соответствует нашим принципам редакционная этика. Чтобы сообщить об ошибке, нажмите здесь.

Комментарий, оставьте свой

Оставьте свой комментарий

Ваш электронный адрес не будет опубликован. Обязательные для заполнения поля помечены *

*

*

  1. Ответственный за данные: Мигель Анхель Гатон
  2. Назначение данных: контроль спама, управление комментариями.
  3. Легитимация: ваше согласие
  4. Передача данных: данные не будут переданы третьим лицам, кроме как по закону.
  5. Хранение данных: база данных, размещенная в Occentus Networks (ЕС)
  6. Права: в любое время вы можете ограничить, восстановить и удалить свою информацию.

  1.   труко сказал

    И как установить клиент, обновляющий IP-адрес в linux uu