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

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

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

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

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

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

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

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

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

Поскольку я обнаружил, что большая часть моего трафика составляла DNS, и мне приходилось поддерживать как первичный, так и вторичный DNS-серверы, чтобы удовлетворить регистраторов, я с тех пор перешел на использование EasyDNS для моих нужд DNS. Их веб-интерфейс прост в управлении и дает мне необходимую гибкость для управления моими наборами RR. Я также обнаружил, что с ним легче работать, чем с теми, которые предоставляются некоторыми хостинг-провайдерами, такими как 1 и 1 которые ограничивают доступные наборы RR, которые вы можете ввести, или даже регистраторы доменов, например Сетевые решения который работает, только если вы используете 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-сервер в силу того, что он находится в серверной стойке, вероятно, будет работать от батареи или батареи и дизельного топлива, в то время как ваш компьютер не будет - так что ваши клиенты будут отключены задолго до того, как отключится сервер.

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

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

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

Следует ли размещать собственные серверы имен?

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

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

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

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

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

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

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

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

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

Это зависит.

Я использую свой собственный DNS для различных работ с конца 80-х (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. Я использую их бизнес-пакет, и он потрясающий, но при этом очень доступный.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Издержки, связанные со сторонним DNS, часто не окупаются.

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

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