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

<blockquote> <p>это <a href="https://meta.serverfault.com/questions/1986">канонический вопрос</a> о том, стоит ли передавать разрешение dns для своих собственных доменов</p> </blockquote><p>в настоящее время у меня есть провайдер, предоставляющий dns для моего домена, но они налагают ограничения на добавление записей. поэтому я думаю о запуске собственного dns.</p><p>вы предпочитаете размещать свой собственный dns или лучше, чтобы ваш провайдер делал это?</p><p>есть ли альтернативы, которые я могу рассмотреть?</p>

<p>я бы не стал запускать свой собственный dns-сервер - в моем случае, хостинговая компания, которая размещает мой сайт, предоставляет бесплатный сервис dns. существуют также альтернативы, компании, которые делают только dns-хостинг ( <a href="http://www.dnsmadeeasy.com">dns made easy</a> приходит на ум, но есть много других), и вам следует обратить на это внимание.</p><p>причина, по которой я бы сам этого не сделал, заключается в том, что dns должен быть достаточно надежным, и если у вас нет собственной сети географически распределенных серверов, вы бы, так сказать, положили все свои яйца в одну корзину. кроме того, существует множество выделенных dns-серверов, и вам не нужно будет запускать новый.</p>

<p>мы всегда размещаем наш собственный dns (предпочтительнее и обратный dns). это позволяет нам вносить срочные изменения, не полагаясь на третьих лиц. если у вас есть более одного местоположения, легко установить приемлемый уровень избыточности для ваших dns-серверов.</p><p>если у вас нет нескольких сайтов, я бы посоветовал кому-то, кто специально занимается dns-хостингом (не вашим isp) с веб-интерфейсом для изменений. также ищите поддержку 24x7 и достойные sla.</p>

<p>для правильной и надежной настройки dns для вашего домена (ов) вы должны иметь ...</p><ul> <li>минимум два авторизованных dns-сервера для вашего домена;</li> <li>dns-серверы должны быть подключены к разным физическим сетям и источникам питания;</li> <li>dns-серверы должны находиться в разных географических зонах.</li> </ul><p>поскольку маловероятно, что у вас есть доступ к вышеуказанной сетевой инфраструктуре, лучше выбрать надежного поставщика услуг размещения dns (как рекомендовали другие), который имеет указанную выше сетевую инфраструктуру.</p>

<p>в течение многих лет я управлял своими собственными dns-серверами, используя bind (версии 8 и 9), без особых хлопот. я сохранял свои конфигурации в системе управления версиями с помощью проверок после фиксации, которые проверяли файлы зоны, и затем мои dns-серверы регулярно проверяли файлы зоны. проблема всегда заключалась в том, что серийный номер soa) обновлялся с каждым выдаваемым коммитом, иначе серверы кэширования не обновятся.</p><p>спустя годы я работал с djbdns, так как формат был идеальным для использования автоматизированных сценариев для управления зонами и не страдал от той же проблемы с soa серийным номером, с которой мне приходилось сталкиваться при использовании bind. у него есть свои проблемы с необходимостью форматирования определенных наборов записей ресурсов, чтобы они были приняты.</p><p>поскольку я обнаружил, что большая часть моего трафика была dns и мне приходилось обслуживать как основной, так и дополнительный dns-сервер, чтобы угодить регистраторам, которых я с тех пор перешел на использование <a href="http://www.easydns.com">easydns</a> для своих нужд dns. их веб-интерфейс прост в управлении и дает мне гибкость, необходимую для управления наборами rr. я также обнаружил, что с ним легче работать, чем с теми, которые предоставляются некоторыми хостинг-провайдерами, такими как <a href="http://1and1.com">1 & 1</a> , которые ограничивают доступные наборы rr, которые вы можете ввести, или даже регистраторами доменов, такими как <a href="http://www.networksolutions.com">сетевые решения</a> , который работает, только если вы используете windows для управления dns.</p>

