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

Есть ли причина использовать внутренний DNS поверх 8.8.8.8?

Я унаследовал локальную сеть, в которой действительно не выполняется разрешение имен для локальных ресурсов ... т.е. все пользователи вводят IP-адреса вручную для доступа к принтерам и сетевым ресурсам. Также нет серверов или доменов LDAP ... рабочие станции просто подключаются к сети без аутентификации. DHCP обрабатывается через основной коммутатор ... И настройки DNS также передаются этим же основным коммутатором. В настоящее время назначения DNS таковы и в следующем порядке:

10.1.1.50     / old Pentium III Windows 2003 box running DNS service- 128 MB RAM
169.200.x.x   / ISP
4.2.2.2.      / the well known public one

В локальной сети несколько тысяч клиентов ... и большая часть активности - это просмотр веб-страниц (это образовательная среда).

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

Какую мощность должен иметь активно используемый DNS-сервер?

Я также слышал использование 4.2.2.2 - плохая идея .... раз уж им так злоупотребляли ...

Наконец, не имеет ли смысла указывать первым надежный внешний DNS-сервер? (Google 8.8.8.8 кажется логичным кандидатом)

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

Если бы я был в университете, который использовал службу имен Google, я бы очень быстро поднял вопросы конфиденциальности.

Некоторые вещи лучше хранить дома, и разрешение DNS, похоже, является одним из них. Если вы не можете или не хотите запускать стабильный сервер, например BIND затем приобретите устройство для локального разрешения DNS.

DNS для небольшого сайта может работать на очень маленькой машине, но я бы не стал включать DNSSEC. :)

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

Поскольку вы вообще не указали, что существующая система работает не идеально, нет фактического необходимость изменить что-либо.

В отношении

Google 8.8.8.8 кажется логичным кандидатом

Почему это логично? Почему бы просто не использовать DNS интернет-провайдера или какой-либо другой нефильтрованный источник?

Я бы пошел еще дальше и удалил 4.2.2.2, так как вероятность того, что клиенты когда-либо столкнутся с ним, ничтожна. В конце концов, чтобы это произошло, и машина 2003 года, и DNS провайдера должны быть отключены. Если вы действительно чувствуете потребность в третьем источнике DNS, добавьте вместо него вторичный поставщик услуг Интернета.

Я работаю в университете, и мы используем внутренний DNS-сервер только для внутренних записей, в остальном все запросы перенаправляются на Google 8.8.8.8/8.8.4.4 без каких-либо проблем.

Вы получите более быстрый отклик для веб-серфинга и уменьшите свой сетевой трафик, если настроите локальный DNS-сервер, даже если вы используете его только в качестве прокси-DNS-сервера (например, все ваши клиентские машины выполняют поиск на вашем локальном DNS-сервере, который затем выполняет поиск в общедоступном DNS-сервере / DNS-провайдере по вашему выбору, а затем кэширует ответы). Почему вы получите более быстрый ответ? Проверьте связь с хостом в сети 10/100/1000 Мбит и сравните результат с проверкой связи с общедоступным DNS-сервером через подключение к Интернету на 1/2/8/10 Мбит. Я предполагаю, что вы сразу получите выгоду от локальной инфраструктуры DNS, которая не будет стоить вам так дорого.

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

Причины использования внутреннего DNS-сервера:

  • У вас есть внутренние домены, которые не являются общедоступными или отличаются от общедоступных.
  • Вы бы хотели повозиться с кешированием и другими проблемами производительности.
  • Вы хотите регистрировать запросы DNS, чтобы отслеживать, кто куда идет.
  • Вы хотели бы заблокировать определенные вещи (обратите внимание, что люди будут обходить это, изменив свой DNS-сервер на 8.8.8.8 или что-то еще, поэтому вам придется заблокировать DNS для чего-либо, кроме вашего сервера, на вашем брандмауэре)
  • Вы хотите перенаправить определенные домены (например, перенаправить facebook.com на политику условий найма) (конечно, у вас будут те же проблемы, что и при блокировке доменов)
  • Вы действительно хотите понять, как работает DNS.
  • Вы помешаны на контроле.
  • Вы шпион.

Я почти не слышал о 4.2.2.2, но этот вот что я слышал.

