DNS на самом деле довольно сложная тема. Так что понимаю, что я здесь говорю, очень сильно «широкими мазками». Чтобы понять различные виды услуг DNS, сначала необходимо понять анатомию DNS-запроса .
Суть DNS.
Подводя итог (и упростить), DNS-запрос принимает имя хоста ... скажем myserver1.example.com
... и просит DNS-сервер, настроенный в настройках вашей системы (ваш "локальный DNS-сервер"), дать ему IP-адрес, соответствующий этому имени хоста. Тогда все может пойти одним из двух способов. Если локальный DNS-сервер знает IP-адрес, соответствующий этому имени хоста, он просто отвечает с правильным ответом.
Однако, если он не знает правильного ответа, он должен попросить другой DNS-сервер в Интернете дать ему ответ. Чтобы выяснить, какой DNS-сервер должен спросить (какой DNS-сервер является полномочным для этого имени хоста), он запрашивает «корневые» DNS-серверы. Это авторитетные серверы для «доменов верхнего уровня», таких как .com
, .info
и т.д. Он просит корневые серверы, что авторитетный сервер DNS для, в нашем примере случае, домен example.com
. Корневые серверы отправляют вашему локальному DNS-серверу ip-адрес всех серверов, которые являются доверенными для «example.com», и ваш локальный DNS-сервер затем запрашивает эти доверенные серверы на соответствие ip-адреса myserver1.example.com
.
Таким образом, авторитетный DNS-сервер - это тот, кто окончательно определяет, с каким запросом соответствует какой результат, а пересылающий DNS-сервер - это тот, который перенаправляет запросы на авторитетные DNS-серверы, когда у него нет ответа. Так как же сервер переадресации DNS может получить ответ сам? По кэширование прошлых результатов. В этом случае первый запрос займет много времени (в компьютерном времени), чтобы получить результат, но любые будущие запросы для того же имени хоста получат результат очень и очень быстро. Учтите, что для загрузки одной веб-страницы браузер должен часто искать дюжину имен хостов ... часто те же самые, которые он просматривал в прошлый раз, когда посещал этот сайт. Наличие одного или нескольких серверов кэширования домена в локальной сети может сделать Интернет, который у вас уже есть, гораздо более отзывчивым для пользователей.
Таким образом, в приведенном выше примере наш пересылающий DNS-сервер также является кэширующим DNS-сервером. Это также могут быть официальные DNS-серверы для вашей компании. В этом случае им также не нужно будет пересылать запросы на имена хостов, для которых ваши собственные DNS-серверы являются авторитетными ... они могут просто ответить ответом.
Но! И это важно. Вы никогда не должны работать только с одним официальным DNS-сервером. Фактически, многие регистраторы просто откажутся разрешить это для публично видимых авторитетных DNS-серверов. Это не из-за проблем с производительностью, а скорее из-за необходимости избыточности в инфраструктуре DNS, от которой так зависит интернет. Вторичный авторитетный сервер во всех отношениях аналогичен любому другому DNS-серверу, за исключением того, что он пытается хранить записи, которые он уполномочен синхронизировать с другим (основным) авторитетным сервером. Это означает, что когда вы будете обновлять записи, вы будете делать это на первичном полномочном сервере, и изменения будут быстро распространяться на любые вторичные полномочные серверы, которые у вас могут быть. Как быстро зависит многое от конфигурации DNS-серверов.
Итак, давайте перейдем к вашему примеру.
Одного сервера переадресации DNS достаточно, чтобы справиться с нагрузкой 250 пользователей. Наличие второго сервера пересылки DNS - хорошая идея просто в случае сбоя ... чтобы не прерывать рабочий день. Важно, чтобы серверы пересылки были настроены на пересылку запросов только из вашей локальной сети. В идеале, эти серверы даже не будут доступны из Интернета, но могут быть случаи, когда это необходимо. В таких случаях важно следить за тем, чтобы ресурсы вашей компании не использовались интернет-загрузчиками. В идеале вы также должны настроить эти серверы для кэширования результатов на некоторое время.
Что касается авторитетного DNS ... ну ... это зависит от того, чего вы хотите достичь. Если вы пытаетесь сделать так, чтобы различные машины в вашей сети могли находить друг друга по имени хоста, а не по IP-адресу, вам сначала понадобятся статические IP-адреса, назначенные каждому устройству, которое вы хотите таким образом достичь. Это будет особенно сложно с портативными устройствами. Существуют способы сделать автоматическое обновление записей, чтобы они соответствовали IP-адресам, назначенным DHCP ... но существует значительное снижение надежности и связанное с этим увеличение необходимого обслуживания. Скорее всего, слишком много для 250 пользователей.
Затем вам понадобятся два авторитетных сервера: основной и дополнительный. Они могут быть теми же серверами, что и ваши серверы пересылки / кэширования ... но будьте особенно внимательны при настройке DNS-серверов, чтобы они не давали достоверных ответов на запросы, исходящие из Интернета. Это не только вопрос сохранения ресурсов или даже безопасности, но и предотвращения загрязнения инфраструктуры DNS Интернета информацией, которая бесполезна за пределами вашей локальной сети.
Каждое устройство в сети, которое будет пытаться искать имена хостов через собственный уполномоченный DNS-сервер или серверы пересылки / кэширования DNS, должно будет настроить эти DNS-серверы в качестве своего основного и дополнительного DNS-серверов. На самом деле, для ваших авторитетных DNS-серверов идеально также переадресовывать серверы, чтобы упростить настройку и убедиться, что нет бессмысленных запросов для имен узлов в Интернете, отправляемых на локальный DNS-сервер или наоборот.
Вам также необходимо разработать собственную схему имен хостов. Слово совета ... не используйте в .local
качестве своего TLD. Он конфликтует с децентрализованными службами DNS, такими как mDNS (многоадресная DNS), которые являются общими для устройств Apple. Лучшая практика заключается в использовании доменного имени вашей компании и создать subomain ( subdomain.domain.tld
), при котором все локальные узлы назначаются ( myserver1.myoffice1.company.com
, myworkstation256.myoffice1.company.com
и т.д.).
Теперь, если вы хотите, чтобы авторитетные DNS-серверы публично размещали DNS для доменного имени вашей компании (для вашего веб-сайта и т. Д.) ... тогда вам нужно заняться поиском. Почти во всех случаях вам лучше платить за управляемый хостинг, который включает управляемый хостинг DNS. Есть много преимуществ для этого. Все, от улучшенной избыточности (большинство хостов имеют 5 или более DNS-серверов, обращенных к Интернету), до лучшего физического размещения (хосты могут размещать DNS-серверы в разных центрах обработки данных для дальнейшего повышения избыточности и сокращения времени ожидания для людей, пытающихся добраться до вашего сайта), до более сложных конфигураций (например, использование функции geoip для направления запросов к физически ближайшим серверам DNS).
Надеюсь, что отвечает на ваши вопросы.