DNS-записи

Коротко: Записи в зоні DNS, що пов’язують домени з певною інформацією — найвідоміше IP-адреси, але також поштові сервери, текстові відомості чи псевдоніми.

Докладніше: У кожного DNS-запису є тип (наприклад, A, AAAA, CNAME, MX, TXT, NS), ім’я, значення та TTL. У домену може бути будь-яка кількість записів різних типів; які сервери імен авторитетні для домену, визначається записами NS.

Подробиці

Найважливіші типи записів

• A — домен → адреса IPv4, безперечно найпоширеніший тип запису
• AAAA — домен → адреса IPv6, сучасний аналог A
• CNAME — домен → інше доменне ім’я (псевдонім); за стандартом не може існувати разом з іншими типами записів на тому самому імені
• MX — домен → відповідальний поштовий сервер, із номером пріоритету, коли записів кілька
• TXT — довільний вільний текст, наприклад для підтвердження домену або для SPF/DKIM/DMARC (захист від підміни адреси електронної пошти)
• NS — домен → авторитетний сервер імен, визначає, у кого взагалі «останнє слово» щодо зони
• Інші, рідші типи: SRV (записи служб для певних протоколів на кшталт SIP/XMPP), CAA (визначає, які центри сертифікації можуть видавати сертифікати SSL), PTR (зворотний DNS, IP → домен замість навпаки)

Повний шлях розв’язання

Типовий запит працює так: клієнт питає у свого резолвера DNS (часто провайдера інтернету або публічного на кшталт 1.1.1.1/8.8.8.8) про emzett-digital.com. Якщо відповіді ще немає в кеші резолвера, він спочатку звертається до одного з 13 кластерів кореневих серверів (верхній рівень глобальної ієрархії DNS), який відсилає його до сервера TLD .com. Той, своєю чергою, відсилає до авторитетних серверів імен домену, названих у записі NS, які нарешті повертають відповідний A-запис. Увесь цей шлях називається «рекурсивним розв’язанням», бо резолвер проходить увесь ланцюжок від імені клієнта, замість того щоб лишати кожен окремий проміжний крок самому клієнту (що теоретично теж можливо — «ітеративне розв’язання»).

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

Файли зон і керування

Усі записи домену разом утворюють його «зону», якою керують через файл зони в відповідного DNS-провайдера (наприклад, Cloudflare, Vercel DNS, сам реєстратор). Файл зони відповідає стандартизованому текстовому формату із записом SOA (Start of Authority, містить метадані на кшталт первинного сервера імен і серійного номера для синхронізації), за яким ідуть власне записи ресурсів. Зміни зони вносяться через вебінтерфейс або API провайдера і потім — залежно від TTL змінених записів — поширюються на всі резолвери по всьому світу за секунди–години.

Часті пастки

Класична помилка — поставити запис CNAME на те саме ім’я, де вже є запис A або MX: це порушує RFC 1034 і призводить до непередбачуваної поведінки залежно від резолвера. Так само багато хто забуває заздалегідь знизити TTL перед запланованою міграцією DNS, через що саме перемикання стає видимим скрізь не за хвилини, а за години.

Див. також: A-запис, AAAA-запис, CNAME, MX-запис, TXT-запис, NS-запис, TTL