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 в конечном итоге принимает этот метод в качестве стандарта, который также может быть принят операторами либо в его текущей черновой версии, либо в финал.

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