<p>для моих личных доменов (и доменов некоторых друзей, с которыми я помогаю) мы размещаем собственный dns, а мой регистратор (gandi) предоставляет дополнительный dns. или друг в другой сети предоставляет вторичную. gandi не обновляет зоны немедленно, они, кажется, проверяют примерно каждые 24 часа или около того, но изменения происходят очень редко; работает достаточно хорошо для нас, и их сервер, вероятно, гораздо надежнее, чем наш.</p><p>на моей работе у нас есть собственный dns, а наш поставщик исходящей сети предоставляет вторичный dns. тем не менее, мы университет, и 99% наших пользователей находятся на месте; если локальная сеть не работает, не имеет значения, если dns не работает. кроме того, у нас есть полный класс-b (/ 16) с примерно 25 тыс. dns-записей (плюс 25 тыс. обратных dns-записей, конечно), что кажется немного неудобным для управления через веб-интерфейс. наши локальные dns-серверы являются высокодоступными и достаточно быстрыми.</p>

<p>я сделал оба. с хостингом у вас могут быть преимущества: вы определенно узнаете много нового о том, как работает dns, когда ваш начальник спрашивает вас, почему это так долго. кроме того, вы намного больше контролируете свои зоны. это не всегда так мощно, как следовало бы, во многом из-за иерархической распределенной природы dns - но время от времени это оказывается полезным. вдвойне, если вы можете заставить своего провайдера назначить вас как soa для обратного dns вашего блока ip, при условии, что он у вас есть.</p><p>тем не менее, все комментарии выше о том, как вы действительно должны иметь большую стойкость к отказам, встроены выше. серверы в разных дата-центрах в разных географических зонах очень важны. справившись с масштабным отключением электроэнергии на северо-востоке в 2003 году - мы все узнали, что наличие блока в двух разных центрах обработки данных в одном городе или даже провинции или штате - не обязательно является достаточной защитой. восторг, который возникает, когда вы понимаете, что ваши батареи, а затем дизельные генераторы спасли вашу задницу, быстро сменяется страхом, вызванным осознанием того, что вы сейчас едете на своем запасном колесе.</p><p>однако я всегда запускаю наш внутренний dns-сервер для локальной сети. может оказаться очень удобным иметь полный контроль над dns, который ваша сеть использует для внутреннего использования - и если в вашем офисе отключается питание, ваш внутренний dns-сервер в силу того, что он находится в серверной стойке, вероятно, работает от батареи или батареи и дизеля, в то время как ваш компьютер не будет - поэтому ваши клиенты будут в автономном режиме задолго до того, как сервер будет.</p>

<p>я читаю все эти решения с некоторым интересом, потому что нам удалось случайно вписаться во все эти "требования", разместив наш первичный dns на статической линии dsl, а регистратор (который находился на другом континенте) предоставил вторичный dns на гораздо более серьезное и надежное соединение. таким образом, мы получаем всю гибкость использования привязки и установки всех записей, в то же время будучи разумно уверенными, что вторичное устройство обновляется для отражения этих изменений и будет доступно в случае возгорания люка, чтобы сослаться на одно вхождение.</p><p>это эффективно выполняет:<br> "как минимум два авторитетных dns-сервера для вашего домена;"<br> "dns-серверы должны быть подключены к разным физическим сетям и источникам питания";<br> "dns-серверы должны находиться в разных географических зонах".</p>

<p>взгляните на <a href="http://www.dyn.com">dyn.com</a> ; у них есть всевозможные службы, связанные с dns, такие как dns-хостинг, динамический dns, mailhop и т. д., и т. д. я считаю их надежными и использую их, вероятно, 5 лет.</p>

<p>это зависит.</p><p>с конца 80-х годов я запускаю собственный dns для своих различных работ (bsd 4.3c). что касается работы, я всегда размещал свой собственный dns, но у меня всегда было несколько расположений центра обработки данных или я мог обмениваться дополнительным dns с партнером. например, на моей последней работе мы делали вторичный dns для другого .edu (они были в mn, мы в ca), и они сделали то же самое для нас. географическое и сетевое разнообразие.</p><p>или на моей нынешней работе у нас есть свои центры обработки данных на восточном и западном побережье (сша). размещение собственного dns позволяет нам помещать любые необычные записи dns, которые могут нам понадобиться (svr, txt и т.д.), которые могут не поддерживаться некоторыми службами dns с графическим интерфейсом. и мы можем изменить ttl, когда захотим; у нас есть в значительной степени предельная гибкость, за счет того, что мы делаем это сами.</p><p>для дома я сделал это обоими способами. для некоторых доменов, где я делаю необычные вещи или мне нужна большая гибкость, я по-прежнему использую свои собственные "скрытые" главные dns-серверы и обмениваюсь общедоступными службами dns с другими, которые делают то же самое. я использую rcs для файлов зон контроля версий для управления конфигурацией, поэтому я могу видеть всю историю изменений зон назад к началу времени. для простых вещей, таких как домен с одним блогом или общие веб-серверы (одна запись a или одна cname), проще использовать службу dns регистраторов доменов там, где она доступна, и теперь беспокоиться о cm.</p><p>это компромисс. максимальный контроль и гибкость достигается за счет самостоятельной обработки разнообразия, работы нескольких серверов, устранения сбоев аппаратного/программного обеспечения и т.д. если вам не нужна гибкость или полный контроль, то любой из ведущих поставщиков dns будет решить вашу проблему, вероятно, с меньшими затратами.</p>

