Давайте поговорим о DNS. В конце концов, что может пойти не так? Это просто инвалидация кеша и название переменной.
Это наш очередной перевод. Он длинный, но интересный. Оригинал доступен по адресу http://blog.serverfault.com/2017/01/09/surviving-the-next-dns-attack/
Много букв
Этот пост про то, как StackOverflow и вся остальная сеть StackExchange подходит к организации DNS:
- Оценивая различные DNS-провайдеры и выбирая между ними
- Внедряя несколько DNS провайдеров
- Преднамеренно ломая DNS чтобы оценить последствия
- Проверяя наши предположения и тестируя реализации DNS стандарта
Хороший материал в этом посте находится посередине, так что не стесняйтесь прокручивать вниз до «атака на Dyn», если вы хотите попасть прямо в кровь и кишки этого поста.
Система доменных имен
DNS был в центре внимания в октябре 2016 года, когда была развернута серьезная DDos атака против Dyn, сделав недоступными, такие ресурсы как Twitter, CNN, imgur, Spotify и буквально тысячи других сайтов.
Но для большинства системных администраторов или веб операторов DNS в основном хранится в небольшом черном ящике, который обычно передан на аутсорс третьей стороне и в большинстве случаев успешно забыт. И, по большей части, так и должно быть. Но по мере того как вы начинаете расти до 1,3 + миллиарда просмотров страниц в месяц с веб-сайтом, где производительность — это фича, каждая мелочь имеет значение.
В этой статье я объясню некоторые решения, которые мы сделали вокруг DNS в прошлом, и о том что мы собираемся улучшить в будущем. Я буду избегать глубоких технических подробностей и замалчивать реализацию DNS на низком уровне в пользу широких штрихов.
В начале
Для начала чуть чуть истории. В начале пути мы запустили свои собственные DNS c собранными вручную файлами конфигурации для BIND. Это было достаточно быстро, когда у нас было всего несколько сотен миллионов посещений в месяц, но в конечном итоге это было слишком сложно для надежной поддержки. Когда мы перешли в Cloudflare в качестве нашего CDN, их сервис был тесно связан с DNS, поэтому мы выключили наши боксы с BIND и передали DNS Cloudflare.
Поиск нового провайдера
Перенесемся в начало 2016 года где мы перенесли наш CDN на Fastly. Fastly не предоставлял DNS, поэтому мы вернулись обратно и начался наш поиск нового DNS-провайдера. Мы составили список каждого DNS-провайдера, о котором мы могли вспомнить, и закончили с кратким списком из 10:
- Dyn
- NS1
- Amazon Route 53
- Google Cloud DNS
- Azure DNS (beta)
- DNSimple
- Godaddy
- EdgeCast (Verizon)
- Hurricane Electric
- DNS Made Easy
Из этого списка из 10 провайдеров мы провели первоначальное расследование их предложений по услугам и начали устранять службы, которые либо не соответствовали нашим потребностям, либо были чрезмерно дорогими, либо имели недостаточный SLA, либо не предлагали требуемые услуги (такие как полнофункциональный API). Затем мы начали тестирование производительности. Мы сделали это, разместив скрытый iFrame на 5% посетителей сайта stackoverflow.com, который создавал запрос к любому другому DNS провайдеру. Мы делали это для каждого провайдера, пока у нас не было довольно солидных показателей производительности.
Используя базовую аналитику, мы смогли измерить реальную производительность, наблюдаемую нашими реальными пользователями, с разбивкой по географическим регионам. На основе этих тестов мы построили несколько графиков, которые позволили нам визуализировать поведение каждого провайдера.
Если вы не знаете, как толковать boxplot, вот краткое руководство для вас. Для ботаников данных они были созданы с помощью стандартных функций boxplot языка R, что означает, что верхний и нижний фитиль(whiskers) min (max (x), Q_3 + 1,5 * IQR) и max (min (x), Q_1–1,5 * IQR), Где IQR = Q_3 — Q_1
Это результаты наших тестов, для пользователей в США:
Вы можете видеть, что у Hurricane Electric четверть запросов отработали за 16 мс и медиана в 32 мс, причем три «облачных» провайдера (Azure, Google Cloud DNS и Route 53) были немного медленнее (около 24 мс первой четверти и 45 мс медианы ), А DNS Made Easy — на втором месте (20 мсек в первой четверти, медиана — 39 мсек).
Вы можете удивиться, почему шкала на этом графике идет вплоть до 700 мс, когда значения не такие высокие. Это связано с тем, что у нас есть мировая аудитория, поэтому просто смотреть на данные из США недостаточно. Если мы посмотрим на данные из Новой Зеландии, мы увидим совсем другую историю:
Здесь вы можете видеть, что Route 53, DNS Made Easy и Azure у всех хорошие показатели в 1-й четверти, но у Hurricane Electric и Google очень плохие. Попытайтесь запомнить это, поскольку это будет очень важным позже.
У нас также есть Stack Overflow на португальском, поэтому давайте посмотрим на производительность из Бразилии:
Здесь мы видим, что Hurricane Electric, Route 53 и Azure в фаворитах, а Google и DNS Made Easy медленные.
Итак, как вы решаете, какой провайдер DNS выбрать, если ваша главная цель — производительность? Это сложно, потому что независимо от того, кого вы выбираете, вы будете выбирать поставщика, который является неоптимальным для части вашей аудитории.
Вы знаете, что было бы портясающим? Если бы у нас было два DNS-провайдера, каждый из которых обслуживал бы те области, где у них лучшие результаты! К счастью, это то, что можно реализовать с помощью DNS. Тем не менее, времени было мало, поэтому нам пришлось отложить дизайн двойного провайдера, и на данный момент у нас есть только один провайдер.
Наше первоначальное внедрение DNS было на Amazon Route 53 в качестве нашего провайдера: у них были приемлемые показатели производительности во многих регионах и была очень эффективная оценка (на этой ноте Route 53, Azure DNS и Google Cloud DNS — все одинаково оценены для базового DNS-сервиса).
Атака на Dyn
Перенесемся до октября 2016 года. Route 53 оказался стабильным, быстрым и экономичным DNS-провайдером. Мы по-прежнему имели два DNS-провайдера в идеях для реализации, но, как и многие хорошие идеи, они были поставлены на задний план, так как у нас не было времени. Затем Интернет упал. DNS-провайдер Dyn подвергся атаке, выбив из Интернета большое количество авторитетных DNS-серверов, что вызвало многочисленные проблемы с подключением к основным веб-сайтам. Внезапно DNS снова привлек наше внимание. Stack Overflow и Stack Exchange не пострадали от сбоя Dyn, но это была чистая удача.
Мы знали, что если DDoS такого масштаба случится с нашим DNS-провайдером, то решение состояло бы в том, чтобы иметь двух полностью независимых DNS-провайдеров. Таким образом, если один провайдер положат, у нас все еще есть полностью функционирующий второй провайдер, который может забрать нагрузку. Но остались еще вопросы, на которые нужно ответить, и предположения, которые необходимо подтвердить:
- Какая будет производительность для наших пользователей, когда у нас будет несколько DNS провайдеров, когда оба провайдера работают правильно?
- Какая будет производительность и влияние на наших пользователей, если один из поставщиков не работает?
- Какое максимальное количество серверов имен будет использоваться?
- Как синхронизировать данные между двумя DNS-провайдерами?
Это были довольно серьезные вопросы — некоторые из них были гипотезами, которые нужно было проверить, и другие, на которые были даны ответы в стандартах DNS, но по опыту мы знаем, что поставщики DNS не всегда соблюдают стандарты DNS.
Какая будет производительность для наших пользователей, когда у нас будет несколько DNS провайдеров, когда оба провайдера работают правильно?
Это должно быть достаточно легко проверить. Мы уже сделали это один раз, так что давайте просто сделаем это снова. Мы запустили наши тесты, как и в начале 2016 года, но на этот раз мы указали двух поставщиков DNS:
- Route 53 & Google Cloud
- Route 53 & Azure DNS
- Route 53 & наш внутренний DNS
Мы сделали это простым перечислением серверов имен от обоих провайдеров в админ-панели нашего регистратора (и, очевидно, мы установили одни и те же записи в зонах для обоих провайдеров).
Использовать Route 53 и Google или Azure был довольно здраво — Google и Azure неплохо покрывали регионы, в которых плохо работал Route 53. По цене Route 53 был таким же, что упростило бы прогнозирование бюджета. В качестве третьего варианта мы решили посмотреть, что произойдет, если мы возьмем локальные серверы BIND и вернем их в качестве одного из провайдеров. Давайте посмотрим на данные по трем регионам: США, Новая Зеландия и Бразилия:
США
Новая зеландия
Бразилия
Вероятно, есть одна вещь, которую вы сразу заметите из этих графиков, но есть и другое, не столь очевидное изменение:
- Тут нет azure :(
- В третьем квартале мы стали заметно медленнее(не столь очевидно)
Azure
Azure имеет фатальный недостаток в их коммерческом предложении, начиная с записи в их блоге. Они не позволяют изменять записи NS в начале вашей зоны:
Вы не можете добавлять, удалять или изменять записи в автоматически созданной записи NS, установленной в начале зоны (имя = “@”). Единственное изменение, которое разрешено, — изменить установленный TTL записи.
NS записи — это авторитетные сервера для данного домена. Очень важно, чтобы они были точными и правильными, потому что они будут кэшироваться клиентами и DNS резолверами.
Не вдаваясь в подробности о том, как работает кэширование DNS и NS-записи (мне потребуется еще 2500 слов, чтобы описать это подробно), произойдет следующее: тот DNS сервер, с которым вы связались в первый раз, будет единственным поставщиком для вас, пока не истечет срок действия вашего кеша. Если вы в первый раз пошли на Azure, то будут использоваться только серверы Azure. При использовании нескольких DNS провайдеров это наносит ущерб этой идее, потому что если провайдер, который у вас закешировался уйдет в оффлайн, то у вас есть 50:50 шанс, что у вас не будет другого DNS, провайдера.
Таким образом, пока Azure не добавит возможности изменять записи NS, они нам не подходят.
Третья четверть
Третья четверть показывает влияние сетевых задержек на DNS. Вы заметите, что в результатах для ExDNS (это внутреннее имя для наших локальных серверов BIND) графики намного выше, чем другие. Это происходит потому, что эти серверы расположены в Нью-Джерси и Колорадо — далеко, далеко от того места, откуда прибывает большинство наших посетителей. Как и ожидалось, служба с двумя точками присутствия в одной стране (в отличие от десятков во всем мире) работает очень плохо для многих пользователей.
Выводы по результатам
Таким образом, наши выборы были ограничены для нас Route 53 и Google Cloud, потому что у Azure нет возможности изменять важные записи NS. К счастью, у нас есть данные, подтверждающие тот факт, что Route 53 в сочетании с Google является очень приемлемой комбинацией.
Помните раньше, когда я сказал, что важна производительность в Новой Зеландии? Потому, что Route 53 работает хорошо, но Google Cloud работает плохо в этом регионе. Но взгляните на график снова. Не прокручивайте вверх, я покажу вам еще один график:
Посмотрите, как Google очень плохо работал в Новой Зеландии (его первая четверть — 164 мс против 27 мс для Route 53)? Однако, когда вы объединяете Google и Route 53 вместе, производительность в основном остается такой же, как наRoute 53.
Почему это? Потому что есть техника Smooth Round Trip Time. Вообще DNS-резолверы (а именно определенная версия BIND и PowerDNS) отслеживают, какие DNS-серверы реагируют быстрее, и взвешивать запросы к этим DNS-серверам. Это означает, что более быстрый провайдер должен быть перекошен чаще, чем более медленные. Здесь есть отличная презентация, если вы хотите узнать больше об этом. В кратце, если у вас много DNS-серверов, кеш-серверы DNS будут использовать их. В результате, если один провайдер быстр в Окленде, но медленный в Лондоне, а другой провайдер — наоборот, сервера DNS в Окленде будут отдавать предпочтение первому провайдеру, а в Лондоне будут отдавать предпочтение другому. Это очень малоизвестная особенность современных DNS-серверов, но наше тестирование показывает, что достаточное количество ISP поддерживают его, и мы уверены, что можем на них положиться.
Какая производительность, если один из провайдеров отключен?
Здесь очень удобно использовать локальные DNS-серверы. Мы решили отправить часть пользователей на наши локальные сервера, получить базовые замеры, затем положить один из серверов и снова запустить замеры. Мы также можем измерять в нескольких местах: замеры, которые зарепорчены нашими пользователями (какой на самом деле был пользовательский опыт), и мы можем посмотреть данные из нашей сети, чтобы увидеть, что на самом деле произошло. Для анализа сети мы обратились к инструменту анализа сети ExtraHop, которому мы доверяем. Это позволило бы нам посмотреть данные на проводе и получить измерения со сломанного DNS-сервера (что-то, что вы не можете сделать с помощью pcap на этом сервере, потому что, вы знаете, он сломан).
Вот как выглядела здоровая работа (измеряемая ExtraHop), с двумя DNS-серверами, оба были полностью работоспособны, в течение 24-часового периода:
384/5000
Синий и коричневый — это два разных DNS-сервера. Поскольку оба сервера расположены в одном и том же дата центре, то не было никакого эффекта Smoothed Round Trip Time, и у нас был хорошее равномерное распространение— как и следовало ожидать.
Теперь, что произойдет, если мы выведем один из серверов в оффлайн решим, чтобы имитировать простой провайдера?
Мы видим, что синий DNS-сервер был отключен, а коричневый DNS-сервер был работоспособен.Сломанный DNS-сервер получил такое же количество запросов, как тогда, когда он был в рабочем состоянии, но на коричневом, работающем DNS-сервере было в два раза больше запросов. Это связано с тем, что те пользователи, которые попали на сломанный сервер повторили свои запросы на здоровом сервере. Итак, как это выглядит в терминах реальной производительности клиента?
На этот раз я собираюсь поделиться с вами одним графиком, потому что все они были по сути одинаковыми:
Мы видим, что у значительно части наших посетителей было снижение производительности. Для одних он был незначительным, для других — довольно значительным. Это связано с тем, что 50% посетителей, попавших на неисправный сервер, должны повторить запрос, и количество времени, которое требуется для повтора этого запроса, варьируется. Вы можете снова увидеть большой рост, что указывает на то, что это клиенты, которые потребовали 300 миллисекунд, чтобы повторить запрос.
Что это нам говорит?
Это означает, что в случае отключения DNS-провайдера, мы должны отключить его из ротации, чтобы обеспечить максимальную производительность, до этого момента наши пользователи будут к нему обращаться. Большая часть пользователей окажется под влиянием.
Какое количество NS серверов стоит использовать?
Основываясь на предыдущем тестировании производительности, мы можем предположить, что число повторных попыток, которые может потребоваться клиенту, равно N / 2 + 1, где N — количество перечисленных серверов имен. Таким образом, если мы перечисляем восемь серверов имен, по четыре от каждого провайдера, клиенту может потребоваться сделать 5 DNS-запросов, прежде чем они получат сообщение об успешном завершении (четыре неудачных запроса, а также последний успешный). Человек, который разбирается в статистике лучше меня, мог бы рассказать вам точную вероятность каждого сценария, но короткий ответ:
- Четыре.
Мы чувствовали, что на основе нашего прецедента и снижения производительности, которое мы готовы принять, мы будем перечислять в общей сложности четыре сервера имен — по два от каждого провайдера. Это может оказаться неправильным решением для тех, у кого web presence в Интернете больше чем у нас, но Facebook предоставляет два сервера имен на IPv4 и два на IPv6. Twitter предоставляет восемь, четыре от Dyn и четыре от Route 53. Google предоставляет 4.
Как мы держим наши провайдеры синхронизированными?
DNS имеет встроенные способы синхронизации нескольких серверов. У вас есть трансферы домена (IXFR, AXFR), которые обычно запускаются пакетом NOTIFY, отправляемым на все серверы, перечисленные в качестве NS-записей в зоне. Но они не используются в природе очень часто и имеют ограниченную поддержку со стороны поставщиков DNS. Они также имеют свои собственные головные боли, такие как ведение белого списка ACL, из которых могут быть сотни потенциальных серверов (все различные точки присутствия от нескольких поставщиков), из которых вы не контролируете. Вы также теряете возможность аудита, кто изменил запись, поскольку они могут быть изменены на любом сервере.
Поэтому мы создали инструмент для синхронизации нашего DNS. Мы на самом деле создали этот инструмент много лет назад, как только наши локальные файлы конфигурации стали слишком трудными для редактирования вручную. Однако детали этого инструмента выходят за рамки этого блога. Если вы хотите узнать об этом, придите в блог в марте 2017 года, мы планируем выложить исходники в сеть. Инструмент позволяет нам описывать данные зоны DNS в одном месте и раскидывать их к различным DNS-провайдерам. (https://github.com/StackExchange/dnscontrol инструмент, о котором говориться в статье)
Что мы изучили?
Самый большой вывод из всего этого состоит в том, что даже если у вас несколько DNS-серверов, DNS по-прежнему является единственной точкой отказа, если все DNS зависят от одного провайдера, который вдруг уйдет в оффлайн. До атаки на Dyn это было в значительной степени «теоретически», если вы пользовались большим DNS-провайдером, потому что до первой успешной атаки ни один крупный провайдер DNS никогда не имел большого простоя работы во всех точках присутствия.
Однако реализация нескольких поставщиков DNS не совсем проста. Есть соображения производительности. Вы должны убедиться, что обе ваши зоны обслуживают одни и те же данные. Там может быть такая вещь, как слишком много серверов имен.
Наконец, мы все это делали, следуя рекомендациям DNS. Нам не нужно было делать какие-то странные трюки DNS или писать собственный DNS-сервер, чтобы делать нестандартные вещи. Когда DNS был спроектирован в 1987 году, мне интересно, знали ли авторы о важности того, что они создавали. Я не знаю, но их дизайн по-прежнему силен и эластичен сегодня.
Ссылки
Ранее статья была опубликована тут.
