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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

По-разному.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Расходы на использование сторонних DNS часто не стоят преимуществ.

Негативы наличия стороннего DNS часто незаслуженно игнорируются.

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