<p>как уже упоминалось в этом потоке, существует несколько особых случаев с dns, наиболее существенное различие между авторизованным и кэширующим развертываниями серверов имен.</p><ol> <li> <p>если вам нужен dns-сервер только для разрешения интернет-ресурсов, разумным выбором может стать бесплатный распознаватель dns с кэшированием. я лично использую рекурсор powerdns (pdns-recursor) в linux.</p> </li> <li> <p>для обслуживания вашей внешней инфраструктуры, такой как веб-сайты или mx, я бы не использовал внутренние ns (если мы говорим о soho здесь). используйте хороший, надежный, пуленепробиваемый сервис, такой как <a href="http://www.dnsmadeeasy.com/u/43729">dnsmadeasy</a> . я использую их бизнес-пакет, и он потрясающий, будучи очень доступным.</p> </li> </ol>

<p><strong>должны ли мы размещать наши собственные серверы имен?</strong></p><p>да, <strong>и</strong> вам также следует использовать еще одного крупного стороннего поставщика dns. гибридное решение, вероятно, является самым безопасным долгосрочным подходом по нескольким причинам, особенно если вы являетесь предприятием, которое имеет какое-либо поместье sla или договорные требования к своим клиентам. тем более, если вы b2b.</p><p>если ваши главные dns-серверы (скрытые или публичные) являются вашим источником правды, то вы защищаете себя оперативно от привязки к конкретным возможностям поставщика. как только вы начнете использовать их отличные функции, выходящие за рамки базового dns, вы можете обнаружить, что переключение на другого провайдера или размещение собственного dns-сервера является проблематичным, поскольку теперь вам приходится копировать эти возможности. примерами могут служить проверки работоспособности сайта и аварийное переключение dns, которые предоставляют dyn и ultradns. эти функции великолепны, но их следует считать разовыми, а не зависимыми. эти функции также плохо воспроизводятся от поставщика к поставщику.</p><p>если у вас есть только сторонние поставщики, это может повлиять на ваше время безотказной работы, когда они подвергаются целевой ddos-атаке. если у вас есть только собственные dns-серверы, это может повлиять на время безотказной работы, если вы являетесь целью ddos-атаки.</p><p>если у вас есть один или несколько dns-провайдеров и ваши собственные распределенные dns-серверы, которые подчиняются скрытым основным dns-серверам, которые вы контролируете, то вы убедитесь, что вы не привязаны к конкретному поставщику и что вы всегда будете контролировать свои зоны, и что атаки должны уничтожить как ваши серверы, так и одного или нескольких крупных провайдеров, которые подчиняются вашим серверам. все, кроме этого, будет ухудшением обслуживания по сравнению с критическим отключением.</p><p>еще одно преимущество наличия собственных главных (в идеале скрытых, неопубликованных) серверов заключается в том, что вы можете создавать свои собственные api и обновлять их в соответствии со своими предпочтениями. с сторонними поставщиками dns вам нужно будет адаптироваться к их api. у каждого продавца есть свои; или в некоторых случаях просто имеет веб-интерфейс.</p><p>более того, если ваш мастер находится под вашим контролем, и у поставщика возникла проблема, то все ваши подчиненные серверы, которые все еще могут связаться с вашим мастером, получат обновления. это то, что вы захотите получить после того, как поняли, что наличие третьей стороны в качестве вашего мастера было ошибкой во время большого ddos-инцидента, и вы не можете изменить ни один из серверов у провайдеров, которые не подвергаются атакам.</p><p>с юридической точки зрения предотвращение блокировки поставщиков также может быть важно для вашего бизнеса. например, dyn потенциально покупается oracle. это дает им уникальную возможность собирать статистику dns по всем клиентам dyn. есть конкурентные аспекты этого, которые могут представлять правовой риск. тем не менее, я не юрист, поэтому вы должны проконсультироваться со своими юридическими и pr командами по этому вопросу.</p><p>есть много других аспектов этой темы, если мы хотим копаться в сорняках.</p><p><strong>[edit]</strong> если это только для небольшого личного/хобби-домена, то для двух виртуальных машин, которые не находятся в одном центре обработки данных друг с другом, достаточно запустить небольшой демон dns. я делаю это для своих личных доменов. мне было неясно, означает ли ваш домен бизнес или просто хобби. какие бы самые маленькие виртуальные машины вы не получили, их более чем достаточно. я использую rbldnsd для своих доменов; используя в моих записях очень высокое значение ttl), так как оно занимает 900 кб оперативной памяти и может справиться с любыми злоупотреблениями, с которыми сталкиваются люди.</p>

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

