Как работает DNS-кеширование на веб-сайтах, находящихся за CDN?

Компания, использующая CDN, установит дублирующие серверы по всему миру. Эти серверы известны всем серверам CDN.

Один и тот же IP-адрес, который вы упомянули, указывает на один DNS-сервер, который является частью CDN.

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

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

Чтобы избежать проблем и перегрузок, ответ DNS будет иметь небольшой срок жизни (TTL), поэтому процесс может время от времени повторяться и, возможно, в следующий раз вернет другой сервер.

Когда дело доходит до Cloudflare, который одновременно является CDN и авторитетным DNS-сервером, как службы кэширования DNS, такие как встроенные в Windows или другое программное обеспечение сервера кэширования, узнают, какой IP-адрес принадлежит какому домену?

Им не обязательно это знать. Все кэши DNS, как и сам DNS, сопоставляют доменные имена только со значениями (записями «A»), а не наоборот.

Если, например, программное обеспечение для кэширования DNS помнит, что 1.2.3.4 указывает на facebook.com, а также что IP-адрес предназначен для google.com, bing.com и т. д., кеш бесполезен, так что же я упускаю?

Нет, это совсем не то, что запоминает программное обеспечение для кэширования DNS. Он делает обратное — и DNS-кеш, и DNS-система в целом заботятся лишь о том, чтобыgoogle.comуказывает на1.2.3.4, а не то, что адрес «указывает» назад.

Записи в кэше DNS выглядят точно так же, как записи на авторитетных DNS-серверах, с именем домена в качестве ключа поиска. (На самом деле, за пределами Windows, большинство кэшей DNS представляют собой обычные DNS-серверы, которые принимают стандартные запросы и отвечают на них.)

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

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

Да, в целом, однако, когда вы используете CDN, такой как Cloudflare, конечным результатом этого DNS-запроса больше не является исходный сервер — это сервер CDN.

В частности, в Cloudflare таблица записей DNS, которую вы видите в «панели управления» Cloudflare, на самом деле не является записями DNS, которые Cloudflare предоставляет пользователям. Как только вы включите проксирование для доменного имени, авторитетные DNS-серверы Cloudflare начнут отвечать, используя собственные IP-адреса CDN вместо введенных вами.

(Другие CDN работают таким же образом, поскольку весь смысл использования CDN заключается в том, что ваши клиенты общаются с ним. Например,superuser.comдомен использует Fastly CDN, поэтому он всегда преобразуется в IP-адреса близлежащих узлов Fastly.)

Таким образом, целью коротких TTL с CDN является не защита, а балансировка нагрузки (авторитетный сервер CDN динамически отвечает «лучшими» узлами на данный момент, как с точки зрения нагрузки, так и с точки зрения геолокации).

Когда несколько записей DNS разрешаются одному и тому же IP-адресу, например google.com и facebook.com, оба разрешаются до 1.2.3.4, какой элемент/компонент в сети отвечает за перенаправление пользователя на правильный веб-сайт?

На самом деле это клиент и сервер, а не сеть.

Каждый HTTP-клиент указывает запрошенный домен как часть HTTP-запроса — это заголовок «Host» в HTTP/1.1 (или псевдозаголовок «:authority» в HTTP/2). Веб-серверы или обратные прокси-серверы сопоставят полученное значение хоста с соответствующим <VirtualHost> или аналогичной конфигурацией.

(Вы можете просмотреть все заголовки запросов с помощью F12«Инструментов разработчика» в браузере — откройте вкладку «Сеть», чтобы начать сбор данных, затем вернитесь в браузер и нажмите F5, чтобы перезагрузить веб-страницу, и вернитесь в «Сеть». раздел.)

Аналогично, клиенты TLS также указывают запрошенный домен как расширение «Индикация имени сервера» в TLS ClientHello, чтобы сервер мог отправить правильный сертификат.

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

Но сеть (на уровне IP) вообще не заботится о доменах (или сайтах) — ее единственная задача — доставлять пакеты на 1.2.3.4, и если IP-адрес тот же, то и сервер назначения тоже тот же. . («Целевым сервером» в данном случае является интерфейс обратного прокси-сервера CDN.)