Як працює DNS: від крапки в корені до запису whois

Кожне доменне ім'я закінчується крапкою, якої ви ніколи не пишете

Ім'я, яке ви набираєте, — не повне. example.com це скорочення; справжнє, повністю визначене ім'я має вигляд example.com. — із крапкою в кінці. Ця крапка і є корінь, вершина всієї системи імен. Усе інше висить під нею.

Прочитайте домен справа наліво — і ви прочитаєте ланцюг повноважень:

• . — корінь. Одна зона на весь інтернет.
• com. — домен верхнього рівня, делегований коренем.
• example.com. — домен другого рівня, делегований зоною .com.
• www.example.com. — ім'я всередині цього домену, яким повністю розпоряджається його власник.

Кожен рівень знає про наступний рівно одну річ: кого питати далі. Корінь не знає адреси example.com — він знає, хто веде .com. Сервери .com адреси теж не знають — вони знають, які сервери імен оголошено для example.com. І лише останні тримають справжню відповідь. Це вся конструкція, і все подальше з неї випливає.

Коренева зона: тринадцять імен, сотні майданчиків

Коренева зона — невеликий файл. У ньому перелічені всі домени верхнього рівня й делеговані їм сервери імен: близько півтори тисячі записів, кілька мегабайтів тексту. Це єдина точка, з якої починається розв'язання будь-якого імені.

Її віддають тринадцять іменованих серверів, від a.root-servers.net до m.root-servers.net. Це число часто читають як «інтернет тримається на тринадцяти машинах». Ні. Тринадцять — це кількість імен, і вибрана вона тому, що відповідь DNS мусила вміщуватись у UDP-пакет на 512 байтів: рівно стільки серверних записів туди й влазило.

За цими іменами стоять дванадцять незалежних організацій-операторів — університети, державні установи, мережеві оператори, неприбуткові фонди, — які разом тримають далеко за тисячу фізичних примірників по всьому світу. Адреси спільні завдяки anycast: та сама IP-адреса анонсується з багатьох місць одночасно, а маршрутизація доправляє ваш запит до найближчого. Втрата всіх примірників на цілому континенті погіршує обслуговування, але не спиняє його.

Вміст кореневої зони визначають не ті, хто тримає сервери. Зміни проходять через IANA — функцію, яка веде реєстри імен, номерів і параметрів протоколів, — і публікуються звідти. Сервери розповсюджують; вони не вирішують.

Хто веде домен верхнього рівня, а хто продає вам ім'я

У кожному домені беруть участь три різні сторони, і саме їх плутають, коли не можуть зрозуміти, хто що може полагодити.

Реєстр (registry)

Організація, яка веде один TLD: тримає зону, утримує авторитетні сервери імен для неї й визначає правила цієї зони. На один TLD він рівно один.

Реєстратор (registrar)

Компанія, у якої ви купуєте ім'я. Має договір із реєстром і спілкується з ним протоколом EPP. Реєстраторів на один реєстр багато, і між ними можна переходити.

Власник (registrant)

Ви. Ви маєте право користуватися ім'ям певний строк і задаєте його сервери імен.

Тому коли домен заблоковано — це зробив реєстратор або реєстр, а не ваш хостинг. Коли сайт не відкривається, а ім'я розв'язується — з реєстром усе гаразд, і проблема деінде. Реєстровий запис каже, через якого реєстратора тримають ім'я і в якому стані його вважає реєстр.

Які бувають домени верхнього рівня

Загальні (gTLD)

.com, .net, .org, .info, .biz, а з часів розширення, що відкрилося 2012 року, — ще понад тисяча: .site, .online, .shop, .app і решта. Усі працюють за договором з ICANN, і саме договір робить їхні правила спільними: однакові коди статусів, обов'язковий RDAP, єдиний порядок передачі.

Національні (ccTLD)

