Pull to refresh

Сбой в DNS у регистратора R01 и несколько роковых случайностей

Reading time2 min
Views30K
Сегодня один из старейших регистраторов R01 объявил о сбое в DNS.
В связи с этим хочу рассказать вам маленькую поучительную историю о том, как это едва не убило нашу компанию.

По роду деятельности мы saas-аналитика для веба. Наше основное оружие — javascript файл, который собирает статистику. Файл раздается на множество сайтов наших пользователей, поэтому мы обязаны обеспечить его безупречную стабильность, недоступность нашего сайта не должна никак влиять на сайты наших клиентов. И мы потратили много сил на то чтобы обеспечить полную стабильность: положили скрипт в отличный мощный CDN, сделали свой домен, чтобы абстрагировать этот CDN (чтобы можно было в любой момент сменить CDN, если он даст сбой или станет слишком дорогим). Но не учли одну мелочь: DNS-сервер находился у регистратора.

Сбой в DNS у R01 заключался в том, что все домены резолвились в один конкретный IP-адрес, который на HTTP-запросы показывал обычную страницу «парковки» домена с рекламой. Либо не показывал ничего, потому что на этот IP пришлась спонтанная DoS атака от всех людей, которые пытались зайти на привычные сайты, которые держали DNS у R01. Но только не в нашем случае. На запросы /somescript.js сервер отвечает скриптом. И не просто скриптом, а динамически сгенерированным, вот таким:

var redir_url = 'http://домен, который резолвился в роковой IP/';
if (window != top) {
top.location.href = redir_url;
} else {
window.location = redir_url;
}


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

Частично спасло нас только то, что почти все время сервер, который отзывался по тому IP, находился под DDoS из-за количества запросов к нему, из-за чего у подавляющего большинства пользователей запросы к нашему скрипту отваливались по таймауту (в случае недоступности скрипта мы, разумеется, никак не влияем на чужие сайты). Но те доли процента, которым «посчастливилось» получить ответ от сервера, получали редирект.

Роковое стечение обстоятельств, как это часто бывает, едва не стоило нам 2 лет работы проекта. Просто недоступный DNS; доступный DNS, который направляет запросы на недоступный сервер; доступный DNS + доступный сервер, но который не отвечает скриптом на запросы к скриптам; все предыдущее, но скрипт, который не делает редиректа — это все помогло бы избежать катастрофического эффекта на сайты наших пользователей. Не знаю, сумеем ли мы выкарабкаться после такого удара по нашему сервису, но многие клиенты, конечно же, заметили жалобы своих пользователей на непонятные редиректы. Да и мы не скрывали, тут же провели email-рассылку с просьбой отключить наш сервис до тех пор, пока не обновится кэш DNS по всему миру.

Мораль истории проста: невозможно предусмотреть все, и даже таким надежным и привычным вещам, как DNS-сервера, доверять нельзя.

Крайне сложно было предусмотреть такую ситуацию: слишком многое сложилось не в нашу пользу. Конечно же мы сменим провайдера DNS, и даже поставим свои сервера, если это будет надежнее. Но сломаться может и DNS, и CDN, все что угодно. Единственное, что можно сделать, чтобы минимизировать шанс влететь так же сильно, как мы: убедиться что в каждой точке вашей системы использовано лучшее, самое надежное из возможных решений. Даже если это выбор DNS-сервера или регистратора.
Tags:
Hubs:
Total votes 66: ↑59 and ↓7+52
Comments49

Articles