Проходили ли вы профилирование через существующий DNS-сервер AD - по сравнению с сервером пересылки AD DNS, установленным по-разному между вашим интернет-провайдером и Google? Или вы просто профилировали напрямую своего интернет-провайдера и DNS Google?
Я понимаю, что если у вас уже есть локальный DNS-сервер (AD, BIND или другой), и все ли ваши клиенты используют этот локальный пересылающий DNS-сервер - если локальный DNS-сервер настроен правильно, он будет кэшировать исходящие результаты. Таким образом, только первый DNS-запрос для данного имени ресурса в течение разумного времени TTL необходимо будет перенаправить за пределы вашей сети для разрешения. Имея это в виду, не можете ли вы просто использовать своего интернет-провайдера?
Это один из тех случаев, когда процесс составления вопроса сделал мне ответ ясным. Я не ожидал, что какой-либо DNS-сервер сможет автоматически сделать это различие. Я просто хотел вручную направить некоторые из наиболее часто запрашиваемых cdn нашей сети в нужное место. Для этого мне все равно придется вручную вводить значения где-нибудь, и в этот момент я также могу просто выполнить поиск и разместить эти записи непосредственно на нашем сервере AD DNS. Условные пересылки были бы лучше, но я не видел в AD способа сделать это.
Я собираюсь посидеть на этом некоторое время, так как это имеет значение (например, необходимость часто проверять это вещи не изменились, проверьте, стоит ли по-прежнему вести определенные записи и т. д.), и, возможно, еще есть способ лучше. В нашем случае мы Это небольшой колледж, поэтому на самом деле в основном имеют значение два компакт-диска: netflix и facebook. На каждую из этих двух приходится около 40% нашего трафика по размеру и количеству обращений соответственно, и наличие более быстрого поиска в целом, с правильными результатами конкретно для этих двух, вероятно, было бы заметным улучшением.
Это просто служба DNS с разделенным горизонтом на прокси-сервере DNS, что в простейшем случае довольно просто.
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-поиска в вашей локальной сети, поработайте над этим.
Бесконтрактные, внешние третьи стороны для прокси-службы HTTP или службы отправки SMTP. Прокси-служба DNS немного отличается, и для нее применяются те же доводы. То, что вы хотите сделать, на самом деле довольно плохая идея.Если вы хотите улучшить работу DNS-поиска в вашей локальной сети, поработайте над этим.
Бесконтрактные, внешние третьи стороны для прокси-службы HTTP или службы отправки SMTP. Прокси-служба DNS немного отличается, и для нее применяются те же доводы. То, что вы хотите сделать, на самом деле довольно плохая идея.Если вы хотите улучшить работу DNS-поиска в вашей локальной сети, поработайте над этим.