Это канонический вопрос о гео-избыточности DNS.

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

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

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

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

Я понимаю, что это считается лучшей практикой, но это действительно кажется бессмысленным!

Примечание: содержание спора, обратитесь к комментариям для обоих ответов. Обнаружены ошибки, и этот Q & A нуждается в капитальном ремонте.

Пока я удаляю согласие из этого ответа, пока состояние этого канонического вопроса и ответов не будет должным образом рассмотрено. (удаление этого ответа также приведет к удалению прикрепленных комментариев, что не подходит для IMO. Возможно, после обширного редактирования оно превратится в ответ сообщества вики).

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

Я понимаю, что это считается лучшей практикой, но это действительно кажется бессмысленным!

Это может показаться бессмысленным ... но на самом деле это не так!

Рекурсивные серверы очень хорошо запоминают, когда удаленные серверы не отвечают на запрос, особенно когда они повторяют попытки и до сих пор не видят ответа. Многие реализуют негативное кэширование этих сбоев связи и временно помещают не отвечающие на запросы серверы имен в поле штрафов на период времени не более пяти минут. В конце концов этот «штрафной» период истекает, и они возобновят связь. Если плохой запрос снова не проходит, они сразу возвращаются в поле, в противном случае он возвращается к нормальной работе.

Вот где мы сталкиваемся с единственной проблемой сервера имен:

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

Короче говоря, если вы используете один DNS-сервер (это включает использование одного и того же IP-адреса несколько раз в разных NSзаписях), это произойдет. Это также произойдет гораздо чаще, чем вы думаете, но проблема будет настолько спорадической, что шансы неудачи 1) сообщаться вам, 2) воспроизводиться и 3) привязываться к этой конкретной проблеме чрезвычайно близки к нуль. Они в значительной степени были равны нулю, если вы вошли в эти вопросы и ответы, не зная, как работает этот процесс, но, к счастью, этого не должно быть сейчас!

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

ОП спрашивает:

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

Отличный вопрос!

Лучший ответ дает профессор Дэниел Дж. Бернштейн, доктор философии Беркли , который является не только всемирно известным исследователем, ученым и криптологом, но также написал очень популярный и хорошо принятый набор DNS, известный как DJBDNS ( последний выпущен в 2001- 02-11 , до сих пор популярны по сей день).

http://cr.yp.to/djbdns/third-party.html (2003-01-11)

Стоимость и преимущества стороннего сервиса DNS

Обратите внимание на эту короткую и краткую часть:

Ошибочные аргументы для сторонней службы DNS

...

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

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

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

Любое программное обеспечение, которое свободно реализует консервативное руководство в течение 5 минут, начиная с RFC 1998-03 и заканчивая сбоями в кеше, просто разбито по дизайну, и наличие дополнительного гео-избыточного сервера не помешает.

Фактически, согласно Как долго тайм-аут DNS кэшируется? в BIND SERVFAILусловие традиционно НЕ кэшировалось вообще до 2014 года, а с 2015 года по умолчанию кэшируется всего на 1 секунду , что меньше, чем обычному пользователю, чтобы достичь тайм-аута решателя и снова нажать эту кнопку «Обновить». ,

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

Более того, разработчики BIND даже установили потолок для этой функции, составляющий всего 30 с, который даже в качестве потолка (например, максимальное значение, которое функция когда-либо примет), уже в 10 раз ниже, чем предложение 5 мин (300 с). от RFC, гарантируя, что даже самые благие намерения администраторов (пользователей глазного яблока) не смогут стрелять в ноги своих собственных пользователей.

Кроме того, есть много причин, по которым вы можете не захотеть запускать стороннюю службу DNS - прочитайте djbdns/third-party.htmlвсе подробности , а аренда крошечного дополнительного сервера только для DNS для самостоятельного администрирования вряд ли оправдана, когда в этом нет необходимости. кроме BCP 16 существует для такого усилия.

По моему личному «анекдотическому» опыту владения и настройки доменных имен, по крайней мере, с 2002 года, я могу сказать вам со всей уверенностью и честностью, что у меня на самом деле было значительное время простоя моих различных доменов из-за профессионально управляемого сторонние серверы моих регистраторов и хостинг-провайдеров , у которых по одному провайдеру за все годы и за все годы были все их инциденты, были недоступны, без необходимости отключали мои домены, в то же самое время, когда мой собственный IP-адрес (где HTTP и SMTP для данного домена был размещен с) был полностью доступен в противном случае. Обратите внимание, что эти сбои произошли с несколькими независимыми, уважаемыми и профессионально управляемыми поставщиками, и они ни в коем случае не являются изолированными инцидентами, и происходят на ежегодной основе, и, как сторонняя служба,полностью вне вашего контроля ; Просто так получилось, что мало кто когда-либо говорил об этом в долгосрочной перспективе.

Короче:

Для небольших сайтов гео-избыточный DNS совершенно не нужен.

Если вы запускаете все свои службы с одного и того же IP-адреса , добавление второго DNS, скорее всего, приведет к дополнительной точке отказа и отрицательно скажется на постоянной доступности вашего домена. «Мудрость» того , чтобы всегда делать это в любой мыслимой ситуации, на самом деле является очень популярным мифом; Разорен.

Конечно, совет будет совершенно другим, если некоторые службы домена, будь то веб (HTTP / HTTPS), почта (SMTP / IMAP) или голосовая / текстовая (SIP / XMPP), уже обслуживаются сторонней организацией. провайдеры, и в этом случае исключение вашего собственного IP-адреса как единой точки отказа действительно было бы очень мудрым подходом, и гео-избыточность действительно была бы очень полезна.

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