Должны ли мы размещать собственные серверы имен?

  

Это Канонический вопрос об аутсорсинге разрешения DNS для собственных доменов

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

Вы предпочитаете размещать свой собственный DNS или лучше, если ваш интернет-провайдер сделает это?

Есть ли альтернативы, которые я могу изучить?

87 голосов | спросил Saif Khan 11 J0000006Europe/Moscow 2009, 02:46:38

21 ответ


62

Я бы не запускал свой собственный DNS-сервер - в моем случае хостинговая компания, на которой размещается мой сайт, предоставляет бесплатный сервис DNS. Существуют также альтернативы, компании, которые ничего не делают, кроме DNS-хостинга ( DNS Made Easy , но есть и многие другие), которые являются такими что вы, вероятно, должны изучить.

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

ответил David Z 11 J0000006Europe/Moscow 2009, 02:55:23
27

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

Если у вас нет нескольких сайтов, я бы подумал о том, кто конкретно делает DNS-хостинг (НЕ ваш интернет-провайдер) с веб-интерфейсом для изменений. Также посмотрите поддержку 24x7 и достойные SLA.

ответил Doug Luxem 11 J0000006Europe/Moscow 2009, 02:54:39
18

Для хорошей, надежной настройки DNS для вашего домена, вы должны иметь ...

  • Как минимум два авторизационных DNS-сервера для вашего домена;
  • DNS-серверы должны быть подключены к различным физическим сетям и источникам питания;
  • DNS-серверы должны находиться в разных географических зонах.

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

ответил Convict 11 J0000006Europe/Moscow 2009, 05:30:14
13

В течение многих лет я запускал свои собственные DNS-серверы, используя BIND (версии 8 и 9) без каких-либо серьезных проблем. Я сохранил свои конфигурации в контроле версий с проверками после фиксации, которые будут проверять файлы зон, а затем мои DNS-серверы проверяют файлы зон через равные промежутки времени. Проблема всегда заключалась в том, что серийный номер SOA был обновлен с каждой фиксацией, которая была вытолкнута, в противном случае кеширующие серверы не будут обновляться.

Через несколько лет я работал с djbdns, поскольку формат был идеальным для создания автоматических сценариев для управления зонами и не страдал от того же самого серийного номера SOA, с которым мне приходилось иметь дело с использованием BIND. Однако у него возникли проблемы с форматированием определенных наборов записей ресурсов, чтобы их можно было принять.

Как я понял, большая часть моего трафика была DNS и должна поддерживать как первичный, так и вторичный DNS-сервер, чтобы понравиться регистраторам, с которых я перешел на использование EasyDNS для моих потребностей DNS. Их веб-интерфейс прост в управлении и дает мне гибкость, необходимую мне для управления наборами RR. Я также нашел, что с ним легко работать, чем с теми, которые предоставляются некоторыми хостинг-провайдерами, такими как 1 & 1 , которые ограничивают доступные наборы RR, которые вы можете ввести, или даже регистраторы доменов, например Сетевые решения , которые работают только в том случае, если вы используете Windows для управлять DNS.

ответил Jeremy Bouse 11 J0000006Europe/Moscow 2009, 05:14:36
8

Для моих личных доменов (и некоторых доменов друзей, с которыми я помогаю) мы размещаем наш собственный DNS, а мой регистратор (Gandi) предоставляет дополнительный DNS. Или друг в другой сети обеспечивает вторичный доступ. Gandi не обновляет зоны сразу, они, кажется, проверяют примерно раз в 24 часа или около того, но изменения очень редки; работает достаточно хорошо для нас, и их сервер, вероятно, гораздо более надежный, чем наш.

На моей работе мы создаем собственный DNS, и наш провайдер восходящей сети обеспечивает вторичный DNS. Тем не менее, мы являемся университетом, и 99% наших пользователей находятся на месте; если локальная сеть отключена, не имеет значения, отключен ли DNS. Кроме того, у нас есть полный класс-B (/16) с примерно 25k DNS-записями (плюс 25k обратных записей DNS, конечно), что кажется немного неудобным для управления через веб-интерфейс. Наши локальные DNS-серверы доступны и доступны очень быстро.

