Розподіл DNS від початку до кінця

Кожного разу, коли ви вводите домен у браузер, запускається ланцюг пошуків перш ніж один пакет досягне сайту, який вам потрібен. Більшість цього ланцюга невидима, і більшість пояснень зупиняються на "це як телефонний довідник". Ось що насправді відбувається, крок за кроком, включаючи частини, які люди зазвичай пропускають.

Stub resolver не розумний

Ваша операційна система не виконує справжнього DNS розподілу самостійно. Вона запускає stub resolver, тонкий шматок коду, який просто передає ваш запит будь-якому DNS серверу, налаштованому в /etc/resolv.conf на Linux або в параметрах вашого мережевого адаптера в Windows. Перевірте свій за допомогою:

cat /etc/resolv.conf

Цей файл зазвичай вказує на ваш маршрутизатор (наприклад 192.168.1.1), resolver вашого провайдера або публічний, як 1.1.1.1 або 8.8.8.8. Stub resolver не має власної логіки кешування, крім того, що надає ОС або локальний daemon як systemd-resolved.

Рекурсивний resolver виконує реальну роботу

Коли ваш запит потрапляє на рекурсивний resolver, цей сервер береться за пошук відповіді, навіть якщо йому потрібно запитати кілька інших серверів. Якщо відповідь уже кешована з попереднього пошуку, ви отримаєте її одразу. Перевірте TTL за допомогою:

dig example.com

Поглянуть на ANSWER SECTION — число перед типом запису (наприклад 300 перед A) це TTL у секундах. Це час, протягом якого resolver може кешувати запис перш ніж запитати знову.

Якщо нічого не кешовано, рекурсивний resolver починає проходити вниз по DNS ієрархії від кореня.

Кореневі, TLD та авторитетні сервери

Існує 13 кореневих адрес серверів (a.root-servers.net через m.root-servers.net), кожна підтримана багатьма фізичними машинами через anycast маршрутизацію. Кореневий сервер не знає, де знаходиться example.com, але він знає, які сервери обробляють .com, тому він повертає посилання.

Resolver потім запитує TLD сервер .com, який знову не знає остаточну відповідь, але знає, які nameserver авторитетні для example.com. Ви можете побачити це делегування самостійно:

dig +trace example.com

Ця команда показує кожен перехід: корінь, потім TLD, потім авторитетні nameserver для домену, закінчуючи фактичним записом A або AAAA. Це найкраща команда для розуміння DNS візуально замість теоретично.

Авторитетний nameserver це останній зупинок. Це сервер, який насправді налаштував власник домену, часто через DNS панель реєстратора або сервіс як Route 53 або Cloudflare DNS. Це єдиний сервер у всьому ланцюзі, який має справжню, канонічну відповідь замість кешованої копії або посилання.

Типи записів, які ви насправді зустрінете

Запис A відображує ім'я на IPv4 адресу, AAAA робить те ж саме для IPv6. CNAME вказує одне ім'я на інше ім'я замість IP, це як CDN наприклад Cloudflare або Fastly маршрутизують трафік без відкриття сирих IP. MX записи обробляють маршрутизацію пошти, і TXT записи несуть довільний текст, найчастіше зараз використовуються для SPF, DKIM та рядків верифікації домену. NS записи розповідають світу, які сервери авторитетні для зони, і це тип запису, який робить делегування можливим у першу чергу.

Де насправді живе кешування

Кешування відбувається на кількох рівнях одночасно: сам браузер (Chrome має власний DNS кеш, видимий на chrome://net-internals/#dns), кеш OS resolver, локальний маршрутизатор, і upstream рекурсивний resolver. Це чому зміна DNS може виглядати так, що працює миттєво на одному пристрої і займе години, щоб з'явитися на іншому — ви не потрапляєте в той же кеш.

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

Чому це важливо для усунення несправностей

Коли сайт недоступний, dig +trace розповідає вам точно, який рівень зламаний: проблема на рівні root/TLD виглядає зовсім інакше, ніж неправильно налаштований авторитетний сервер або застарілий кеш на вашій власній машині. Порівняння dig example.com з відомим хорошим resolver, як dig example.com @1.1.1.1, ізолює, чи проблема у вашому локальному resolver або в самій DNS конфігурації домену.

DNS виглядає просто ззовні, тому що зазвичай розв'язується за менше 100ms і ніхто про це не думає. Під капотом це розподілена, кешована, ієрархічна система запитів, яка працює з майже незмінною структурою з 1980-х років, що дуже добре говорить про те, як добре вихідний дизайн витримав.

Якщо ви хочете йти далі з цим, Korra Studio має пов'язані сегменти на DEFENSE_GRID, що охоплюють розширення безпеки DNS, DNS тунелювання як техніку екзфільтрації та розробку власного resolver з нуля на Python.