Примечание: содержание спора, обратитесь к комментариям для обоих ответов. Обнаружены ошибки, и этот 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, скорее всего, приведет к дополнительной точке отказа и отрицательно скажется на постоянной доступности вашего домена. "Мудрость" того, чтобы всегда делать это в любой мыслимой ситуации, на самом деле является очень популярным мифом; BUSTED.

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

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