ответил freiheit 11 J0000006Europe/Moscow 2009, 03:23:01
5

Я сделал оба. Могут быть преимущества с размещением вашего собственного: вы определенно много узнаете о том, как работает DNS, когда ваш босс спрашивает вас, почему его так долго. Кроме того, вы гораздо более контролируете свои зоны. Это не всегда так сильно, как должно быть, во многом из-за иерархической распределенной природы DNS, но время от времени это пригодится. Совсем так, если вы можете заставить своего провайдера выделить вас в качестве SOA для обратного DNS вашего IP-блока, если у вас есть один.

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

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

ответил Kyle Hodgson 11 J0000006Europe/Moscow 2009, 06:06:50
4

Я читаю все эти решения с некоторым развлечением, потому что нам удалось случайно вписаться во все эти «требования» путем размещения нашего основного DNS с статической линии DSL, а наличие регистратора (который был на другом континенте) обеспечил вторичный DNS на гораздо более серьезную и надежную связь. Таким образом, мы получаем всю гибкость использования bind и установки всех записей в то время, будучи разумно уверенным, что вторичная информация обновляется, чтобы отразить эти изменения и будет доступна в случае, если люк загорается, чтобы привести одно событие.

Это эффективно выполняет:
«Как минимум два авторитетных DNS-сервера для вашего домена».
«DNS-серверы должны быть подключены к различным физическим сетям и источникам питания».
«DNS-серверы должны быть в разных географических зонах».

ответил dlamblin 14 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowMon, 14 Sep 2009 11:56:01 +0400 2009, 11:56:01
4

Взгляните на Dyn.com ; у них есть все виды DNS-сервисов, таких как DNS-хостинг, динамический DNS, MailHop и т. д. и т. д. Я нашел их надежными и использовал их, вероятно, 5 лет.

ответил Knox 11 J0000006Europe/Moscow 2009, 03:17:59
3

Это зависит.

Я запускаю свой собственный DNS для своих различных заданий с конца 80-х (BSD 4.3c). Для работы я всегда размещал свой собственный DNS, но у меня всегда было несколько центров данных, или я мог обменять вторичный DNS с партнером. Например, на моей последней работе мы использовали вторичный DNS для другого .EDU (они были в MN, мы в CA), и они сделали то же самое для нас. Географическое и сетевое разнообразие.

Или, на моей нынешней работе у нас есть наши собственные дата-центры на восточном и западном побережье (США). Хостинг нашего собственного DNS позволяет нам использовать любые необычные DNS-записи, которые могут потребоваться (SVR, TXT и т. Д.), Которые могут не поддерживаться некоторыми службами DNS-интерфейса. И мы можем менять TTL, когда захотим; у нас есть довольно большая гибкость, ценой самих действий.

Для домашних вещей я сделал это в обоих направлениях. Для некоторых доменов, где я занимаюсь необычными вещами или нуждаюсь в большой гибкости, я все еще запускаю свои собственные «скрытые» мастер-DNS-серверы и обмениваюсь общедоступными службами DNS с другими, которые делают то же самое. Я использую RCS для файлов зон контроля версий для управления конфигурацией, поэтому я могу увидеть всю историю изменений зоны до начала времени. Для простых вещей, таких как домен с одним блогом или универсальными веб-серверами (одна запись или один CNAME), проще использовать DNS-службу регистраторов доменов, где они доступны, и теперь беспокоиться о CM.

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

ответил tep 11 J0000006Europe/Moscow 2009, 09:27:25
3

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

  1. Если вам нужен DNS-сервер, чтобы разрешить интернет-ресурсы, для вас нужен бесплатный бесплатный DNS-ресивер. Я лично использую PowerDNS recursor (pdns-recursor) в Linux.

  2. Для обслуживания вашей внешней инфраструктуры, например веб-сайтов или MX, я бы не использовал внутренние NSes (если мы говорим о SOHO здесь). Используйте некоторые хорошие, надежные, пуленепробиваемые службы, такие как DNSmadeasy . Я использую их бизнес-пакет, и он потрясает, будучи очень доступным.

