Вопросы Теги

Существует ли причина использовать внутренний DNS более чем 8.8.8.8?

Можно посмотреть на Alertsite, www.alertsite.com. Транзакционного теста, который можно запустить, который позволит Вам сценарию серию событий. Мы используем его в доме, чтобы войти в приложение дистанционного обучения и пробежать несколько процессов перед тем, чтобы выходить из системы. Хорошая вещь об этом состоит в том, что это будет время шаги, а также целое событие с хорошими подробными диаграммами, на которые можно посмотреть к часу, дню или месяцу. Это должно обработать прекрасный JavaScript.

5
задан 15 April 2010 в 21:13
9 ответов

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

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

В отношении

Google 8.8.8.8, казалось бы, был бы логическим кандидатом

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

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

6
ответ дан 3 December 2019 в 00:50
  • 1
    Все положительные стороны спасибо... Особенно, если ISP' s DNS не отвечает.. it' s, вероятно, признак отключения электричества и Google' s DNS (или 4.2.2.2) wouldn' t быть достижимым так или иначе –  CaseyIT 16 April 2010 в 04:58
  • 2
    Я просто получил downvote для этого. В то время как я действительно couldn' t заботятся меньше о потере нескольких точек, я чрезвычайно интересовался бы тем, почему кто-то думает, что это - достаточно плохой ответ на downvote. Существует ли техническая ошибка? Это плохо для использования здравого смысла? –  John Gardeniers 22 April 2010 в 01:32

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

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

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

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

13
ответ дан 3 December 2019 в 00:50
  • 1
    +1 для проблем конфиденциальности. Вы не можете пропустить такой аспект. –  Antoine Benkemoun 16 April 2010 в 00:41
  • 2
    Весь Ваш DNS, принадлежат Google. –  Wesley 16 April 2010 в 03:32

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

6
ответ дан 3 December 2019 в 00:50

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

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

5
ответ дан 3 December 2019 в 00:50

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

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

Я едва услышал о 4.2.2.2, но это - то, что я слышал.

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

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

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

2
ответ дан 3 December 2019 в 00:50
  • 1
    Я слышу беспокойство фильтрации..., но ISP имеет довольно хороший фильтр - я говорю довольно хороший начиная со студентов регулярно юбка вокруг этого с прокси как hidemyass.com и т.п. –  CaseyIT 16 April 2010 в 04:49
  • 2
    Это верно, и фильтрация DNS ничего действительно не делает кроме остановки менее технически наклоненный так или иначе. –  Gomibushi 16 April 2010 в 09:20

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

2
ответ дан 3 December 2019 в 00:50
  • 1
    Никакой it' s не, и that' s собирающийся происходить я могу уверить Вас! Haven' t слышал о DNSMasq, но изучит его. –  CaseyIT 16 April 2010 в 04:53
  • 2
    DNSMasq делает передачу/кэширование DNS (и DHCP, но Вы don' t потребность это и it' s не включенный по умолчанию). Другой опцией (и может быть более устойчивым) был бы BIND. –  gravyface 16 April 2010 в 05:07
  • 3
    Я уничтожил бы его и полностью избавляться от него - использует много электричества ни для чего. Как в: Получите ОДИН сервер, который современен, более мощен, виртуализируйте все старое дерьмо далеко. Я выполняю основанный на окнах DNS на машинах 256 МБ с очень трудной частью ЦП успешно. –  TomTom 16 April 2010 в 08:52

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

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

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

1
ответ дан 3 December 2019 в 00:50

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

Когда какое-либо приложение пытается разрешить имя хоста, сначала ОС пытается разрешить его, используя внутренний cache, если кеш недоступен, он свяжется с DNS-сервером. Используя dig , вы можете обойти кэш ОС, напрямую запросить свой или любой случайный 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-сервер, который должен примерно добавить что угодно дополнительное время, необходимое для обработки запроса от серверов вашего интернет-провайдера к другому DNS-серверу, может составлять от 20 до 60 мс в лучшем случае.

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

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

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

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

0
ответ дан 3 December 2019 в 00:50

Теги

Похожие вопросы