Я бы порекомендовал вам использовать как минимум два DNS-сервера для большой сети из тысяч клиентов. Я бы не хотел быть вами, если (или, скорее, когда) ONE DNS выйдет из строя ...

Если вы ищете такую ​​же простоту и не хотите размещать свой собственный, я рекомендую вам проверить OpenDNS где вы можете даже настроить некоторые фильтрации (порно и т.д.), которые вы можете захотеть по образовательной сети. Особенно в образовательной сети.

Конечно, я бы наиболее окончательно использовал Google 8.8.8.8 И 8.8.4.4 вместо 4.2.2.2.

Этот сервер Win2003 используется для чего-нибудь еще? Я бы взорвал его, бросил на ваш любимый дистрибутив Linux / BSD и установил на него DNSMasq.

Возможно, имеет смысл настроить DNS-сервер с немного большей мощностью. Вы можете использовать ведение журнала отладки DNS в свойствах DNS Windows 2003, чтобы регистрировать DNS-запросы, чтобы узнать, какой объем DNS-трафика вы получаете. Для внутренних запросов вы можете установить для TTL локальных записей большое значение, чтобы уменьшить количество запросов. 3600 секунд возможно?

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

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

По причинам производительности локальный DNS трудно превзойти. Если вам не нужен собственный сервер для локального разрешения имен, то второй лучший выбор IMO - использовать DNS-сервер, предоставленный вашим интернет-провайдером, по простой причине: теоретически вы не можете выполнить более быстрое разрешение DNS, чем через вашего интернет-провайдера, просто потому, что запросы к любому другому общедоступный DNS-сервер (например, 8.8.8.8 или 4.2.2.2) в любом случае будет проходить через серверы вашего интернет-провайдера. (очевидно, что ваш интернет-провайдер неправильно настроил DNS, но я предполагаю, что он работает должным образом).

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

Например, если я хочу разрешить google.com используя DNS-сервер от моего интернет-провайдера:

> dig -4 -u +notcp google.com @76.14.0.8
...
google.com.             210     IN      A       172.217.6.46
;; Query time: 9027 usec
...

На ее решение ушло 9027 микросекунд. Если я бегу 10 раз, я получаю стабильные значения в диапазоне 9-10 мс. Теперь, если я попытаюсь использовать DNS-сервер Google:

> dig -4 -u +notcp google.com @76.14.0.8
...
google.com.             168     IN      A       216.58.192.14
;; Query time: 30024 usec
...

Прошло 30024 микросекунды. Если я копаюсь на их серверах, я получаю значения в диапазоне от 20 до 60 мс, что намного хуже, чем при использовании DNS-сервера, предоставленного моим местным интернет-провайдером. Я физически нахожусь в паре миль от штаб-квартиры Google, возможно, моя локальная точка, которая обрабатывает 8.8.8.8, тоже не так уж далеко, но для кого-то далеко от 8.8.8.8 разница будет намного хуже.

Если у вас есть локальный DNS-сервер (он может быть у вашего роутера), то:

> dig -4 -u +notcp google.com @192.168.0.1
...
google.com.             4       IN      A       216.58.195.78
;; Query time: 9368 usec
...

это заняло 9368 микросекунд, потому что у моего маршрутизатора не было кеша для google.com, и мне пришлось связаться с моим интернет-провайдером, чтобы решить эту проблему. Но если я запускаю его во второй раз, я всегда получаю кешированные результаты, которые стабильно меньше 1 мс:

> dig -4 -u +notcp google.com @192.168.0.1
...
google.com.             2       IN      A       216.58.195.78
;; Query time: 493 usec
...

Трудно превзойти такую ​​производительность.

В целом по порядку исполнения:

  1. Кэш ОС является самым быстрым (возможно, микросекунда или меньше для его разрешения), так как сетевые запросы не задействуются

  2. Локальный DNS-сервер со временем разрешения 0,5-1 мс

  3. DNS-сервер вашего интернет-провайдера (может быть что угодно, допустим, 10 мс)

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

Итак, когда вы будете использовать 8.8.8.8, 4-й вариант производительности вместо 2-го?

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

  • использовать его в качестве вторичного резервного DNS-сервера.

  • используйте его, если ваш основной DNS-сервер фильтрует некоторые домены (в некоторых странах для блокировки доступа к определенным сайтам).