Дві літери зі списку країн ISO: .ua, .de, .pl. Вони не підпадають під договір для загальних доменів. Кожен ведеться за власною національною домовленістю, з власними правилами про те, хто може реєструвати, які дані публікуються і які протоколи пропонуються. Саме тому національні домени поводяться так непослідовно порівняно із загальними.

Національні, які продають як бренд

.io, .co, .me, .tv, .ai технічно є національними доменами, які продають по всьому світу. Правила в них ccTLD-івські, і це подеколи дивує тих, хто розраховував на захист, передбачений для загальних доменів.

Інфраструктурний

.arpa — не для сайтів. У ньому живуть in-addr.arpa та ip6.arpa, зони, які відображають адреси назад в імена. Зворотний DNS — це звичайне делегування всередині тієї самої ієрархії, і тому ним керує власник блоку адрес, а не власник сайту.

Дванадцять доменів і звідки беруться записи про них

Візьмімо конкретний набір — той, що найчастіше трапляється в згенерованих тестових даних. Ось якого роду кожна зона й який протокол за неї відповідає:

Різниця в останньому рядку суттєва. Для загального домену RDAP — договірний обов'язок: ICANN вимагає його від кожного реєстру й реєстратора gTLD із серпня 2019 року. Для національного домену такого договору немає — оператор публікує RDAP, бо сам так вирішив. Більшість тих, що продаються комерційно, публікують; чимало суто національних — ні.

Оператори реєстрів змінюються. Реєстри купують і продають, і компанія, яка веде домен сьогодні, за три роки може бути іншою. Авторитетну й завжди актуальну відповідь на питання «хто веде цей TLD» дає база кореневої зони IANA, а не стаття — зокрема й ця.

Як ім'я розв'язується насправді

Ви набрали ім'я. Далі задіяно щонайменше чотири різні машини, і розуміння цього поділу пояснює більшість проблем із DNS.

1. Пристрій питає свій резолвер. Заглушка-резолвер в операційній системі сама ієрархією не ходить. Вона шле одне питання рекурсивному резолверу — провайдерському або обраному вами — і чекає на готову відповідь.
2. Резолвер питає корінь. Якщо він не знає нічого, то питає кореневий сервер про www.example.com. Корінь не віддає адреси. Він віддає відсилання: «питай сервери .com, ось вони».
3. Резолвер питає .com. Ще одне відсилання: «сервери імен для example.com — оці».
4. Резолвер питає їх. Вони авторитетні для зони й віддають справжній запис.

Далі резолвер кешує кожен крок і віддає вам відповідь. Наступний, хто спитає будь-що в .com, пропустить крок 2; наступний, хто спитає це саме ім'я, пропустить усе. На практиці корінь питають рідко — саме тому тринадцять імен здатні обслужити світ.

Два наслідки, які варто тримати в голові:

• Авторитетну відповідь ви майже ніколи не бачите напряму. Ви бачите те, що закешував ваш резолвер. Тому запис, змінений годину тому, досі виглядає старим, і тому двоє людей можуть чесно повідомляти різні результати в один момент.
• «Поширення» — хибне слово. Нікуди нічого не розсилають. Кеші просто тримають відповідь, яку їм дозволили тримати, стільки, скільки сказав її TTL. Побачити, що авторитетні сервери відповідають саме зараз, можна запитом до DNS — це часто найшвидший спосіб відрізнити «запис неправильний» від «запис правильний, а ваш кеш старий».

Делегування, glue і розбіжність, яка ламає пів сайту

Делегування — це просто NS-запис у батьківській зоні. У .com для example.com лежить список імен серверів — і більше нічого про сам домен.

Звідси очевидна циклічність, коли сервери імен живуть усередині домену, який вони ж і обслуговують. Якщо example.com тримає ns1.example.com, то знайти ns1.example.com неможливо, не спитавши спершу example.com. Рятує glue-запис: батьківська зона зберігає адресу сервера імен поруч із делегуванням і розриває петлю. Саме через glue реєстратор просить IP-адреси, коли ви користуєтесь серверами всередині власного домену, — і саме тому забути оновити його після переїзду сервера означає покласти весь домен так, що пояснити це неможливо.