<p>у меня есть лучшее из обоих миров.</p><p>я размещаю свой общедоступный dns для своих веб-сайтов и свои записи mx "где-то еще". это надежно, это безопасно, это работает, я могу изменить это по желанию. я плачу за услугу, и я доволен стоимостью.</p><p>но дома я использую собственный кеширующий dns-сервер, а не полагаюсь на своего провайдера. у моего интернет-провайдера есть привычка терять dns, иметь медленный dns, недействительный dns, и иногда они хотят извращать dns, чтобы сбои приходили в места, которые, по их мнению, могут меня заинтересовать. меня не интересует использование dns моего провайдера. так что у меня есть свои кеширующие dns-серверы, и я делаю это сам. сначала было немного усилий для настройки (возможно, 2 часа), но она чистая и у меня надежный dns. раз в месяц задание cron опрашивает корневые серверы и обновляет таблицу подсказок. может быть, раз в год мне приходится с этим возиться, например, отправлять doubleclick.com на 127.0.0.1 или аналогичный. кроме этого, он не требует вмешательства и прекрасно работает.</p>

<p>если вы решили разместить свой собственный dns ради бога, имейте два dns-сервера на сайт. один для вашего внешнего dns, напрямую подключен к брандмауэру, чтобы мир мог вас найти. и отдельный внутри вашей сети для ваших внутренних dns.</p>

<p>я запускаю свой собственный dns с помощью bind на серверах linux. в настоящее время у меня есть четыре офиса в лондоне, майами, сан-хосе и сингапуре. прекрасно работает, и у меня есть полный контроль. стабильность центра обработки данных очень важна, поэтому я выбрал хорошие контроллеры домена для работы серверов (не зависящие от isp или какой-либо другой "неизвестной" инфраструктуры). я могу настроить dns-серверы и другие службы в любой точке мира, используя dc мирового класса, которые я выбираю на основе строгих критериев. надежный dns необходим для работы с электронной почтой и веб-сервисами.</p>

<p>я пока не могу комментировать, но я делаю то же самое, что и freiheit. мы запускаем наш основной dns здесь, в нашей dmz, и у нашего интернет-провайдера есть несколько подчиненных dns-серверов по всей стране, которые обновляются сразу после внесения изменений в основной dns.</p><p>это дает лучшее из обоих миров; немедленный контроль плюс резервирование.</p>

<p>у каждого подхода есть свои плюсы и минусы, но я определенно предпочитаю внутренний хостинг вашего dns. список вещей, на которые вы полагаетесь для базовых сетевых сервисов, если вы размещаете его снаружи, ошеломляет. генеральный директор может подумать, что разумно экономить деньги на dns-серверах за счет внешнего хостинга, но что он подумает, если не сможет получить свою электронную почту, если интернет-связь не работает?</p>

<p>исходя из опыта, если вы хотите привлечь атаку типа "отказ в обслуживании", разместите свой собственный dns. и ваш собственный сайт.</p><p>я верю в некоторые вещи, которые вы не должны делать сами. dns-хостинг является одним из них. как говорили многие люди, вам потребуются избыточные серверы, соединения и физические местоположения, и вы все равно не приблизитесь к отказоустойчивости даже небольших хостинговых компаний.</p><p>самым большим преимуществом размещения вашего собственного dns является то, что изменения могут быть внесены сразу. нужно сократить ваши ttl для предстоящей миграции? возможно, вы могли бы написать скрипт, который делает это на ваших собственных серверах; для размещенного dns вам может потребоваться войти в систему и вручную изменить записи, или, что еще хуже, позвонить провайдеру, пройти через 3 уровня поддержки, пока, наконец, не достигнете того, кто может записать dns, просто чтобы они сказали вам, что они отправят меняется через 2-3 дня.</p>

