Оптимизация настройки DNS

Автор: Брайан Армстронг

Оригинал статьи: You’re probably doing DNS wrong, like we were

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

В киберпонедельник (1 декабря 2014) что-то пошло не так. Массивная атака DDOS повесила серверы в DNSimple за счет огромного всплеска трафика. Сотни, если не тысячи сайтов полегли — включая Exposure, Dribbble, RVM, Canopy и Pinterest.

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

Но это наша ответственность как разработчиков — обеспечить стабильную и отказоустойчивую работу наших сайтов, даже (скорее, особенно) если мы используем сторонние сервисы.

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

Хорошая новость состоит в том, что есть пара шагов, которые могут значительно повысить отказоустойчивость наших сайтов.

1. Увеличьте TTL

Разработчики любят скорость. Но в случае с TTL, быстрее не значит лучше.

TTL это время жизни (time to live), у TTL DNS это время, в течение которого запись DNS будет оставаться в кэше до его очистки.

Это не время жизни кэша, а скорее как долго кэш будет функционировать (несмотря на связанность, это важное различие).

Так как разработчики обычно занимаются записями DNS лишь при внесении изменений, очень заманчиво сделать так, чтобы эти изменения вступили в силу как можно быстрее. Но уменьшение TTL делает вас уязвимыми к отключениям, так как это заставляет серверы имен отвечать на большее количество запросов.

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

Чем дольше ваши записи DNS остаются в кэше (т.е. чем больше TTL), тем дольше ваш сайт будет жить в случае поломки провайдера DNS. Если IP вашего сервера не меняется, вам лучше установить TTL продолжительностью в неделю.

Хостером Canopy является Heroku, поэтому мы используем запись CNAME, указывающую на домен Heroku. Эта запись никогда не меняется, поэтому TTL в 60 секунд является совершенно необязательным. Каждые 60 секунд мы заставляем тысячи служб разрешения имен DNS делать запросы на наши серверы DNS, чтобы получить данные домена, которые у них уже есть.

Если бы наш TTL занимал полную неделю с понедельника, то благодаря кэшированию большинство бы пользователей не заметило бы никаких сбоев у DNSimpe.

2. Используйте серверы имен от разных провайдеров DNS

Это дефолтные серверы имен для DNSimple. Хорошо, что их много, но плохо, что они все от DNSimple. Это значит, что у нас все равно одна точка отказа.

Если вы используете одного провайдера DNS — то у вас всегда будет одна точка отказа, независимо от количества используемых серверов имен.

Для многих сайтов это уже неплохо, но если вам нужен 100% аптайм, вам необходима большая защита. Использование нескольких провайдеров DNS это один из лучших способов противодействия любым сбоям.

Провайдеры DNS позволяют и даже поощряют использование 4-6 дополнительных серверов имен. Это отлично: если сломается один, остальные смогут разобраться с запросами. Но если все серверы имен от одной компании, то вы можете только верить в 100% аптайм, а не гарантировать его. Даже с учетом того, что DNSimple предоставил нам 4 сервера имен, они все полегли под DDOS атакой и наш сайт вместе с ними.

Ваши шансы устоять под DDOS атакой повышаются, если вы используете не только дополнительные серверы имен, но и услуги дополнительных провайдеров DNS.

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

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

Поэтому, если вы хотите использовать 3 сервера имен от Amazon’s Route 53 и 3 от PointDNS, то ваши записи NS и на Route 53, и на PointDNS должны включать все 6 серверов имен.

Увы, не все провайдеры DNS позволяют вам редактировать записи NS. DNSimple также не давал редактировать записи NS, но после атаки они поняли важность этого и добавили поддержку дополнительного DNS.

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

Добавление серверов имен от нескольких компаний однозначно требует больших усилий и совсем не факт, что это оправданно для всех сайтов. Например, для своего личного сайта, я использую одного провайдера DNS (с несколькими серверами имен, разумеется). Не страшно, если этот сайт пробудет пару часов в офлайне.

Но для приложения типа Canopy уход в офлайн неприемлем. Это путает пользователей и доставляет им неудобства, а также портит репутацию нашего бренда. И здесь я готов заниматься синхронизацией записей двух провайдеров DNS, если это помогает снизить риск сбоя.

Хотя минимизация простоя относится к сфере ответственности провайдеров DNS, нашей задачей как разработчиков является эффективное использование инструментов типа DNS. Многие сайты, даже большие, уязвимы через эту одну точку. Если вы не можете позволить себе простой, попытайтесь разделить серверы имен между двумя провайдерами DNS. И увеличьте срок жизни кэша для служб разрешения имен.

Независимо от конкретной компании, которую вы выберете для управления DNS, эти изменения значительно улучшат отказоустойчивость вашего сайта.