Що таке SOA-запис DNS і чому він важливий для вашого домену

Що таке SOA-запис?

SOA-запис (Start of Authority) — перший запис у кожній зоні DNS і єдиний, який мусить існувати рівно один раз. Він називає первинний неймсервер зони, контактну адресу адміністратора та набір таймерів, що підказують вторинним неймсерверам, як тримати свою копію зони синхронізованою.

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

Побачити SOA-запис будь-якого домену можна за допомогою dig:

dig SOA example.com +short

Типова відповідь має такий вигляд:

ns1.example.com. hostmaster.example.com. 2026082601 3600 900 1209600 300

Сім значень — це первинний неймсервер, поштова скринька відповідальної особи та п'ять чисел — serial і чотири таймери, — пояснені нижче.

Сім полів SOA-запису

Кожен SOA-запис містить ті самі сім полів у такому порядку:

MNAME — первинний неймсервер зони. Вторинні надсилають до цього хоста запити refresh і очікують від нього повідомлення NOTIFY. Це має бути хостнейм, що резолвиться, а не IP-адреса.

RNAME — поштова скринька особи, відповідальної за зону, записана з крапкою замість @: hostmaster.example.com означає [email protected]. Якщо локальна частина сама містить крапку, її екранують зворотним слешем.

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

Refresh — як часто, у секундах, вторинний запитує у первинного поточний serial. 3600 (одна година) — поширене значення. Коли налаштовано NOTIFY, цей таймер лише страхувальна сітка.

Retry — скільки вторинний чекає перед повторним запитом після невдалої спроби refresh. Він має бути коротшим за refresh; типово 900 (15 хвилин).

Expire — як довго вторинний продовжує обслуговувати зону після того, як востаннє зміг дістатися первинного. Коли цей таймер збігає, вторинний повністю перестає відповідати за зону. Звичне значення — 1209600 (два тижні).

Minimum — історично типовий TTL для записів; від часу RFC 2308 він визначає TTL негативного кешування: як довго резолвери можуть кешувати факт, що імені не існує (NXDOMAIN). Фактичний негативний TTL — менше з двох: це поле і TTL самого SOA-запису. Розумний діапазон — від 300 до 3600.

Як вторинні неймсервери використовують SOA

SOA-запис — це угода між вашим первинним неймсервером і кожним вторинним, що обслуговує вашу зону. Вторинний працює за таким циклом:

1. Кожні refresh секунд він запитує у первинного SOA-запис. 2. Він порівнює serial із відповіді із serial своєї копії. 3. Якщо serial первинного більший, він запитує передачу зони (AXFR чи IXFR) і встановлює нову копію. 4. Якщо запит не вдався, він повторює спробу через retry секунд. 5. Якщо він не може дістатися первинного протягом expire секунд, він відкидає зону і повертає SERVFAIL, доки первинний не повернеться.

Більшість первинних також надсилає повідомлення NOTIFY тієї ж миті, коли зона змінюється, тож вторинний перевіряє serial негайно, не чекаючи таймера refresh. Таймери все одно важливі: NOTIFY може загубитися, бути заблокованим фаєрволом або просто не бути налаштованим — і тоді refresh та retry лишаються єдиним, що тримає копії синхронізованими.

Саме тому хостований сервіс вторинного DNS може тримати ваш домен онлайн, поки первинний лежить: він уже має повну актуальну копію зони і продовжує відповідати за неї, поки не збіжить expire. Ширшу картину див. у Резервування DNS, а як працює сама передача — у Як працюють трансфери зон AXFR.

Серійний номер: формати й класичні помилки

Serial — це беззнакове 32-бітове ціле, і єдине правило, яке нав'язує протокол: новіша зона мусить мати більший serial, ніж попередня. Вторинні не дивляться на дати чи часові мітки файлів — лише на це число.

Serial на основі дати — найпоширеніша домовленість: YYYYMMDDnn, наприклад 2026082601 для першої зміни 26 серпня 2026 року. Останні дві цифри дозволяють до 100 правок на день, а число лишається читабельним у виводі dig.

Serial у форматі Unix-часу використовують багато керованих DNS-провайдерів і BIND, якщо налаштовано serial-format unixtime. Такі значення зростають автоматично й ніколи не збігаються.

Простий лічильник (1, 2, 3, …) також цілком припустимий. Формат — це домовленість, а не вимога.