Друга класична поломка — розбіжність між батьком і самою зоною. Реєстр публікує один набір серверів імен, а NS-записи всередині зони перелічують інший — зазвичай тому, що старого провайдера так і не прибрали. Резолвери обирають між ними, тож сайт працює в одних людей і не працює в інших, а кожна спроба відтворити збій дає інший результат. Звірте NS-записи у зоні з тими, що в реєстровому записі; якщо вони різні — ви знайшли причину.

Тонкі й товсті реєстри: чому дві довідки розходяться

Одні реєстри зберігають повний запис про домен, інші — майже нічого.

Тонкі

.com і .net. Реєстр тримає реєстратора, сервери імен і дати. Усе про власника живе в реєстратора. Довідка реєстру про домен .com справді не може сказати більше, бо більшого там немає.

Товсті

Більшість новіших загальних доменів і чимало національних. Реєстр тримає повний запис централізовано.

Тому той самий домен може дати дві різні відповіді залежно від того, кого спитали, і обидві правильні: реєстр авторитетний щодо делегування й дат, реєстратор — щодо всього, що стосується клієнта.

whois: порт 43 і ланцюг відсилань, який змушує його працювати

Whois — первісний протокол довідки, описаний 1982 року. Механізм мінімальний: відкрити TCP-з'єднання на порт 43, надіслати рядок тексту, прочитати те, що прийшло, вільним текстом, роз'єднатися. Ні схеми, ні назв полів, ні домовленості про вигляд. Кожен реєстр відповідає у власному форматі.

Очевидне питання: як клієнт дізнається, який саме сервер питати про конкретну зону, якщо їх близько півтори тисячі. Відповідь — відсилання у два кроки, і знати про нього варто, бо це та сама процедура, якою йде консольна команда whois:

1. Спитати whois.iana.org про об'єкт. IANA не тримає реєстраційних даних — вона тримає реєстр реєстрів.
2. У її відповіді є рядок, що починається з refer: або whois:, — адреса сервера, у якого справді є запис. Питати вже його.

Два з'єднання, і жодного власного списку «зона → сервер». Це важливо: будь-який такий список починає застарівати з моменту написання, і робить це мовчки — застарілий рядок не дає помилки, він дає відповідь від не того сервера.

Whois прожив сорок років тому, що людина прочитає відповідь будь-якого реєстру. Згортають його тому, що програма — ні: надійно, для всіх реєстрів і без поломки при наступній правці шаблону не вийде.

RDAP: заміна і те, як вона знаходить потрібний сервер

RDAP — Registration Data Access Protocol — відповідає на ті самі питання через HTTPS, у форматі JSON, зі стандартними назвами полів. Його описали 2015 року, а документи про запити й відповіді переписали 2021-го. Крім формату, він дав три речі, яких у порту 43 не було ніколи: дані з явно оголошеним кодуванням, машинозрозумілий спосіб сказати «це поле свідомо приховано», і бутстрап.

Бутстрап — це відповідь RDAP на ту саму задачу «кого питати». IANA публікує машинозрозумілі файли бутстрапу — окремо для доменів, для блоків IP-адрес і для номерів автономних систем, — які зіставляють кожну зону чи діапазон із базовою адресою відповідальної служби RDAP. Клієнт завантажує ці файли, кешує їх і відтоді знає, куди слати будь-який запит. Є й публічні перенаправлювачі, які реалізують бутстрап за вас: ви шлете всі запити на одну адресу, а вона переправляє вас до потрібного реєстру.

Хронологія пояснює, чому інструменти розходяться у відповідях. ICANN зробив RDAP обов'язковим для реєстрів і реєстраторів загальних доменів у серпні 2019 року, кілька років обидва протоколи працювали паралельно, а на початку 2025-го договірну вимогу тримати живим порт 43 скасували. Частина операторів досі підтримує його добровільно, дедалі більша частина — ні. Національні домени живуть власним життям: у когось є RDAP, у когось лише порт 43, а дехто пропонує виключно вебформу.