ответил Taras Chuhay 11 J0000006Europe/Moscow 2009, 12:44:33
2

Я использовал Zonedit или годы. Его дешевый (или бесплатный), и я добавил много CNAME, A, MX, TXT, SRV и других записей.

ответил Steve Jones 11 J0000006Europe/Moscow 2009, 02:52:59
2

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

ответил mrdenny 11 J0000006Europe/Moscow 2009, 05:51:31
2

У меня есть лучшее из обоих миров.

Я размещаю свой общедоступный DNS для своих сайтов и своих записей MX «где-то еще». Это надежный, безопасный, он работает, я могу изменить его по своему усмотрению. Я плачу за услугу, и я доволен стоимостью.

Но дома я запускаю собственный кеширующий DNS-сервер, а не полагаюсь на своего интернет-провайдера. У моего интернет-провайдера есть привычка к потере DNS, медленному DNS, недопустимому DNS, а иногда они хотят извратить DNS, чтобы сбои шли в те места, которые, как они думают, меня могут заинтересовать. Я не заинтересован в использовании DNS моего ISP. Поэтому у меня есть собственные кеширующие DNS-серверы и делаю это самостоятельно. Это было немного сложнее настроить в начале (может быть, 2 часа), но он чист, и у меня есть надежный DNS. Раз в месяц задание cron запрашивает корневые серверы и обновляет таблицу подсказок. Может быть, раз в год мне приходится возиться с ним, например, отправив doubleclick.com на 127.0.0.1 или тому подобное. Помимо этого, он не требует вмешательства, и он отлично работает.

ответил codebunny 11 J0000006Europe/Moscow 2009, 06:03:14
2

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

ответил XTZ 11 J0000006Europe/Moscow 2009, 06:58:51
2

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

Это дает лучшее из обоих миров; немедленный контроль плюс избыточность.

ответил pauska 11 J0000006Europe/Moscow 2009, 11:38:25
2

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

ответил Maximus Minimus 11 J0000006Europe/Moscow 2009, 12:37:26
2

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

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

Самое большое преимущество для размещения вашего собственного DNS заключается в том, что изменения могут быть сделаны сразу. Нужно сократить ваши TTL для предстоящей миграции? Вероятно, вы могли бы написать сценарий, который делает это на ваших собственных серверах; для размещенного DNS вам может потребоваться войти в систему и вручную изменить записи или, что еще хуже, позвонить провайдеру, пройти три уровня поддержки, пока вы, наконец, не достигнете того, кто может использовать DNS, просто чтобы они сказали вам, что они отправят меняется через 2-3 дня.

ответил David Oresky 14 J0000006Europe/Moscow 2009, 18:42:16
2

Я запускаю свой собственный DNS, используя BIND на серверах Linux. В настоящее время у меня четыре человека, расположенных в Лондоне, Майами, Сан-Хосе и Сингапуре. Отлично работает, и у меня есть полный контроль. Стабильность центра обработки данных очень важна, поэтому я выбрал хороший DC для запуска серверов (не зависящих от ISP или какой-либо другой «неизвестной» инфраструктуры). Я могу настроить DNS-серверы и другие службы в любой точке мира, используя DC мирового класса, которые я выбираю на основе строгих критериев. Rock solid DNS необходим для работы электронной почты и веб-сервисов, которые я запускаю.

ответил Justin Jones 25 PM00000080000005231 2012, 20:36:52
2

Должны ли мы размещать собственные серверы имен?

Да, и вы также должны использовать один или несколько крупных сторонних поставщиков DNS. Гибридное решение, вероятно, является самым безопасным долгосрочным подходом по нескольким причинам, особенно если вы являетесь бизнесом, у которого есть какое-либо усаживание SLA или контрактные требования к вашим клиентам. Тем более, если вы b2b.

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

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

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

