Назад | Перейти на главную страницу

Используйте разные DNS-серверы для CDN

Когда Google впервые выпустил свои DNS-серверы 8.8.8.8 и 8.8.4.4, я провел некоторое профилирование, и они путь быстрее для нашего местоположения. Более свежий тест подтверждает, что это все еще так. Однако после тщательного рассмотрения я отказался от перехода от DNS нашего провайдера, потому что, глядя на несколько снимков нашего трафика, многие из наших запросов были на адреса cdn. Использование центрального DNS-сервера для поиска на сайтах CDN может привести к работающим результатам (и быстрому получению результатов), но замедлить работу, поскольку они могут возвращать менее оптимальные узлы.

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

Это только сервис DNS с расщеплением горизонта на прокси-сервере DNS, что в простом случае довольно просто.

  • Для пересылка прокси-сервер DNS просто использует условную пересылку. Обратитесь к руководству по программному обеспечению вашего DNS-сервера, чтобы узнать, как выполнить условную пересылку. djbdns, DNS-сервер Microsoft, BIND ISC, мой DNSFCPD, и несколько других могут выполнять условную пересылку.
  • Для разрешение прокси-сервер DNS использует любые механизмы отмены делегирования, предоставляемые серверным программным обеспечением. Для djbdns добавляется файл в servers/ каталог. Для BIND ISC и DNS-сервера Microsoft используются зоны-заглушки.

Проблема в том, что CDN не простые случаи, и вы готовите себе головную боль постоянного обслуживания.

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

Например: www.microsoft.com. это псевдоним для toggle.www.ms.akadns.net. который является псевдонимом для g.www.ms.akadns.net. который является псевдонимом для lb1.www.ms.akadns.net. который соответствует IP-адресу 65.55.12.249. Вы можете сделать чернослив и прививку в microsoft.com., g.www.ms.akadns.net., www.ms.akadns.net., ms.akadns.net., или akadns.net.. Но вы не знаете, какое место подходит, не зная, что оба специфичный для этого CDN и даже не обязательно вам известно в первую очередь. Совершите ошибку, и вы снова столкнетесь с проблемой серверных запросов, поступающих с IP-адреса третьей стороны, и данные DNS подходят для этого адреса, а не для вашего.

Более того, Akamai может изменить все эти промежуточные доменные имена через десять минут без необходимости информировать вас об этом, чтобы вы могли перенастроить свои переопределения с разделенным горизонтом. И завтра можно будет повторить все заново. Умножьте это на все различных CDN, для которых вы собираетесь использовать службу DNS с разделенным горизонтом, и впереди вас ждет огромная гонка красной королевы.

В любом случае, как другие иметь указал, на самом деле не рекомендуется использовать сторонние, бесконтактные, внешние, финансируемые рекламодателем, беспорядочные прокси-серверы DNS. Люди бы не мечта передачи финансируемым рекламодателем, бесконтрактным, внешним третьим сторонам для прокси-службы HTTP или службы отправки SMTP. Прокси-служба DNS немного отличается, и для нее применяются те же доводы. То, что вы хотите сделать, на самом деле довольно плохая идея.

Если вы хотите улучшить работу DNS-поиска в вашей локальной сети, поработайте над этим.

При профилировании выполнялось ли профилирование через существующий сервер AD DNS - по сравнению с сервером пересылки AD DNS, установленным по-разному между вашим интернет-провайдером и Google? Или вы просто профилировали напрямую своего интернет-провайдера и DNS Google?

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

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

Я собираюсь посидеть над этим некоторое время, так как это имеет значение (например, необходимость часто проверять, что что-то не изменилось, проверять, стоит ли по-прежнему вести определенные записи и т. Д.), И еще может быть лучше. В нашем случае мы - небольшой колледж, поэтому в основном имеют значение два компакт-диска: netflix и facebook. На каждый из них приходится около 40% нашего трафика по размеру и количеству обращений соответственно, и наличие более быстрого поиска в целом с правильными результатами для этих двух, вероятно, будет заметным улучшением.