<p>я использовал zonedit или годы. это дешево (или бесплатно), и я добавил много записей cname, a, mx, txt, srv и других.</p>

<p>думайте о dns-хостинге как о основе ваших общественных услуг. в моем случае электронная почта имеет решающее значение для нашего бизнеса. если вы размещаете dns самостоятельно и ваше интернет-соединение прерывается, ваши записи dns могут устареть, что приведет к недоступности вашего домена.</p><p>так что в моем случае, если запись mx не может быть найдена для нашего домена, электронная почта отклоняется сразу.</p><p>итак, наш dns размещен снаружи.</p><p>если запись mx доступна, но наше интернет-соединение не работает, почта будет продолжать стоять в очереди на серверах, пытающихся отправить почту на наш домен.</p>

<h1>это зависит. ™</h1><p>я управлял своими собственными серверами и управлял доменами по крайней мере с 2002 года.</p><p>я часто использовал dns-сервер моего провайдера.</p><p>количество раз, когда мой сервер по моему ip был доступен, но мой dns не был, было слишком много.</p><p>вот мои военные истории:</p><ul> <li> <p>у одного провайдера yuge в москве (один из первых на базе vz) мои vps были в дешевом "недорогом" dc, но их dns были в премиальном состоянии dc с дорогостоящим трафиком, в двух разных/24 подсетях, <a href="http://cr.yp.to/djbdns/dot-ru.html">как того требовали некоторые tld в то время</a> . в какой-то момент произошел сбой (возможно, <a href="http://en.wikipedia.org/wiki/2005\_moscow\_power\_blackouts">перебои в подаче электроэнергии в 2005 году?</a> ), и их дорогой dc перешел в автономный режим, и мой сайт (все еще в москве, но в "ценном" округе колумбия) может быть доступен только по его ip-адресу.</p> <p>интересно, что даже перед любыми инцидентами я ясно помню, что делал <a href="http://mdoc.su/n/traceroute.8"><code>traceroute</code></a> и замечал одно и то же dc для обоих <code>ns1</code> а также <code>ns2</code> моего провайдера, попросив их перенести один из них в "мой" округ колумбия, также для гео-избыточности; они отклонили идею гео-избыточности, потому что серверы были уже в самой лучшей версии dc).</p> </li> <li> <p>у меня был другой провайдер (один из первых, основанный на ispsystem), у которого был один нс на месте, а другой за границей. короче говоря, вся установка была смехотворно глючной, и сервер "за границей" часто не поддерживал свои зоны, поэтому у моего домена была дополнительная точка отказа, и он был бы недоступен, даже если весь мой сервер по-прежнему работал нормально.</p> </li> <li> <p>у меня был регистратор, который управлял своей собственной сетью. это происходило время от времени, даже если мои внешние серверы работали. мой dns не работает.</p> </li> <li> <p>недавно я использовал несколько крупных облачных провайдеров для вторичного, где я сам управлял скрытым мастером. оба провайдера изменили свои настройки хотя бы один раз; никогда с публичными объявлениями; некоторые из моих доменов перестали разрешаться. случился и мой друг с одним из тех же провайдеров. <strong> <em> это чаще случается со сторонними сервисами, чем люди хотят публично допустить.</em> </strong></p> </li> </ul><p>короче говоря, <a href="http://cr.yp.to/djbdns/third-party.html">http://cr.yp.to/djbdns/third-party.html</a> абсолютно верно по теме.</p><p>расходы на использование сторонних dns часто не стоят преимуществ.</p><p>недостатки наличия стороннего dns часто незаслуженно игнорируются.</p><p>я бы сказал, что если ваш домен уже не использует сторонние сервисы (например, для интернета, почты, голоса или текста), то добавление сторонних dns почти всегда будет контрпродуктивным и ни в коем случае не является наилучшей практикой при любых обстоятельствах. ,.</p>