Це канонічне запитання про надмірність геоданих DNS.

Надзвичайно загальновідомо, що гео-надлишкові DNS-сервери, розташовані в окремих фізичних місцях, дуже бажані при наданні еластичних веб-служб. Це детально висвітлюється документом BCP 16 , але деякі з найбільш часто згадуваних причин включають:

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

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

Це все добре і добре, але чи потрібні надмірні сервери DNS, якщо я запускаю всі свої сервіси з однієї і тієї ж IP адреси? Я не бачу, як наявність другого сервера DNS принесе мені будь-яку користь, якщо ніхто не зможе дістатись до чогось, що надається моїм доменом.

Я розумію, що це вважається найкращою практикою, але це справді здається безглуздим!

Примітка. Вміст, який суперечить, див. Коментарі для обох відповідей. Виявлені помилки, і це питання потребує капітального ремонту.

Я поки що знімаю прийом з цієї відповіді, поки стан цього канонічного запитання не буде належним чином вирішено. (видалення цієї відповіді також видалить додані коментарі. Це не спосіб перейти до 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) вже обслуговуються сторонніми сторонами постачальників, і в такому випадку усунення власного ІС як єдиного пункту відмови справді було б дуже мудрим підходом, і геовідміщення справді було б дуже корисним.

Так само, якщо ви маєте особливо популярний сайт з мільйонами відвідувачів і свідомо вимагаєте додаткової гнучкості та захисту геоданих DNS відповідно до BCP 16, то… Ви, мабуть, не використовуєте жодного сервера / сайту для веб / пошти / голос / текст уже, тому це питання та відповідь, очевидно, не стосуються. Удачі!