Чи можливо мати вторинного керованого постачальника DNS для швидкого делегування, коли трапляється атака DDOS на наш * основний * зовнішній постачальник DNS?

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

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

тобто якщо у вас є відключення DNS (через DDOS, у цьому прикладі), який триває більше, ніж, скажімо, 1 година, делегуйте все вторинному постачальнику.

Що люди роблять там, коли мова йде про їх зовнішній DNS та використання іншого керованого постачальника DNS як резервного копіювання?

Зверніть увагу на наших доброзичливих модераторів: це питання набагато конкретніше, ніж питання "" загальної пом’якшення DDOS-атаки ".

EDIT: 2016-05-18 (Через кілька днів): Отже, спочатку дякую AndrewB за відмінну відповідь. Я маю ще додати інформацію тут:

Тож ми звернулися до іншого постачальника послуг DNS і поспілкувались з ними. Поміркувавши і провівши трохи більше досліджень, це насправді багато складніше, ніж я думав пройти з двома постачальниками DNS. Це не нова відповідь, це фактично більше м’яса / інформації на питання! Ось моє розуміння:

- Багато цих постачальників DNS пропонують власні функції, такі як "інтелектуальний DNS", наприклад, балансування навантаження DNS за допомогою ключів, логічні ланцюги для налаштування передачі відповідей (на основі географічного розташування, різного ваги для записів тощо). . Тому першим завданням є синхронізація двох керованих провайдерів . І обох керованих провайдерів доведеться синхронізувати замовник, який повинен автоматизувати взаємодію зі своїми API. Не ракетна наука, а постійні експлуатаційні витрати, які можуть бути болісними (враховуючи зміни з обох сторін щодо функцій та API).

- Але ось доповнення до мого питання. Скажімо, хтось користувався двома керованими провайдерами відповідно до відповіді AndrewB. Чи правильно я вважаю, що тут немає «первинного» та «вторинного» DNS за специфікацією? Тобто, ви реєструєте свої чотири IP-адреси сервера DNS у вашому реєстраторі домену, два з них є одним з ваших DNS-провайдерів, два з них - сервери DNS іншого. Таким чином, ви б по суті просто показували світові свої чотири NS-записи, які є "первинними". Отже, чи є відповідь на моє запитання «Ні»?

Спочатку давайте розглянемо питання в заголовку.

Чи можна мати вторинного керованого постачальника DNS для швидкого делегування

"Швидке" та "делегування" не належать до одного речення разом, коли ми говоримо про делегування у верхній частині домену. Сервери імен, керовані реєстрами домену верхнього рівня (TLD), зазвичай обслуговують реферали, які мають TTL, виміряні в днях. Авторитетні NSзаписи, що живуть на ваших серверах, можуть мати нижчі TTL, які в кінцевому підсумку замінюють TLD-реферали, але ви не маєте контролю над тим, як часто компанії в Інтернеті вирішують скинути весь кеш або перезапустити свої сервери.

Спрощуючи це, найкраще припустити, що для того, щоб змінити сервер імен для верхньої частини вашого домену, буде потрібно мінімум 24 години. Оскільки верхня частина вашого домену є найслабшою ланкою, саме це потрібно планувати навколо.

Які існують варіанти зменшення залежності від єдиного зовнішнього керованого постачальника DNS?

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

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

Для більшості людей варіант №1 є найбезпечнішим варіантом. Перебої можуть траплятися лише раз на кілька років, і якщо напад трапиться, його вирішать люди, які мають більше досвіду та ресурсів для вирішення проблеми.

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

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

Вартість найнадійнішої форми наявності сервера DNS, на жаль, є більшою складністю. Зараз ваші проблеми набагато частіше є наслідком проблем, через які ці сервери не синхронізуються. Зміни брандмауера та маршрутизації, які порушують передачу зони, є найпоширенішими проблемами. Гірше, якщо проблема з передачею зон залишається непоміченою протягом тривалого періоду часу, SOAможе бути досягнуто таймер закінчення терміну дії, визначений вашою записом, і віддалені сервери повністю скинуть зону. Тут знайомий ваш широкий моніторинг.

Щоб завершити все це, існує ряд варіантів, і кожен має свої недоліки. Ви вирішуєте збалансувати надійність та відповідні компроміси.

• Для більшості достатньо, щоб ваш DNS розмістився з компанією, яка має велику репутацію для боротьби з DDoS-атаками ... ризик знизитися один раз на кілька років є досить хорошим для простоти.
• Компанія з менш репутаційною залізом для боротьби з DDoS-атаками є другим найпоширенішим варіантом, особливо коли шукає вільних рішень. Пам'ятайте лише, що безкоштовний звичайно не означає гарантії укладання угоди про укладання договору, і якщо проблема трапиться, у вас не буде можливості невідкладно реагувати на цю компанію. (або особу, яка подає до суду, якщо ваш юридичний департамент вимагає такого роду)
• Найменш поширений варіант - це, як не дивно, найбільш надійний варіант використання декількох DNS хостинг-компаній. Це пов'язано з вартістю, трудомісткістю та сприйняттю довгострокових вигод.
• Найгірше, принаймні, на мою думку, - вирішити влаштувати своє. Небагато компаній зазнали, що адміністратори DNS (які мають меншу ймовірність виникнення аварійних відключень), досвід та ресурси для боротьби з DDoS-атаками, готовність інвестувати в дизайн, що відповідає критеріям, визначеним BCP 16 , та в більшості сценаріїв - комбінація всіх трьох. Якщо ви хочете пограти з авторитетними серверами, які стикаються лише з внутрішньою стороною вашої компанії, це одне, але DNS з інтернетом - це зовсім інша кульова гра.

Очевидно, що постачальник послуг DNS повинен зробити, і багато іншого, що вони могли зробити, щоб гарантувати максимально надійну послугу.

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

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

Що для цього потрібно вирішити, це, по суті, просто підтримувати синхронізацію даних про зони між серверами імен цих різних постачальників.

Класичним рішенням цього було б просто використовувати функцію передачі на майстер / підлеглий зони, що є частиною самого протоколу DNS (для цього, очевидно, потрібні сервіси, які дозволяють використовувати ці засоби), або будь-який з постачальників послуг буде майстер або можливо запуск власного основного сервера.