Возможно ли иметь вторичного управляемого DNS-провайдера для быстрого делегирования, когда происходит DDOS-атака на нашего * основного * внешнего DNS-провайдера?

Поэтому наш DNS-провайдер время от времени сталкивается с DDOS-атаками на свои системы, что приводит к отключению наших веб-сайтов.

Какие есть варианты с точки зрения уменьшения зависимости от ОДНОГО внешнего управляемого DNS-провайдера? Моей первой мыслью было использование TTL с меньшим сроком действия и других TTL SOA, но мне кажется, что они влияют на поведение вторичного DNS-сервера больше, чем что-либо еще.

т.е. если вы испытываете перебои в работе DNS (из-за DDOS, в данном примере), которая длится, скажем, более 1 часа, делегируйте все вторичному провайдеру.

Что люди делают там, когда дело доходит до их внешнего DNS и использования другого управляемого поставщика DNS в качестве резервного?

Примечание для наших дружественных модераторов: этот вопрос гораздо более конкретен, чем вопросы «общей атаки на DDOS».

РЕДАКТИРОВАТЬ: 2016-05-18 (несколько дней спустя): Итак, прежде всего спасибо AndrewB за отличный ответ. У меня есть еще немного информации, чтобы добавить здесь:

Поэтому мы обратились к другому поставщику услуг DNS и пообщались с ними. Подумав и проведя немного больше исследований, на самом деле это намного сложнее, чем я думал, чтобы пойти с двумя провайдерами DNS. Это не новый ответ, это на самом деле больше мяса / информации на вопрос! Вот мое понимание:

- Многие из этих провайдеров DNS предлагают собственные функции, такие как «интеллектуальный DNS», например, балансировка нагрузки на DNS с помощью keepalive, логические цепочки для настройки способа отправки ответов (в зависимости от географического местоположения, различных весов для записей и т. Д. И т. Д.) , Таким образом, первая задача заключается в синхронизации двух управляемых провайдеров . И два управляемых провайдера должны быть синхронизированы клиентом, который должен автоматизировать взаимодействие со своими API. Не ракетостроение, а текущие эксплуатационные расходы, которые могут быть болезненными (учитывая изменения с обеих сторон в плане функций и API).

- Но вот дополнение к моему вопросу. Допустим, кто-то действительно использовал двух управляемых провайдеров согласно ответу AndrewB. Я прав в том, что здесь нет «первичного» и «вторичного» DNS согласно спецификации? То есть вы регистрируете свои четыре IP-адреса DNS-сервера у своего регистратора доменов, два из них являются одним из ваших DNS-провайдеров, два из них являются DNS-серверами другого. Таким образом, вы, по сути, просто покажете миру свои четыре записи NS, все из которых являются «первичными». Итак, ответ на мой вопрос "Нет"?

Во-первых, давайте обратимся к вопросу в заголовке.

Возможно ли иметь вторичного управляемого поставщика DNS для быстрого делегирования

«Быстрое» и «делегирование» не принадлежат одному и тому же предложению, когда мы говорим о делегировании для верхней части домена. Серверы имен, управляемые реестрами доменов верхнего уровня (TLD), обычно обслуживают рефералов, у которых TTL измеряются в днях. Официальные NSзаписи, которые хранятся на ваших серверах, могут иметь более низкие TTL, которые в конечном итоге заменяют рефералов TLD, но вы не можете контролировать, как часто компании в Интернете выбирают удаление всего кэша или перезапуск своих серверов.

Чтобы упростить это, лучше всего предположить, что интернету потребуется не менее 24 часов, чтобы подобрать смену сервера имен для верхней части вашего домена. Так как верх вашего домена является самым слабым звеном, это то, что вы должны планировать больше всего.

Какие есть варианты с точки зрения уменьшения зависимости от ОДНОГО внешнего управляемого DNS-провайдера?

Этот вопрос гораздо более решаем, и, вопреки распространенному мнению, ответ не всегда «найти лучшего поставщика». Даже если вы используете компанию с очень хорошим послужным списком, последние годы показали, что никто не является непогрешимым, даже Neustar.

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

Для большинства людей вариант № 1 является самым безопасным вариантом. Отключение может происходить только раз в несколько лет, и если атака все же произойдет, с ней будут бороться люди, которые имеют больше опыта и ресурсов для решения этой проблемы.

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

В качестве аргумента давайте предположим, что у вашей нынешней DNS-хостинговой компании есть два сервера имен. Если вы добавите в сервер два сервера имен, управляемых другой компанией, тогда потребуется DDoS против двух разных компаний, чтобы вывести вас в автономный режим. Это защитит вас даже от редкого случая, когда такой гигант, как Нойстар, вздремнет. Вместо этого задача состоит в том, чтобы найти способ надежной и последовательной доставки обновлений для ваших зон DNS более чем одной компании. Как правило, это означает наличие скрытого мастера, подключенного к Интернету, который позволяет удаленному партнеру выполнять передачу зон на основе ключей. Конечно, возможны и другие решения, но я лично не фанат использования DDNS для выполнения этого требования.

Стоимость самой надежной формы доступности DNS-сервера, к сожалению, сложнее. Ваши проблемы теперь, скорее всего, являются результатом проблем, которые приводят к несинхронизации этих серверов. Изменения межсетевого экрана и маршрутизации, которые нарушают передачу зон, являются наиболее распространенными проблемами. Хуже того, если проблема передачи зоны остается незамеченной в течение длительного периода времени, таймер истечения, определенный вашей SOAзаписью, может быть достигнут, и удаленные серверы полностью удалят зону. Обширный мониторинг ваш друг здесь.

Чтобы обернуть все это, есть несколько вариантов, и у каждого есть свои недостатки. Вы должны сбалансировать надежность с соответствующими компромиссами.

• Для большинства достаточно, чтобы ваш DNS был размещен в компании, которая имеет хорошую репутацию для борьбы с DDoS-атаками ... риск простоя раз в несколько лет достаточно для простоты.
• Компания с менее железной репутацией, занимающаяся DDoS-атаками, является вторым наиболее распространенным вариантом, особенно когда ищут бесплатные решения. Просто помните, что бесплатное обычно означает отсутствие гарантии SLA, и если проблема все-таки случится, у вас не будет возможности срочно с этой компанией. (или лицо, подающее иск, если ваш юридический отдел требует такого рода вещей)
• По иронии судьбы, наименее распространенным вариантом является наиболее надежный вариант использования нескольких DNS-хостинговых компаний. Это связано с затратами, сложностью эксплуатации и предполагаемыми долгосрочными преимуществами.
• Самое худшее, по крайней мере, на мой взгляд, это принять собственное решение. Лишь немногие компании имеют опытных администраторов DNS (которые с меньшей вероятностью могут вызвать случайные сбои), опыт и ресурсы для борьбы с DDoS-атаками, желание инвестировать в проект, соответствующий критериям, изложенным в BCP 16 , и в большинстве сценариев комбинацию всех трех. Если вы хотите поиграть с авторитетными серверами, которые работают только внутри вашей компании, это одно, а DNS в Интернете - совершенно другая игра в мяч.

Совершенно очевидно, что поставщик услуг DNS должен сделать и многое другое, что он может сделать, чтобы обеспечить максимальную надежность службы.

Если кажется, что у поставщика услуг есть неоправданные проблемы, то, вероятно, имеет смысл рассмотреть их замену в целом, но есть также классы или проблемы, в которых использование отдельно управляемых услуг само по себе полезно.

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

Чтобы это работало, нужно просто синхронизировать данные зоны между серверами имен этих разных провайдеров.

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