На практиці це означає, що клієнт питає спершу RDAP і переходить на порт 43 рівно з однієї причини: у бутстрапі немає запису про цю зону. Помилка мережі чи відмова через ліміт причиною не є — питати те саме в другого сервера після відмови першого є найкоротшою дорогою до того, щоб обмежили обидва, а другий сервер зазвичай належить тому самому реєстру.

«Такого імені немає» — це відповідь, а не збій

У DNS є окрема відповідь для імені, якого не існує, — NXDOMAIN, — і вона авторитетна: сервер, відповідальний за зону, стверджує, що нічого з такою назвою там немає. Це інший результат, ніж «ім'я є, але записів такого типу в нього немає», і ще інший, ніж «я не достукався до того, хто знає».

Протокол ставиться до цієї різниці достатньо серйозно, щоб кешувати відповіді окремо. Заперечне кешування, описане 1998 року, дозволяє резолверу запам'ятати відповідь «не існує», а строк задає сама зона у своєму записі SOA — зазвичай від хвилин до годин. Без нього кожна друкарська помилка в імені й кожна автоматична проба неіснуючої назви щоразу доїжджали б до авторитетних серверів.

Це ж і причина, чому щойно створений запис інколи не з'являється в однієї конкретної людини, тоді як у всіх інших працює: вона спитала зарано, отримала коректну заперечну відповідь, і її резолвер тримає цю відповідь, доки та не спливе. Нічого не зламано, і пришвидшити це вона ніяк не може.

Реєстрові довідки стикаються з тією самою задачею на рівень вище. Реєстри публікують записи про сотні мільйонів доменів і отримують запити безперервно, тому практично всі вони обмежують частоту за адресою джерела, а служби RDAP віддають явний статус «забагато запитів», коли клієнт перебирає. Клієнт, який вважає «такого домену немає» тимчасовою помилкою й повторює запит, створює навантаження, що не дає нічого, — власне, заради таких клієнтів обмеження й з'явилися.

DNSSEC: ланцюг, що йде тією самою ієрархією

У звичайному DNS ніщо не доводить, що відповідь прийшла від потрібного сервера. DNSSEC додає підписи й перевіряє їх точно тим самим ланцюгом делегування: корінь підписує своє твердження про ключ .com, .com підписує твердження про ключ example.com, а example.com підписує свої записи. Резолвер, який перевіряє, проходить цей ланцюг від ключа, якому вже довіряє, — кореневого — до самої відповіді.

Характер відмови варто знати, бо він різкий і несиметричний. Якщо підписи зони спливли, кожен резолвер, який перевіряє, взагалі відмовляється відповідати, а кожен, який не перевіряє, працює як завжди. Домен цілком мертвий для одних людей і цілком справний для інших — тому свідчення ніколи не сходяться, і фраза «у мене працює» тут не несе інформації.

Складаємо докупи

Коли з доменом щось не так, ієрархія сама підказує, куди дивитися, і в якому порядку:

1. Чи реєстр досі його делегує? Статуси в реєстровому записі: домен на утриманні прибрано з DNS повністю, і ніщо на вашому сервері цього не змінить.
2. Чи збігаються сервери імен у батька й у зоні? NS у реєстрі проти NS у зоні. Розбіжність дає уривчасті збої, які не відтворюються.
3. Чи відповідає зона і чим саме? A, AAAA, MX і TXT одним запитом — більшість реальних проблем є розбіжністю між типами записів, а не поломкою всередині одного.
4. Чи ведуть адреси кудись? Хто тримає адресу, на яку вказує ім'я, і чи це досі ваша інфраструктура. Запис, що й далі дивиться на хостинг, покинутий два роки тому, — поширена й тихо небезпечна знахідка.
5. Чи сервер узагалі відповідає? Що віддає вебсервер — бо на цьому кроці ім'я вже точно ні до чого.