Помилки, які справді ламають зони:

- Забути збільшити serial. Ви редагуєте файл зони, перезавантажуєте первинний, і він відповідає новими даними — але кожен вторинний досі бачить старий serial, вирішує, що нічого не змінилося, і безкінечно віддає застарілі записи. Це найпоширеніша причина ситуації «зміна працює на ns1, але не на ns2».

- Відкат назад. Перехід від великого serial на основі часової мітки до меншого на основі дати або відновлення старого файлу зони залишає вторинний із більшим serial, ніж у первинного. Він більше ніколи не виконає передачу, доки serial первинного його не наздожене. Арифметика серійних номерів (RFC 1982) дає вихід: додайте до serial 2^31 − 1 (2147483647), дайте кожному вторинному його підхопити, а тоді виставте потрібне вам значення — другий крок знову сприймається як збільшення.

- Редагування serial на вторинному. Вторинні ніколи не можна правити вручну: наступна передача перезапише копію, і ручна зміна зникне.

Як обрати значення refresh, retry, expire і minimum

RFC 1912 дає класичні рекомендації, і вони досі чинні. Розумні типові значення для зони, де налаштовано NOTIFY:

Refresh — 1 година (3600) Retry — 15 хвилин (900) Expire — 2 тижні (1209600) Minimum — від 5 хвилин до 1 години (300 – 3600)

Два правила, що важать більше за точні числа:

Retry має бути коротшим за refresh, і в ідеалі становити його малу частку — інакше невдалий refresh просто чекатиме наступного запланованого, а таймер retry не робитиме нічого.

Expire має бути довшим за найдовший простій первинного, який ви можете уявити. Якщо первинний лягає в п'ятницю ввечері і ніхто не помічає до понеділка, expire у 86400 (один день) означає, що кожен вторинний перестав відповідати ще в суботу — і весь сенс вторинних втрачено. Два тижні — звичний вибір і водночас нижня межа для робочої зони; RFC 1912 радить від двох до чотирьох тижнів.

Для minimum (негативне кешування) коротші значення дозволяють щойно створеному запису швидше стати видимим після того, як його запитували, поки він ще не існував; довші значення зменшують навантаження від повторних запитів імен, яких ніколи не буде. Не ставте його більшим за кілька годин — інакше одрук у хостнеймі кешуватиметься як неіснуючий цілу добу.

Діагностика застарілого вторинного за допомогою dig

Коли зміна в DNS видима на одному неймсервері, але не на іншому, serial у SOA підказує, де проблема. Запитайте кожен авторитетний сервер напряму:

dig @ns1.example.com example.com SOA +short
dig @ns2.example.com example.com SOA +short

Три можливі результати:

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

Менший serial на вторинному — вторинний знає зону, але не підхопив останню версію. Перевірте, чи serial на первинному справді збільшили, чи первинний дозволяє передачу з IP вторинного (allow-transfer / allow-axfr-ips), чи відкритий між ними TCP-порт 53 і чи надсилає первинний NOTIFY взагалі.

SERVFAIL або REFUSED від вторинного — зона або ніколи не передавалася, або її термін збіг. Подивіться в журналі вторинного, коли була остання успішна передача; якщо вона старіша за значення expire, вторинний коректно відкинув зону, і йому потрібен первинний, щоб завантажити її знову.

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

Приклад SOA-запису для типової зони

Повний SOA-запис у синтаксисі файлу зони з таймерами з таблиці вище:

example.com.  3600  IN  SOA  ns1.example.com. hostmaster.example.com. (
        2026082601  ; serial  (YYYYMMDDnn)
        3600        ; refresh (1 hour)
        900         ; retry   (15 minutes)
        1209600     ; expire  (2 weeks)
        300 )       ; minimum (negative caching TTL, 5 minutes)

3600 перед IN — це TTL самого SOA-запису (як довго резолвери можуть його кешувати). Він також обмежує зверху TTL негативного кешування: за 3600 тут і minimum 300 резолвери кешують відповіді NXDOMAIN 300 секунд — менше з двох значень.

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

Пов'язані гайди

SOA-запис — це механізм; ці гайди пояснюють, для чого він потрібен:

- Резервування DNS: чому це важливо і як його забезпечити - Як працюють трансфери зон AXFR - Як налаштувати вторинний DNS-сервер