Другим преимуществом того, что ваш собственный мастер (идеально скрытый, неопубликованный) является то, что вы можете создать свой собственный API и обновить его в любом месте, соответствующем вашим потребностям. С сторонними поставщиками DNS вам нужно будет адаптироваться к их API. Каждый поставщик имеет свои собственные; или в некоторых случаях просто имеет веб-интерфейс.

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

С юридической точки зрения, предотвращение блокировки поставщика может также иметь важное значение для вашей компании. Например, Dyn потенциально приобретается Oracle. Это ставит их в уникальное положение для сбора статистики DNS для всех клиентов Dyn. Существуют конкурентные аспекты этого, которые могут ввести юридический риск. Тем не менее, я не юрист, поэтому вам следует проконсультироваться с вашими юридическими и PR-группами.

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

[Изменить] Если это только для небольшого личного /хобби-домена, то 2 виртуальных машины, которые не находятся в одном и том же центре данных, как и друг с другом, работают с небольшим DNS-демоном более чем достаточно. Я делаю это для своих личных доменов. Мне было непонятно, если ваш домен означает бизнес или просто для хобби. Какими бы ни были самые маленькие виртуальные машины, которых вы можете получить, более чем достаточно. Я использую rbldnsd для своих доменов; используя очень высокий TTL на моих записях, поскольку он занимает 900 КБ оперативной памяти и может обращаться с любыми людьми, злоупотребляющими им.

ответил Aaron 6 Jpm1000000pmFri, 06 Jan 2017 23:34:03 +030017 2017, 23:34:03
1

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

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

Итак, у меня наш DNS размещен снаружи.

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

ответил Brian 17 J0000006Europe/Moscow 2009, 16:51:13
0

Это зависит. "

Я использую свои собственные серверы и управляю доменами, по крайней мере, с 2002 года.

Я часто использовал DNS-сервер моего провайдера.

Сколько раз мой сервер на моем IP-сервере был доступен, но моего DNS не было, было слишком много.

Вот мои военные истории:

  • Один крупный провайдер в Москве (один из первых на базе VZ) имел мой VPS в дешевом «стоимостном» DC, но их DNS были в превосходном состоянии DC с дорогостоящим трафиком , в двух разных /24 подсетях, как требовалось некоторым TLD в то время . В какой-то момент произошло поражение от катастрофы (возможно, отключение питания в 2005 году? ) и их дорогостоящие DC отключился, и мой сайт (все еще в Москве, но в «значении» DC) мог быть доступен только по его IP-адресу.

    Интересно, что даже перед любыми инцидентами я, очевидно, помню, как делал traceroute , и, заметив тот же DC для обоих ns1 и ns2 моего интернет-провайдера, попросив их перевести его в «мой» DC тоже для гео-избыточности; они отклонили идею гео-избыточности, потому что серверы уже были в самом лучшем варианте DC.

  • У меня был другой провайдер (один из первых на базе ISP-систем), где у них был один нс на месте, а другой - за границей. Короче говоря, вся установка была смехотворной ошибкой, а сервер «за границей» часто не поддерживал свои зоны, поэтому у моего домена была эффективная дополнительная ошибка, и она не была бы доступна, даже если бы весь мой сервер все равно работал плавно.

  • У меня был регистратор, который управлял собственной сетью. Время от времени оно падало, даже несмотря на то, что мои серверы вне сайта были готовы. Мой DNS был недоступен.

  • Недавно я использовал несколько крупных облачных провайдеров для вторичных, где я сам запускал скрытый мастер. Оба провайдера изменили свою настройку хотя бы один раз; никогда с публичными объявлениями; некоторые из моих доменов перестали решаться. Случилось и с моим другом, с одним из тех же поставщиков. Это происходит чаще с сторонними службами, чем люди, которые хотят публично признаться.

Короче говоря, http://cr.yp.to/djbdns/third- party.html абсолютно правильно по теме.

Затраты на то, чтобы беспокоиться о сторонних DNS часто не стоят преимуществ.

Отрицания наличия стороннего DNS часто несправедливо игнорируются.

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

ответил cnst 6 Jpm1000000pmFri, 06 Jan 2017 22:56:16 +030017 2017, 22:56:16

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

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132