Низька затримка DNS є ключовим фактором для швидкої роботи в інтернеті. Щоб її мінімізувати, важливо ретельно підібрати DNS-сервери та . Але насамперед слід позбутися марних запитів.
Саме тому DNS спочатку створювався як протокол, що сильно кешується. Адміністратори зон встановлюють час життя (TTL) для окремих записів, а резолвери використовують цю інформацію для зберігання записів у пам'яті, щоб уникнути непотрібного трафіку.
Чи ефективне кешування? Кілька років тому моє невелике дослідження показало, що воно не ідеальне. Погляньмо на нинішній стан справ.
Для збору інформації я пропатчив для збереження TTL для відповіді. Воно визначається як мінімальне TTL його записів, для кожного запиту. Це дає хороший огляд TTL розподілу реального трафіку, а також враховує популярність окремих запитів. Пропатчена версія сервера працювала кілька годин.
Результуючий набір даних складається з 1 записів (name, qtype, TTL, timestamp). Ось загальний розподіл TTL (вісь X - це TTL в секундах):
Якщо не брати до уваги незначного бугра на 86 400 (в основному, для записів SOA), досить очевидно, що TTL знаходяться в низькому діапазоні. Подивимося ближче:
Добре, TTL більше 1 години статистично не значущі. Тоді зосередимося на діапазоні 0-3600:
Більшість TTL від 0 до 15 хвилин:
Переважна більшість від 0 до 5 хвилин:
Це не дуже добре.
Накопичувальний розподіл робить проблему ще очевиднішою:
У половині DNS-відповідей TTL становить 1 хвилину або менше, а у трьох чвертей – 5 хвилин або менше.
Але зачекайте, насправді все ще гірше. Це TTL від авторитативних серверів. Однак клієнтські резолвери (наприклад, маршрутизатори, локальні кеші) отримують TTL від вищих резолверів, і зменшується кожну секунду.
Таким чином, клієнт фактично може використовувати кожен запис, в середньому протягом половини вихідного TTL, після чого відправить новий запит.
Може, ці дуже низькі TTL стосуються лише незвичайних запитів, а не популярних веб-сайтів та API? Давайте подивимося:
Ось X – це TTL, ось Y – популярність запитів.
На жаль, найпопулярніші запити також і найгірше кешуються.
Наблизимо:
Вердикт: все справді погано. Вже й раніше було погано, а стало ще гірше. Кешування DNS стало практично марним. Оскільки все менше людей використовують DNS-резолвер свого провайдера (з поважних причин), збільшення затримки стає помітнішим.
Кешування DNS стало корисним лише для контенту, який ніхто не відвідує.
Також зверніть увагу, що програмне забезпечення може інтерпретувати низькі TTL.
Чому так?
Чому для записів DNS встановлюється такий малий TTL?
- Застарілі балансувальники навантаження залишилися за замовчуванням.
- Ходять міфи, що балансування навантаження по DNS залежить від TTL (це не так - з часів Netscape Navigator клієнти вибирають випадкову IP-адресу з набору RR і прозоро пробують іншу, якщо не можуть підключитися)
- Адміністратори хочуть застосувати зміни негайно, бо так простіше планувати.
- Адміністратор DNS-сервера або балансувальника навантаження бачить своїм завданням ефективно розгортати конфігурацію, яку вимагають користувачі, а не прискорювати роботу сайтів та сервісів.
- Низькі TTL дають душевний спокій.
- Люди спочатку ставлять низькі TTL для тестування та забувають потім їх змінити.
Я не включив до списку відпрацювання відмови, оскільки це все менш актуально. Якщо потрібно перенаправити користувачів в іншу мережу тільки для відображення сторінки з помилкою, коли все інше зламалося, напевно, допустима затримка більше 1 хвилини.
Крім того, хвилинний TTL означає, що якщо авторитетні DNS-сервери будуть заблоковані більш ніж на одну хвилину, ніхто більше не зможе отримати доступ до залежних служб. І надмірність не допоможе, якщо причиною є помилка конфігурації чи злом. З іншого боку, з розумними TTL багато клієнтів продовжать використовувати попередню конфігурацію та ніколи нічого не помітять.
У низьких TTL значною мірою винні сервіси CDN та балансувальники навантаження, особливо коли вони об'єднують CNAME з малими TTL та записи з такими ж малими (але незалежними) TTL:
$ drill raw.githubusercontent.com raw.githubusercontent.com. 9 IN CNAME github.map.fastly.net. github.map.fastly.net. 20 IN A 151.101.128.133 github.map.fastly.net. 20 IN A 151.101.192.133 github.map.fastly.net. 20 IN A 151.101.0.133 github.map.fastly.net. 20 IN A 151.101.64.133
Щоразу, коли закінчується CNAME або будь-який із записів A, доводиться надсилати новий запит. Обидва мають 30-секундний TTL, але він не збігається. Фактичний середній TTL буде 15 секунд.
Але зачекайте! Все ще гірше. Деякі резолвери дуже погано поводяться в такій ситуації з двома пов'язаними низькими TTL:
$ drill raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com. 1 IN CNAME github.map.fastly.net. github.map.fastly.net. 1 IN A 151.101.16.133
Резолвер Level3, мабуть, працює на BIND. Якщо ви продовжите надсилати цей запит, завжди буде повертатися TTL, рівний 1. По суті, raw.githubusercontent.com ніколи не кешується.
Ось ще один приклад такої ситуації з дуже популярним доменом:
$ drill detectportal.firefox.com @1.1.1.1 detectportal.firefox.com. 25 IN CNAME detectportal.prod.mozaws.net. detectportal.prod.mozaws.net. 26 IN CNAME detectportal.firefox.com-v2.edgesuite.net. detectportal.firefox.com-v2.edgesuite.net. 10668 IN CNAME a1089.dscd.akamai.net. a1089.dscd.akamai.net. 10 IN A 104.123.50.106 a1089.dscd.akamai.net. 10 IN A 104.123.50.88
Не менше трьох записів CNAME. Ай. У однієї пристойний TTL, але це абсолютно марно. В інших CNAME початковий TTL складає 60 секунд, але для доменів akamai.net максимальний TTL становить 20 секунд, і жодна з них не у фазі.
Як щодо доменів, які постійно опитують пристрої Apple?
$ drill 1-courier.push.apple.com @4.2.2.2 1-courier.push.apple.com. 1253 IN CNAME 1.courier-push-apple.com.akadns.net. 1.courier-push-apple.com.akadns.net. 1 IN CNAME gb-courier-4.push-apple.com.akadns.net. gb-courier-4.push-apple.com.akadns.net. 1 IN A 17.57.146.84 gb-courier-4.push-apple.com.akadns.net. 1 IN A 17.57.146.85
Та ж проблема, що у Firefox, і TTL більшу частину часу застрягне на 1 секунді при використанні резолвера Level3.
Dropbox?
$ drill client.dropbox.com @8.8.8.8 client.dropbox.com. 7 IN CNAME client.dropbox-dns.com. client.dropbox-dns.com. 59 IN A 162.125.67.3 $ drill client.dropbox.com @4.2.2.2 client.dropbox.com. 1 IN CNAME client.dropbox-dns.com. client.dropbox-dns.com. 1 IN A 162.125.64.3
У запису safebrowsing.googleapis.com значення TTL 60 секунд, як і домени Facebook. І, знову ж таки, з погляду клієнта, ці значення зменшуються вдвічі.
Як щодо встановлення мінімального TTL?
Використовуючи ім'я, тип запиту, TTL і спочатку збережену тимчасову мітку, я написав скрипт для імітації 1,5 мільйона запитів, що проходять через резолвер, що кешує, щоб оцінити обсяг зайвих запитів, відправлених через прострочений запис кешу.
47,4% запитів було зроблено після закінчення терміну дії існуючого запису. Це невиправдано високо.
Яким буде вплив на кешування, якщо встановлений мінімальний TTL?
Ось X - це мінімальні значення TTL. Записи з вихідними TTL вище цього значення не торкнулися.
Вісь Y — відсоток запитів від клієнта, який вже має кешований запис, але його термін дії минув, і він робить новий запит.
Частка "зайвих" запитів знижується з 47% до 36% простою установкою мінімального TTL в 5 хвилин. При установці мінімального TTL в 15 хвилин кількість цих запитів знижується до 29%. Мінімальний TTL за 1 годину знижує їх до 17%. Істотна різниця!
Як щодо того, щоб нічого не змінювати на стороні сервера, а натомість встановити мінімальні TTL у клієнтських DNS-кешах (маршрутизатори, локальні резолвери)?
Кількість необхідних запитів знижується з 47% до 34% при встановленні мінімального TTL в 5 хвилин, до 25% з мінімумом 15 хвилин і до 13% з мінімумом 1 годину. Можливо оптимальне значення 40 хвилин.
Вплив цієї мінімальної зміни величезний.
Які наслідки?
Звичайно, сервіс можна перевести на нового хмарного провайдера, на новий сервер, на нову мережу, вимагаючи від клієнтів використовувати останні записи DNS. І досить малий TTL допомагає плавно та непомітно здійснити такий перехід. Але з переходом на нову інфраструктуру ніхто не очікує, що клієнти перейдуть на нові записи DNS протягом 1 хвилини, 5 хвилин або 15 хвилин. Встановлення мінімального терміну життя 40 хвилин замість 5 хвилин не завадить користувачам отримати доступ до сервісу.
Однак це дозволить значно скоротити затримку та підвищити конфіденційність та надійність, уникаючи непотрібних запитів.
Звичайно, RFC кажуть, що потрібно суворо дотримуватися TTL. Але реальність така, що система DNS стала надто неефективною.
Якщо ви працюєте з авторитативними серверами DNS, будь ласка, перевірте свої TTL. Вам дійсно потрібні такі сміховинно низькі значення?
Звичайно, є вагомі причини встановлення малих TTL для DNS-записів. Але не для 75% трафіку DNS, який практично не змінюється.
І якщо з якихось причин вам дійсно потрібно використовувати низькі TTL для DNS, заразом переконайтеся, що на вашому сайті не включено кешування. З тих самих причин.
Якщо у вас працює локальний DNS-кеш, такий як , який дозволяє встановити мінімальні TTL, використовуйте цю функцію. Це нормально. Нічого поганого не станеться. Встановіть мінімальний TTL приблизно між 40 хвилинами (2400 секунд) та 1 годиною. Цілком розумний діапазон.
Джерело: habr.com