Щось зламалося. Сайт не вантажиться, пошта відбивається, або ти годину тому змінив запис — і нічого не відбувається. У дев'яти випадках із десяти відповідь сидить у DNS — треба лише знати, як подивитися.
DNS — це адресна книга інтернету: він перетворює example.com на IP, до якого браузер реально може під'єднатися. Коли він вередує, усе нижче по ланцюгу виглядає зламаним, хоча сервер цілий. Розберімо, як читати його як належить.
Записи, які варто знати
Усі напам'ять не потрібні. Найчастіше доводиться пам'ятати ось ці:
| Запис | Що робить | Що ламається, коли він неправильний |
|---|---|---|
| A | Прив'язує ім'я до адреси IPv4 | Сайт указує на не той/старий сервер |
| AAAA | Те саме, але IPv6 | IPv6-користувачі до тебе не дістаються |
| MX | Куди йде пошта домену | Листи відбиваються або зникають |
| TXT | Довільний текст — SPF, DKIM, верифікація | Пошта летить у спам; верифікація падає |
| NS | Які сервери імен авторитетні | Весь домен резолвиться неправильно |
| CNAME | Псевдонім, що вказує одне ім'я на інше | Піддомен не резолвиться |
| SOA | Адмін-метадані зони | Рідко — але називає головний NS |
| CAA | Які CA можуть видавати тобі сертифікати | Випуск сертифіката відхиляється |
Наш інструмент DNS Lookup опитує всі десять типів, які підтримує — A, AAAA, MX, TXT, NS, CNAME, SOA, CAA, SRV і PTR — на резолвері за твоїм вибором: Google (8.8.8.8), Cloudflare (1.1.1.1) чи Quad9 (9.9.9.9). Він показує повний технічний вивід зі збереженими значеннями TTL — рівно такий, який видає dig (класична консольна утиліта, якою сисадміни роблять DNS-запити прямо з терміналу). Ти читаєш те саме, що вони бачать у себе на екрані, тільки в браузері.
Помітив A-запис, що вказує на незнайому IP? IP WHOIS за секунди скаже, хто нею володіє.
TTL: непомітне число, через яке зміни «не працюють»
Кожен запис несе TTL — час життя, у секундах. Це скільки резолверам дозволено кешувати відповідь, перш ніж питати знову. TTL 3600 означає «довіряй цьому годину».
Це одне число пояснює більшість паніки «моя зміна DNS не працює». Простий приклад: ти виправляєш A-запис о 12:00, а TTL у нього — 86400 (доба). Резолвери, які спитали твій домен об 11:30, і далі віддаватимуть старий IP майже 24 години — і для частини користувачів сайт «переїде» лише наступного дня. Не тому, що щось зламалося, а тому, що ти сам дозволив кешувати цю відповідь на добу.
Практичне правило, якого ми тримаємося: знизь TTL за добу до того, як плануєш міняти запис. Опусти до 300 секунд, дочекайся, поки спливе старий високий TTL, і тоді вноси зміну. Тепер перемикання поширюється за хвилини, а не за добу. Після цього підніми TTL назад, щоб резолвери постійно не довбали твої сервери імен.
«Я вже змінив запис — чому нічого не змінилося?»
Бо в DNS немає кнопки «оновити». Немає центрального сервера, куди можна запушити зміну. Твій авторитетний сервер імен отримує нове значення миттєво — але кожен резолвер, який уже встиг закешувати старе значення, і далі віддаватиме саме його, доки не спливе TTL. А різні резолвери в різних країнах спливають у різні моменти.
Саме тому ми зробили перевірку поширення DNS такою, як вона є. Вона не питає один резолвер, а одночасно надсилає той самий запит до 15 публічних резолверів по всьому світу — Google і Cloudflare у США, Quad9 у Швейцарії, Mullvad у Швеції, CZ.NIC у Чехії, Alibaba і DNSPod у Китаї та інші. На карті видно, де новий запис уже показується, а де ще віддається старе значення з кешу. Коли всі 15 показують однакове — зміна поширилася по всьому світу.
Орієнтир: «поширення» — це не повільний інтернет. Це кеші, що шанують виставлений тобою TTL.
Коли проблема в самому резолвері
Часом записи всюди правильні, а сайт усе одно мляво резолвиться. Це вказує на затримку резолвера, а не на значення записів.
Наш інструмент часу відгуку DNS міряє саме це: по кілька разів робить один і той самий запит до тих самих 15 резолверів і показує для кожного мінімальний, максимальний і середній час відповіді. Якщо твої користувачі в Німеччині, а твої сервери імен відповідають Франкфурту за 8 мс, а Сіднею — за 280 мс, це реальний, вимірюваний сигнал: можливо, час перейти на anycast-DNS-провайдера.
Хто керує зоною: WHOIS і сервери імен
Якщо NS-записи виглядають не так, питання стає хто їх виставив. Domain WHOIS дає тобі реєстратора, дати реєстрації й закінчення, статус-коди домену, чи ввімкнено DNSSEC і — головне — сервери імен, які реєстр має у себе.
Одне, що варто знати, бо дешевші інструменти на цьому хибують: чимало новіших розширень типу .tools, .app і .dev взагалі не тримають традиційного WHOIS-сервера. Спитаєш їх по-старому — і не отримаєш нічого. Наш інструмент автоматично відкочується на RDAP — сучасну заміну на основі JSON — щойно виявляє неповну чи відсутню WHOIS-відповідь, тож домен .tools повертає той самий структурований результат, що й .com. Ми, до речі, наштовхнулися на це на власному домені. Виправлення стало фічею.
Якщо сервери імен у реєстрі не збігаються з тим, що ти виставив у свого DNS-хоста, ти знайшов баг: домен указує геть в інше місце, і жодне редагування записів не зарадить, поки не виправлено делегування NS.
Швидкий чек-лист, коли DNS «не працює»
- Подивись запис, який змінював, через інструмент DNS Lookup. Нове значення взагалі там є?
- Перевір TTL. Високий? Ти просто чекаєш на спливання кешу.
- Зроби перевірку поширення. Різні результати по регіонах — кеші ще спливають; однаково всюди — воно живе.
- Звір NS-записи із твоїм DNS-хостом через WHOIS. Розбіжність делегування — справжній винуватець частіше, ніж здається.
- Усе ще повільно? Зміряй час відгуку резолвера, перш ніж винуватити свій застосунок.
Підсумок
Більшість DNS-«збоїв» — не збої. Це TTL, що роблять рівно те, що ти їм сказав, або делегування, що вказує туди, про що ти забув. Читай записи, поважай TTL і перевіряй поширення більш ніж по одному резолверу, перш ніж робити висновки. Почни з DNS Lookup — відповідь зазвичай прямо у виводі.
— команда checkbox.tools