16.08.2026
2 хв
45
DNS непомітно працює щоразу, коли ми відкриваємо сайт за його доменним ім’ям. Розповідаємо, як google.com перетворюється на IP-адресу, що роблять DNS-сервери, навіщо потрібні кеш, DNS-записи та захищені DNS-запити, а також що відбувається, коли ця система перестає працювати.
Ми відкриваємо браузер, вводимо google.com, натискаємо Enter і за мить бачимо сторінку Google. Це настільки звична дія, що навряд чи хтось замислюється, як комп’ютер узагалі зрозумів, де шукати цей сайт. Адже десь у світі працюють сервери Google, до яких потрібно підключитися, а напис google.com сам по собі не говорить мережі, куди надсилати дані.
Саме тут у гру вступає DNS, або Domain Name System. Ця система непомітно працює у фоновому режимі практично під час кожної нашої подорожі інтернетом. Вона допомагає перетворювати зрозумілі людям назви на адреси, з якими можуть працювати мережеві пристрої. Без DNS інтернет не зник би фізично, сервери продовжували б працювати, а пакети даних усе ще могли б передаватися між пристроями. Але користуватися таким інтернетом було б настільки незручно, що сучасний веб у звичному для нас вигляді фактично перестав би існувати.
Щоб зрозуміти, наскільки важлива ця система, достатньо простежити за тим, що відбувається після звичайного введення адреси сайту в браузері.
Людям зручно запам’ятовувати назви. Набагато простіше пам’ятати google.com, wikipedia.org або youtube.com, ніж набір чисел. Комп’ютерним мережам, однак, потрібна інша інформація. Щоб передати дані конкретному пристрою в мережі, необхідно знати його IP-адресу.
У випадку IPv4 така адреса може виглядати, наприклад, як 192.0.2.10. IPv6 використовує значно довші адреси на кшталт 2001:db8::10. Це спрощені приклади, але вони добре демонструють проблему: навіть кілька таких адрес запам’ятати складніше, ніж назви сайтів. А якби людина регулярно користувалася сотнею різних сервісів, їй довелося б вести власний список адрес.
Доменне ім’я розв’язує цю проблему для людини. DNS, своєю чергою, допомагає мережі з’ясувати, яка адреса пов’язана з потрібним ім’ям. Через це DNS часто називають телефонною книгою інтернету. Аналогія непогана: ми знаємо ім’я людини, а довідник допомагає знайти її номер. У випадку DNS ми знаємо домен, а система допомагає знайти інформацію, необхідну для підключення.
Проте сучасний DNS значно складніший за звичайний довідник. Одному домену можуть відповідати різні IP-адреси, відповіді можуть залежати від розташування користувача та мережевої інфраструктури, а частина інформації кешується на різних рівнях. Крім того, DNS використовується не лише для пошуку адрес вебсайтів. Через нього визначаються поштові сервери, перевіряються налаштування доменів і працює безліч інших механізмів.
Тому коли ми пишемо google.com, за простим доменним ім’ям приховується ціла система, яка повинна швидко відповісти на головне запитання: куди саме потрібно звернутися?
Потреба зіставляти зрозумілі назви комп’ютерів із числовими адресами виникла задовго до сучасного вебу. Коли мережа ARPANET та її наступники були невеликими, проблему можна було вирішувати досить прямолінійно: існував файл із переліком відомих хостів та їхніх адрес.
Цей файл отримав назву HOSTS.TXT. Його централізовано підтримував Network Information Center, а комп’ютери в мережі могли отримувати актуальну копію. Фактично це й була своєрідна телефонна книга: ім’я машини стояло поруч з її адресою.
Поки мережа складалася з відносно невеликої кількості комп’ютерів, така модель була прийнятною. Але інтернет почав швидко зростати. З’являлися нові машини, змінювалися адреси, потрібно було додавати нові записи та розповсюджувати оновлений файл. Централізований список ставав дедалі більшим, а підтримувати його актуальність було дедалі складніше.
Проблема полягала не лише в розмірі файлу. Сам підхід погано масштабувався. Уявімо, що весь сучасний інтернет використовував би один величезний каталог, у якому потрібно було б зберігати назви незліченної кількості серверів. Кожна зміна мала б потрапити до центрального джерела, а користувачі повинні були б регулярно отримувати нову версію цього каталогу.
До початку 1980-х стало зрозуміло, що потрібна система, здатна рости разом із мережею. Замість одного плоского списку необхідно було розподілити відповідальність між різними частинами інтернету та створити ієрархію, у якій ніхто не повинен знати абсолютно все. Саме з цієї проблеми й народився DNS.
На початку 1980-х у технічній спільноті обговорювали перехід від старої плоскої системи назв до ієрархічної. Одним із людей, які відіграли ключову роль у створенні нового механізму, став американський інженер Пол Мокапетріс.
У листопаді 1983 року були опубліковані RFC 882 та RFC 883, автором яких був Мокапетріс. Ці документи описували концепцію та реалізацію Domain Name System і заклали основу DNS. Пізніше їх замінили RFC 1034 та RFC 1035, опубліковані у 1987 році. Саме вони залишаються фундаментальними документами DNS, хоча за десятиліття система отримала безліч доповнень і змін.
Головною перевагою нового підходу стала децентралізація. Замість єдиного списку всіх комп’ютерів у світі з’явилася ієрархічна система. Різні організації могли відповідати за власні частини простору доменних імен, а DNS-серверу більше не потрібно було зберігати повну карту всього інтернету.
Це рішення виявилося напрочуд життєздатним. Коли створювався DNS, не існувало ні Google, ні YouTube, ні соціальних мереж, ні смартфонів, ні хмарних платформ у сучасному розумінні. Всесвітню павутину Тім Бернерс-Лі запропонує лише наприкінці десятиліття. Проте архітектура DNS змогла пережити всі ці зміни.
Причина багато в чому полягає саме в її ієрархічності. Керування величезною системою розділено між великою кількістю учасників. Власнику example.com не потрібно домовлятися з якимось єдиним «головним сервером інтернету» щоразу, коли він створює blog.example.com. Кожен рівень делегує відповідальність наступному.
Цей принцип найкраще видно, якщо простежити звичайний DNS-запит від початку до кінця.
Уявімо найпростішу ситуацію. Ви відкриваєте браузер, вводите google.com і натискаєте Enter. На перший погляд браузеру потрібно лише відкрити сайт. Але спочатку необхідно дізнатися, куди підключатися. Для цього система має отримати адресу, пов’язану з google.com.
При цьому далеко не кожне відкриття сайту запускає повний пошук DNS з нуля. Комп’ютер і браузер активно використовують кеш. Якщо необхідна інформація вже була отримана нещодавно й залишається актуальною, відповідь можна взяти звідти. Це значно швидше.
Якщо готової відповіді немає, запит передається DNS-резолверу. У домашній мережі його адресу пристрій часто отримує автоматично разом з іншими мережевими налаштуваннями. Це може бути DNS-сервіс інтернет-провайдера або інший резолвер, налаштований користувачем, операційною системою, браузером чи адміністратором мережі.
Якщо розкласти весь процес від введення домену до початку завантаження сайту на основні етапи, він виглядатиме приблизно так:
Користувач вводить домен. Браузер отримує
google.comі розуміє, що для подальшого підключення йому потрібно визначити адресу цього ресурсу.
Перевіряється доступна кешована інформація. Якщо актуальна відповідь уже відома системі, повний DNS-пошук може взагалі не знадобитися.
Запит потрапляє до DNS-резолвера. Якщо той також не має потрібної відповіді в кеші, починається пошук через DNS-ієрархію.
Резолвер звертається до кореневої DNS-інфраструктури. Вона допомагає визначити, де шукати інформацію про потрібний домен верхнього рівня, у нашому випадку
.com.
Запит переходить до серверів
.com. Вони допомагають з’ясувати, які DNS-сервери відповідають заgoogle.com.
Резолвер звертається до авторитетного DNS-сервера. Саме звідти він отримує потрібну DNS-відповідь, наприклад IP-адресу.
Відповідь повертається користувачу. Після цього браузер уже може переходити до встановлення необхідного мережевого з’єднання.
У реальному житті завдяки кешуванню весь цей ланцюжок не обов’язково повторюється щоразу. Але саме він добре показує фундаментальну логіку DNS: система поступово рухається від загального до конкретного, доки не знаходить джерело потрібної інформації.
Важливо розуміти: DNS сам по собі не завантажує сторінку Google. Він допомагає знайти інформацію, необхідну для наступного етапу.
Після отримання адреси браузер уже може встановлювати мережеве з’єднання з потрібною інфраструктурою. Для HTTPS далі відбуваються свої процеси: встановлення захищеного з’єднання, перевірка сертифіката, передавання HTTP-запиту, отримання ресурсів сторінки тощо.
Тобто між введенням google.com та появою сторінки існує принципова межа. Спочатку потрібно відповісти на запитання «де?», і лише після цього можна переходити до «підключитися та отримати сторінку». DNS займається переважно першим завданням.
Щоб ця система не перетворилася на новий HOSTS.TXT, DNS побудований у вигляді ієрархії. На її вершині знаходиться коренева зона DNS. Нижче розташовані домени верхнього рівня, такі як .com, .org, .net, .ua, а вже під ними знаходяться конкретні домени.
Доменне ім’я фактично читається ієрархічно справа наліво. Візьмемо умовний news.example.com. Спочатку є корінь DNS, потім .com, далі example.com, а вже всередині цього домену існує news.example.com.
Якщо дуже спростити систему, у звичайному пошуку DNS-відповіді можна виділити чотирьох головних учасників:
DNS-резолвер отримує запит користувача, перевіряє свій кеш і, якщо готової відповіді немає, займається її пошуком.
Коренева DNS-інфраструктура знаходиться на верхньому рівні ієрархії та допомагає резолверу перейти до серверів потрібного домену верхнього рівня.
TLD-сервери відповідають за зони верхнього рівня на кшталт
.com,.orgабо.netі допомагають знайти авторитетні сервери конкретного домену.
Авторитетні DNS-сервери є джерелом DNS-інформації для відповідної зони та повертають дані, які зрештою потрібні резолверу.
Кореневі сервери не зберігають IP-адресу кожного сайту в інтернеті. Їхнє завдання значно фундаментальніше: вони допомагають перейти до потрібного домену верхнього рівня. Якщо резолвер шукає example.com, коренева система може направити його до серверів, відповідальних за .com.
Навколо кореневих DNS-серверів існує відомий міф про те, що «весь інтернет тримається на 13 серверах». Насправді є 13 імен, або логічних ідентичностей кореневих серверів, традиційно позначених літерами від A до M. Але завдяки технології anycast за ними стоїть велика кількість фізичних серверних інстансів у різних точках світу. Тому мова зовсім не йде про 13 одиноких машин, вимкнення яких здатне миттєво знищити DNS.
Наступний рівень, наприклад .com, теж не повинен знати всю інформацію про сайт. Йому достатньо знати, які DNS-сервери є авторитетними для конкретного домену.
І нарешті ми приходимо до authoritative name server, або авторитетного DNS-сервера. Саме він є джерелом DNS-інформації для своєї зони. NS-записи вказують, які сервери є авторитетними для домену.
У цій схемі DNS-резолвер можна уявити як помічника, який бігає по величезній бібліотеці замість вас. Ви кажете йому: «Знайди адресу example.com». Він перевіряє, чи вже знає відповідь. Якщо ні, починає з верхнього рівня каталогу, поступово з’ясовує, до кого звертатися далі, і зрештою приходить до джерела, яке має потрібні дані.
Завдяки цьому жодна окрема частина системи не повинна зберігати інформацію про кожен домен у світі.
Коли говорять про DNS, найчастіше згадують перетворення доменного імені на IP-адресу. Але всередині DNS зберігаються різні типи записів, і кожен виконує своє завдання.
Серед найпоширеніших можна виділити:
A пов’язує доменне ім’я з IPv4-адресою. Саме це один із класичних випадків, коли DNS фактично відповідає на запитання: «На яку IPv4-адресу потрібно звернутися?»
AAAA виконує подібне завдання для IPv6-адрес.
CNAME дозволяє зробити одне доменне ім’я псевдонімом іншого. Замість безпосередньої прив’язки до IP воно вказує на інше доменне ім’я.
MX визначає поштові сервери, які повинні приймати електронну пошту для відповідного домену.
NS показує, які DNS-сервери є авторитетними для певної зони, і є важливою частиною механізму делегування.
TXT дозволяє зберігати текстову інформацію та широко використовується для різноманітних перевірок і налаштувань домену.
Один домен при цьому може мати більше однієї адреси. А вебсайт та електронна пошта на одному домені можуть обслуговуватися зовсім різною інфраструктурою.
Особливо цікаві TXT-записи. Сьогодні вони використовуються в багатьох механізмах, зокрема пов’язаних з електронною поштою та підтвердженням контролю над доменом. Наприклад, DNS бере участь у роботі SPF, DKIM і DMARC, які допомагають захищати поштову інфраструктуру від підроблення повідомлень.
І це далеко не повний список. DNS давно став універсальною розподіленою базою інформації про домени та пов’язані з ними сервіси.
Саме тому помилка в DNS може вплинути не лише на сайт. Неправильно налаштований запис здатен порушити доставлення пошти, роботу певного піддомену або іншого сервісу, який залежить від DNS.
Якби під час кожного відкриття сайту резолвер обов’язково починав із кореневих серверів і проходив усю ієрархію до кінця, це створювало б величезну кількість зайвих запитів. Тому одна з найважливіших складових DNS – кешування.
Припустімо, резолвер щойно з’ясував адресу певного домену. Замість того щоб через секунду повторювати той самий пошук для іншого користувача, він може тимчасово зберегти відповідь. Наступний запит буде оброблений значно швидше й без звернення до всієї DNS-ієрархії.
Життя такої кешованої відповіді можна уявити як простий цикл:
DNS-резолвер отримує актуальну відповідь від відповідного джерела.
Інформація потрапляє в кеш і може повторно використовуватися для наступних запитів.
Поки TTL не закінчився, резолвер має можливість відповідати з кешу замість повторного проходження всього ланцюжка.
Після завершення TTL старий кешований запис більше не повинен використовуватися як актуальний у звичайному режимі.
Під час наступного запиту резолвер отримує свіжу інформацію, після чого цикл починається знову.
Скільки саме можна зберігати інформацію, визначає параметр TTL, або Time To Live. TTL повідомляє резолверам, як довго відповідь дозволено вважати актуальною до повторної перевірки.
Це створює цікавий компроміс. Довгий TTL зменшує кількість DNS-запитів і дозволяє довше користуватися кешем. Але якщо власник домену змінить запис, старі дані можуть ще певний час залишатися в кешах. Короткий TTL дозволяє швидше переходити на нові значення, але збільшує частоту повторних DNS-запитів.
Саме тут з’являється знайома багатьом адміністраторам сайтів ситуація: DNS-запис уже змінено, але один користувач бачить новий сервер, а інший усе ще потрапляє на старий.
Це часто називають «поширенням DNS», ніби новий запис фізично повинен пройти хвилею через весь інтернет. Насправді картина складніша. Значну роль відіграє закінчення терміну життя раніше кешованих відповідей. Один резолвер уже змушений запросити свіжі дані, а інший ще має право використовувати стару відповідь.
Тому порада «просто трохи почекайте після зміни DNS» має цілком технічне пояснення. Десь у мережі старі дані можуть усе ще жити у своєму кеші.
Після опису кореневих серверів, TLD, авторитетних серверів і кешів може здатися, що відкриття будь-якого сайту повинно тривати вічність. Насправді користувач у більшості випадків майже не помічає роботу DNS. Одна з головних причин полягає в кешуванні: якщо потрібна відповідь уже збережена поблизу, проходити повний ланцюжок DNS-запитів не потрібно. Крім того, сама DNS-інфраструктура проєктується так, щоб відповідати максимально швидко, а великі оператори розміщують сервери в багатьох географічних точках.
При цьому не варто прив’язувати швидкість DNS до якоїсь однієї цифри на кшталт «запит завжди займає 20 мілісекунд». Реальний час залежить від мережі, відстані до сервера, наявності відповіді в кеші, конкретного резолвера, стану інфраструктури та інших факторів. Для користувача важливіше те, що DNS знаходиться на критичному шляху відкриття ресурсу: якщо потрібної адреси ще немає, браузеру доводиться спочатку дочекатися її визначення і лише потім переходити до встановлення необхідного з’єднання. Тому повільна робота DNS може додавати помітну затримку, навіть якщо сам вебсервер відповідає дуже швидко.
Саме це також пояснює, чому кешування відіграє настільки важливу роль. Воно не просто зменшує кількість запитів і навантаження на DNS-сервери, а й допомагає зробити роботу величезної розподіленої системи практично невидимою для людини. У нормальних умовах ми навіть не замислюємося, що перед відкриттям звичайної вебсторінки комп’ютеру спочатку потрібно було визначити, де саме в мережі знаходиться потрібний йому ресурс.
Найкращий спосіб оцінити важливість DNS – побачити, що відбувається без нього. Уявімо, що сервер сайту працює нормально. Він підключений до мережі, приймає запити, його канал зв’язку справний. Але DNS-запит до домену з якоїсь причини не дає потрібної відповіді.
Для звичайного користувача результат простий: сайт не відкривається. І тут виникає парадоксальна ситуація. Сам сайт може бути «живим». Інтернет-з’єднання користувача теж може працювати. Інші IP-адреси можуть бути доступними. Але браузер не знає, куди підключатися за вказаним доменним ім’ям.
Це трохи схоже на спробу приїхати в ресторан, знаючи його назву, але не знаючи адреси. Ресторан нікуди не зник, дороги працюють, автомобіль справний. Проблема в тому, що ви не знаєте пункт призначення.
Причини таких проблем можуть бути дуже різними:
недоступний DNS-резолвер, до якого намагається звернутися пристрій користувача;
помилково налаштовані DNS-записи, через які домен повертає неправильну інформацію або не повертає потрібної;
проблеми з авторитетними DNS-серверами, які повинні бути джерелом інформації про домен;
неправильне делегування домену, коли вищий рівень DNS-ієрархії направляє запити не туди, куди потрібно;
мережеві або програмні проблеми, через які DNS-запити не доходять до сервера або відповіді не повертаються користувачу.
Іноді допомагає зміна DNS-резолвера, але це не універсальне рішення. Якщо проблема знаходиться на рівні авторитетної DNS-інфраструктури самого домену, інший публічний резолвер теж може не отримати правильної відповіді.
Варто також пам’ятати, що пряме введення IP не завжди врятує ситуацію. Сучасний веб використовує HTTPS, віртуальний хостинг, CDN та інші механізми, для яких ім’я хоста може бути принципово важливим. Тому популярна порада «якщо DNS не працює, просто введи IP сайту» сьогодні значно менш універсальна, ніж може здатися.
DNS особливо цікавий тим, що проблема в одному компоненті здатна виглядати як поломка зовсім іншого. Якщо великий онлайн-сервіс втрачає доступність своєї авторитетної DNS-інфраструктури, користувачі можуть вирішити, що «впали сервери». Насправді сервери застосунку можуть продовжувати працювати, просто значна частина користувачів більше не може нормально знайти шлях до них за доменним ім’ям. Ще масштабнішими можуть бути проблеми в інфраструктурі компаній, які обслуговують DNS одразу для великої кількості клієнтів. Якщо від такого постачальника залежать тисячі доменів, серйозний збій потенційно відчують користувачі багатьох незалежних сайтів.
Саме тому DNS є критичною інфраструктурою і його намагаються будувати з урахуванням відмовостійкості. Для домену зазвичай використовують кілька авторитетних серверів, а великі DNS-платформи розподіляють інфраструктуру географічно. Додаткову стійкість забезпечує кешування: якщо авторитетний сервер став тимчасово недоступним, частина користувачів може ще певний час отримувати раніше кешовану інформацію. Але кеш не вічний, і коли TTL закінчиться, резолверу знадобиться свіжа відповідь.
Саме тому масштабні DNS-інциденти можуть виглядати так дивно: одночасно перестають відкриватися сервіси, які на перший погляд ніяк між собою не пов’язані. Спільним знаменником виявляється інфраструктура, про існування якої більшість користувачів навіть не знала. DNS у цьому сенсі нагадує електрику в будинку: поки вона є, ми сприймаємо телевізор, холодильник і комп’ютер як окремі пристрої, але щойно електрика зникає, одразу стає очевидно, що всі вони залежали від одного базового шару інфраструктури.
Теоретично передавання даних через IP-мережі не вимагає, щоб кожен ресурс обов’язково мав красиве доменне ім’я. Якщо ви знаєте IP-адресу потрібної машини й відповідний сервіс дозволяє пряме звернення, з’єднання може бути можливим.
Звідси виникає логічне запитання: навіщо тоді взагалі DNS? Може, просто зберігати IP у закладках?
Для сучасного вебу це швидко перетворилося б на кошмар. Причин одразу декілька:
IP-адреси можуть змінюватися. Домен дозволяє власнику сервісу перебудувати або перенести інфраструктуру, не змушуючи мільйони користувачів вивчати нову адресу.
Одна IP-адреса може обслуговувати багато сайтів. Серверу важливо розуміти не тільки адресу, на яку прийшло з’єднання, а й конкретне доменне ім’я, яке хоче відкрити користувач.
HTTPS тісно пов’язаний із доменними іменами. Сертифікати підтверджують право сервера представляти певне ім’я або набір імен, а сучасний TLS дозволяє обслуговувати багато захищених сайтів на спільній інфраструктурі.
За одним доменом може стояти величезна CDN або хмарна платформа. Користувачу не потрібно знати, який конкретно сервер обслуговуватиме його сьогодні, а який завтра.
Усе це показує, наскільки сильно домен відділяє користувача від внутрішньої кухні інтернет-сервісу. Людині достатньо знати стабільне ім’я, тоді як власник сервісу може змінювати сервери, мережі та архітектуру.
Тому інтернет без DNS не обов’язково означає, що жоден пакет більше нікуди не піде. Значно точніше сказати інакше: без системи імен сучасний інтернет утратив би один зі своїх базових механізмів абстракції.
Нам довелося б знати не «що ми хочемо відкрити», а «де воно фізично або логічно знаходиться просто зараз». Для глобальної мережі з постійно змінною інфраструктурою це величезна різниця.
Фраза «DNS перетворює домен на IP» корисна для першого знайомства, але вона створює дещо оманливу картину: ніби кожен сайт має одну постійну адресу, записану навпроти його назви. Сучасний інтернет часто працює зовсім не так.
Великий сервіс може використовувати багато серверів у різних дата-центрах. Якщо всі користувачі світу будуть підключатися до однієї машини, вона швидко стане вузьким місцем. Крім того, користувачу з Європи немає сенсу щоразу звертатися до далекого сервера, якщо необхідну інфраструктуру можна розмістити ближче.
Тому використовуються CDN, балансування навантаження, географічно розподілені дата-центри та інші технології. DNS може бути частиною механізму, який допомагає направляти користувачів до відповідної інфраструктури.
Один домен може мати кілька A або AAAA-записів. DNS-відповіді також не зобов’язані назавжди залишатися однаковими. Інфраструктура може змінюватися, сервери можуть додаватися або виводитися з експлуатації, а системи доставки контенту можуть оптимізувати маршрути обслуговування.
До цього додаються проксі-сервіси. Коли вебтрафік проходить через проксі-мережу, DNS може повертати адресу цієї мережі, а не реального origin-сервера сайту. Уже проксі приймає запит користувача та взаємодіє з сервером, який знаходиться за ним.
Тому аналогія з телефонною книгою поступово починає ламатися. У звичайній книзі ми очікуємо знайти один номер конкретної людини. DNS ближчий до надзвичайно швидкої глобальної довідкової системи, яка може сказати: «Ось актуальний спосіб знайти потрібний тобі сервіс».
І саме така гнучкість дозволяє власникам сайтів перебудовувати інфраструктуру практично непомітно для користувача.
Зручність DNS має й інший бік. Якщо ваш пристрій запитує: «Яка адреса відповідає цьому домену?», хтось повинен отримати цей запит і відповісти на нього.
У традиційному DNS запити могли передаватися мережею без шифрування. Це створювало проблему приватності: мережевий спостерігач міг отримувати інформацію про доменні імена, які запитує пристрій.
Важливо не перебільшувати можливості DNS. Сам DNS-запит не означає, що сторонній спостерігач автоматично бачить повний вміст сторінки, яку ви читаєте. Якщо ви звертаєтеся до example.com, DNS зазвичай працює з доменним ім’ям, а не з повною HTTPS-адресою на кшталт https://example.com/private/article.html.
Проте навіть список доменів може багато розповісти про активність людини. Саме тому питання приватності DNS з часом стало набагато важливішим.
Для захисту DNS-трафіку сьогодні використовуються, зокрема, два поширені підходи:
DNS over HTTPS (DoH) передає DNS-запити через захищене HTTPS-з’єднання, тому сторонньому спостерігачу в мережі значно складніше прочитати сам DNS-запит.
DNS over TLS (DoT) також шифрує обмін між клієнтом і DNS-резолвером, але використовує окреме TLS-з’єднання для DNS-трафіку.
Обидва механізми вирішують схожу проблему: не дозволити сторонньому учаснику мережі просто прочитати DNS-запити під час їх передавання.
Шифрування, однак, не робить DNS магічно анонімним. Резолвер, до якого безпосередньо звертається користувач, усе одно повинен обробити запит. Наприклад, у стандартному DoH резолвер може бачити і IP клієнта, і домен, який той запитує. Існують додаткові технології приватності, які намагаються розділити ці дані між різними учасниками, але це вже наступний рівень розвитку системи.
Тому вибір DNS-резолвера є ще й питанням довіри. Ви фактично обираєте сервіс, який допомагатиме вашому пристрою знаходити домени. DNS, створений у зовсім іншу епоху інтернету, сьогодні повинен вирішувати проблему, про яку в ранніх мережах думали зовсім інакше: як залишатися фундаментальною службою інтернету й водночас не перетворювати кожен запит доменного імені на відкриту листівку.
Приватність є лише однією стороною безпеки DNS. Не менш важливе інше запитання: звідки ми знаємо, що отримана відповідь правильна?
Уявімо, що користувач хоче відкрити bank.example, а зловмиснику вдається змусити його пристрій отримати неправильну IP-адресу. Людина вводить правильний домен, але система направляє її не туди, куди вона очікувала.
Історично DNS створювався в середовищі, де сучасний масштаб кіберзагроз просто не існував. Згодом атаки на механізми визначення імен стали окремим напрямом. Одним із відомих класів є DNS cache poisoning, коли атакувальник намагається домогтися появи неправдивої інформації в DNS-кеші.
Якщо отруєна відповідь потрапить у кеш і буде прийнята за справжню, проблема може зачепити не один запит. До закінчення терміну її життя неправильні дані потенційно використовуватимуться повторно.
Для посилення захисту DNS сьогодні використовуються різні механізми, які важливо не плутати між собою:
DNSSEC допомагає криптографічно перевіряти автентичність та цілісність DNS-даних. Його завдання полягає не в приховуванні запиту, а в можливості перевірити отриману інформацію.
DoH шифрує DNS-трафік між клієнтом і резолвером за допомогою HTTPS. Це насамперед захист каналу передавання та приватності запиту на цій ділянці.
DoT переслідує схожу мету, але передає DNS через захищене TLS-з’єднання, спеціально призначене для такого трафіку.
Тобто DNSSEC не є «ще одним способом зашифрувати DNS». А DoH та DoT самі по собі не виконують ту саму функцію перевірки автентичності DNS-даних, для якої створений DNSSEC.
При цьому DNS є лише одним шаром безпеки сучасного вебу. HTTPS і TLS виконують власну роботу. Навіть якщо користувач отримав IP-адресу, браузер під час захищеного з’єднання повинен перевірити сертифікат сервера. Саме багатошаровість робить сучасну модель безпеки значно сильнішою, ніж спроба довіряти одному-єдиному механізму.
DNS повинен не просто сказати «йди туди». У сучасному інтернеті дедалі важливіше мати можливість переконатися, що ця відповідь заслуговує на довіру.
Найдивовижніше в DNS навіть не те, наскільки складною є система за звичайним введенням адреси в браузері. Дивовижніше те, скільки змін вона пережила. Перші специфікації DNS з’явилися у 1983 році, коли інтернет неможливо було порівнювати із сучасним за масштабом і способом використання. Не було звичного нам вебу, пошукових систем, стримінгових платформ, соціальних мереж, хмарних сервісів і мільярдів смартфонів. Проте фундаментальна ідея ієрархічної розподіленої системи імен виявилася настільки вдалою, що продовжує працювати десятиліття потому.
DNS не залишився застиглим у 1980-х. Змінювалися протоколи, з’являлися нові типи записів, механізми безпеки, підтримка IPv6, шифрування запитів та величезні anycast-інфраструктури. Але основна логіка збереглася: глобальний простір імен розділений на рівні, а відповідальність можна делегувати. Завдяки цьому система масштабується без необхідності створювати єдину всесвітню базу, яка повинна знати абсолютно все.
І тепер можна повернутися до того самого google.com, з якого ми почали. Користувач вводить кілька знайомих символів, після чого система перевіряє кеш. За необхідності DNS-резолвер шукає відповідь, коренева інфраструктура допомагає знайти потрібний домен верхнього рівня, а далі визначаються авторитетні сервери. Зрештою повертаються дані, які дозволяють продовжити підключення. Після цього вступають у роботу інші мережеві протоколи, встановлюється захищене з’єднання, надсилається запит і завантажується сторінка.
Для користувача вся ця складна послідовність залишається практично невидимою: він просто вводить google.com і за мить бачить Google. У цьому й полягає одна з головних ознак добре спроєктованої інфраструктури: поки все працює правильно, більшу частину часу ми навіть не замислюємося про її існування.
DNS не є самим інтернетом і не передає замість нього весь вебконтент. Його роль водночас простіша й фундаментальніша: він дозволяє людям і програмам знаходити потрібні ресурси за стабільними та зрозумілими іменами, не думаючи постійно про те, на яких IP-адресах і в яких дата-центрах вони працюють.
Без DNS сервери не зникли б, маршрутизатори не перестали б передавати пакети, а IP-протокол продовжив би існувати. Але сучасний інтернет, де ми відкриваємо сайти за зрозумілими назвами, переносимо сервіси між серверами, використовуємо хмари, CDN, електронну пошту та величезну розподілену інфраструктуру, став би незрівнянно складнішим у використанні.
Саме тому DNS майже не помітний, коли все працює, і миттєво стає помітним, коли ламається. Щоразу, коли ми вводимо адресу сайту й за секунду бачимо потрібну сторінку, десь у фоновому режимі продовжує виконувати свою роботу система, фундаментальні принципи якої були закладені понад сорок років тому.
