DNS не відноситься до цікавих тем. Якщо ви не є інженером по мережах і інфраструктурі, ви про це практично не згадуєте - поки щось не піде не так. Якщо ви запустили сайт, що не заморочуючись з приводу DNS, то зараз відповідний час вжити заходів, які дозволять утримати ваш сайт на поверхні в той момент, коли інші сайти будуть тонути.
Критикувати 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, ці зміни значно поліпшать відмовостійкість вашого сайту.