Перейти до вмісту
> 💻 🧠 Код 1001 > 📑 Шпаргалки > 🖧 Повний, вичерпний посібник із DNS-записів: від основ до DNSSEC та автоматизації

🖧 Повний, вичерпний посібник із DNS-записів: від основ до DNSSEC та автоматизації

DNS (Domain Name System) — це фундаментальна система, на якій тримається весь сучасний інтернет. Це не просто “телефонна книга”, а складна, розподілена база даних, яка перетворює зрозумілі людині імена (наприклад, google.com) на технічні ідентифікатори, такі як IP-адреси, поштові сервери, політики безпеки та навіть географічні координати. Неправильна настройка DNS — одна з найпоширеніших причин недоступності сайтів, проблем із доставкою пошти та вразливостей безпеки.

Цей посібник об’єднує в собі всі аспекти DNS: від базових записів, які використовуються щодня, до складних механізмів, таких як DNSSEC і DANE. Ми розглянемо кожен тип запису, його призначення, синтаксис, практичні приклади, поширені помилки, команди для діагностики та готові шаблони для розгортання. Інформація структурована так, щоб ви могли використовувати цей матеріал як навчальний посібник, довідник адміністратора та контрольний список для продакшн-середовища.

In Questo Articolo
  1. 1. Термінологія
  2. 2. Детальний розбір усіх типів записів
  3. 3. Практичні рекомендації та нюанси налаштування
  4. 4. Повні шаблони зонних файлів (BIND style)
  5. 5. Крок за кроком налаштування поштового домену (PTR, SPF, DKIM, DMARC)
  6. 6. Команди для перевірки та налагодження DNS
  7. 7. Безпека та найкращі практики
  8. 8. Поширені помилки та як їх уникнути
  9. 9. Контрольний список перед продакшн-релізом або міграцією
  10. 10. Додаткові приклади та пояснення полів
  11. 11. Корисні сценарії
  12. 12. Готовий JSON для імпорту в панель провайдера
  13. Висновок

1. Термінологія

Перш ніж зануритися в типи записів, важливо зрозуміти ключові терміни, що використовуються в DNS. Це створить єдину мовну базу та допоможе уникнути плутанини.

  • DNS (Domain Name System): Система доменних імен. Глобальна розподілена база даних, яка перетворює доменні імена на IP-адреси та іншу пов’язану інформацію.
  • Доменне ім’я (Domain Name): Зрозуміла людині адреса в інтернеті, наприклад, example.com. Складається з міток, розділених крапками.
  • FQDN (Fully Qualified Domain Name): Повне доменне ім’я, яке однозначно визначає вузол у ієрархії DNS. Завжди закінчується крапкою, що позначає корінь DNS (наприклад, www.example.com.).
  • Зона (Zone): Адміністративна одиниця в DNS. Частина простору імен, якою керує один авторитетний сервер (або група серверів). Зазвичай відповідає домену або піддомену.
  • Зонний файл (Zone File): Текстовий файл, що зберігається на DNS-сервері, який містить усі записи для конкретної зони. Використовує синтаксис, визначений у стандарті BIND.
  • Запис (Resource Record, RR): Основна одиниця даних у DNS. Кожен запис має тип, ім’я, значення та TTL.
  • Тип запису (Record Type): Визначає, яку інформацію містить запис (наприклад, A, MX, TXT). Кожному типу відповідає унікальний числовий код (наприклад, 1 для A, 15 для MX).
  • TTL (Time To Live): Час життя запису, зазначений у секундах. Визначає, як довго резолвери та інші DNS-сервери можуть кешувати запис, перш ніж запитати його знову у авторитетного сервера.
  • Резолвер (Resolver): DNS-клієнт або сервер, який отримує запит від програми (наприклад, браузера) і виконує необхідні запити для отримання відповіді. Може бути рекурсивним (виконує повний ланцюжок запитів) або нерекурсивним.
  • Авторитетний сервер (Authoritative Server): DNS-сервер, який зберігає оригінальні записи для певної зони і відповідає за них. Відповідає на запити, використовуючи дані з зонного файлу.
  • Рекурсивний сервер (Recursive Server): Сервер, який отримує запит від клієнта і, якщо у нього немає відповіді в кеші, виконує ланцюжок запитів, починаючи з кореневих серверів, щоб знайти авторитетний сервер і отримати відповідь.
  • Кореневий сервер (Root Server): Один із 13 груп серверів (позначених буквами від a.root-servers.net. до m.root-servers.net.), які є відправною точкою для розв’язання будь-якого доменного імені. Вони знають, де знаходяться сервери для доменів верхнього рівня (TLD).
  • TLD (Top-Level Domain): Домен верхнього рівня. Остання частина доменного імені (наприклад, .com, .org, .ru, .io).
  • Реєстратор (Registrar): Компанія, через яку реєструються доменні імена. Керує інформацією про делегування (які NS-сервери обслуговують домен) у батьківській зоні (наприклад, у зоні .com для домену example.com).
  • Реєстрант (Registrant): Власник доменного імені.
  • Делегування (Delegation): Процес передачі управління піддоменом (або доменом) від батьківської зони дочірній. Здійснюється за допомогою NS-записів у батьківській зоні.
  • Glue Record (Клейовий запис): A або AAAA запис, який публікується у реєстратора для сервера імен, чиє доменне ім’я знаходиться всередині делегованої зони. Необхідний для розриву циклічної залежності.
  • SOA (Start of Authority): Запис, що містить адміністративну інформацію про зону, включаючи основний сервер, контакт адміністратора та параметри, що керують передачею зони вторинним серверам.
  • Серійний номер (Serial Number): Поле в записі SOA, яке вказує версію зони. Вторинні сервери використовують його для визначення необхідності оновлення.
  • Пряме розв’язання (Forward Resolution): Процес перетворення доменного імені на IP-адресу (наприклад, example.com → 192.0.2.1).
  • Зворотне розв’язання (Reverse Resolution): Процес перетворення IP-адреси на доменне ім’я (наприклад, 192.0.2.1 → example.com). Керується через зони in-addr.arpa (для IPv4) та ip6.arpa (для IPv6).
  • Кеш (Cache): Тимчасове сховище DNS-записів на резолвері або DNS-сервері для прискорення подальших запитів.
  • Кешування (Caching): Процес збереження DNS-записів у кеші.
  • Негативне кешування (Negative Caching): Кешування інформації про те, що запитуваний запис не існує.
  • RFC (Request for Comments): Офіційний документ, що описує стандарти, протоколи та процедури в інтернеті. Усі основні аспекти DNS описані в серії RFC.
  • BIND (Berkeley Internet Name Domain): Найпоширеніша реалізація DNS-сервера. Синтаксис його зонних файлів став де-факто стандартом.
  • MTA (Mail Transfer Agent): Поштовий сервер, відповідальний за передачу електронної пошти (наприклад, Postfix, Exim, Sendmail).
  • FCrDNS (Forward-Confirmed Reverse DNS): Механізм перевірки, при якому IP-адреса має PTR-запис, який розв’язується в доменне ім’я, а це доменне ім’я, у свою чергу, має A-запис, що веде назад до вихідної IP-адреси. Критично важливий для репутації поштових серверів.
  • DNSSEC (Domain Name System Security Extensions): Набір розширень, що додають криптографічний підпис до DNS-записів для забезпечення їх автентичності та цілісності.
  • DANE (DNS-based Authentication of Named Entities): Стандарт, що дозволяє прив’язувати TLS-сертифікати до DNS-імен за допомогою записів TLSA. Вимагає включення DNSSEC.
  • CAA (Certification Authority Authorization): Механізм, що дозволяє власнику домену вказати, які центри сертифікації (CA) мають право випускати для нього сертифікати.
  • SPF (Sender Policy Framework): Механізм, що дозволяє власнику домену вказати, які сервери мають право надсилати пошту від його імені.
  • DKIM (DomainKeys Identified Mail): Механізм, що дозволяє підписувати вихідні листи цифровим підписом, який одержувач може перевірити за допомогою публічного ключа, опублікованого в DNS.
  • DMARC (Domain-based Message Authentication, Reporting & Conformance): Політика, що визначає, як поштові сервери повинні обробляти листи, які не пройшли перевірку SPF або DKIM, і налаштовує надсилання звітів власнику домену.
  • ALIAS / ANAME: Нестандартні типи записів, які пропонують деякі DNS-провайдери. Дозволяють створювати псевдоніми для кореневого домену (apex), що неможливо за допомогою стандартного CNAME.
  • CNAME Flattening: Технологія, яку використовують деякі DNS-провайдери. Коли запитується CNAME на apex-домені, сервер автоматично розв’язує ланцюжок CNAME і повертає кінцеві A/AAAA записи клієнту, уникаючи порушення RFC.

2. Детальний розбір усіх типів записів

Усі приклади наведено у форматі BIND-style zone-file. Імена, що закінчуються крапкою (наприклад, example.com.), є FQDN. TTL (Time To Live) вказується в секундах і визначає, як довго запис може кешуватися резолверами.

A — Address Record (IPv4)

  • Призначення: Пов’язує доменне ім’я з 32-бітною IPv4-адресою. Найбазовіший і найчастіше використовуваний запис.
  • Формат: ім’я TTL IN A IPv4-адреса
  • Приклад:
    example.com. 3600 IN A 192.0.2.1 www.example.com. 3600 IN A 192.0.2.1
  • Коли використовується: Для вказівки IP-адреси веб-сервера, API, ігрового сервера або будь-якого іншого сервісу, доступного за IPv4.
  • Перевірка: dig +short example.com A
  • Найкращі практики:
    • Для кореневого домену (apex, @) використання A-запису — стандартна та коректна практика.
    • TTL слід вибирати залежно від стабільності IP-адреси. Для стабільних адрес — 3600 (1 година) або 86400 (1 день). Перед міграцією — зменшити до 300 (5 хвилин).

AAAA — IPv6 Address Record

  • Призначення: Аналог A-запису, але для 128-бітних IPv6-адрес. Критично важливий для майбутнього інтернету.
  • Формат: ім’я TTL IN AAAA IPv6-адреса
  • Приклад:
    example.com. 3600 IN AAAA 2001:db8::1
  • Коли використовується: Для забезпечення доступності сервісу за протоколом IPv6.
  • Перевірка: dig +short example.com AAAA

CNAME — Canonical Name Record

  • Призначення: Створює псевдонім (аліас) для доменного імені. Будь-який запит до CNAME автоматично перетворюється на запит до його цільового (канонічного) імені.
  • Формат: ім’я TTL IN CNAME ціль.
  • Приклад:
    www.example.com. 3600 IN CNAME example.com. blog.example.com. 3600 IN CNAME blog-hosting.example.net.
  • Важливі обмеження:
    • Конфлікт записів: Для одного й того ж імені не можна одночасно мати CNAME та будь-який інший запис (A, MX, TXT тощо). Це порушення RFC.
    • Apex-домен: Стандарт RFC забороняє використання CNAME для кореневого домену (наприклад, example.com.), оскільки він уже містить NS та SOA записи. Для вирішення цієї проблеми DNS-провайдери (Cloudflare, AWS Route 53) пропонують нестандартні розширення: ALIAS або ANAME, які на льоту розв’язують алиас у A/AAAA записи.
  • Практичне застосування: Підключення CDN (робимо www CNAME на адресу CDN), використання SaaS-платформ (блог, магазин).
  • Перевірка: dig +short www.example.com CNAME

MX — Mail Exchange Record

  • Призначення: Вказує сервери, які приймають вхідну пошту для домену. Запис містить пріоритет: чим менше число, тим вищий пріоритет.
  • Формат: ім’я TTL IN MX пріоритет поштовий_сервер.
  • Приклад:example.com. 3600 IN MX 10 mail1.example.com. example.com. 3600 IN MX 20 mail2.example.com.
    • Пошта буде спочатку надсилатися на mail1.example.com.. Якщо він недоступний, MTA (Mail Transfer Agent) спробує mail2.example.com..
  • Ключові вимоги:
    • Поштовий сервер (mail1.example.com.) повинен мати свій A або AAAA запис.
    • Для IP-адреси поштового сервера обов’язково має бути налаштований PTR-запис, і він має відповідати імені сервера, вказаному в MX. Це критично важливо для репутації сервера та доставки пошти.
  • Перевірка: dig +short example.com MX

TXT — Text Record

  • Призначення: Зберігає довільні текстові дані. Широко використовується для політик безпеки електронної пошти (SPF, DKIM, DMARC), верифікації власності доменом (Google, Microsoft, Yandex) та інших цілей.
  • Формат: ім’я TTL IN TXT "текст"
  • Приклади:
    • SPF (Sender Policy Framework): Визначає, які сервери мають право надсилати пошту від імені домену. example.com. 3600 IN TXT "v=spf1 ip4:192.0.2.0/24 include:_spf.google.com ~all"
      • ip4:192.0.2.0/24 — дозволяє всю підмережу.
      • include:_spf.google.com — включає правила з зони Google (для Gmail).
      • ~all — “м’яка” відмова для всіх інших (softfail). -all — строга відмова (fail).
    • DKIM (DomainKeys Identified Mail): Публікує відкритий ключ для перевірки цифрового підпису, доданого до вихідних листів. Зазвичай створюється для піддомену виду селектор._domainkey.домен. default._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQ..."
      • v=DKIM1 — версія.
      • k=rsa — тип ключа.
      • p=... — сам відкритий ключ у форматі base64.
    • DMARC (Domain-based Message Authentication, Reporting & Conformance): Задає політику обробки листів, які не пройшли перевірку SPF або DKIM, і налаштовує надсилання звітів. _dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:forensics@example.com; pct=100"
      • p=reject — відхиляти листи, які не пройшли перевірку.
      • rua=mailto:... — адреса для агрегованих звітів.
      • ruf=mailto:... — адреса для звітів про конкретні збої (forensic).
      • pct=100 — застосовувати політику до 100% листів.
    • Верифікація: example.com. 3600 IN TXT "google-site-verification=abc123..."
  • Примітки:
    • Якщо текстовий рядок довший за 255 байт, його можна розділити на кілька частин у зонному файлі, уклавши кожну в лапки. DNS-сервер автоматично їх склеїть.
      example.com. IN TXT ("v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; " "pct=100; fo=1")
  • Перевірка: dig +short example.com TXT

NS — Name Server Record

  • Призначення: Вказує DNS-сервери, які є авторитетними для даної зони. Ці записи — основа для делегування управління доменом.
  • Формат: ім’я TTL IN NS сервер_імен.
  • Приклад:
    example.com. 3600 IN NS ns1.example.net. example.com. 3600 IN NS ns2.example.net.
  • Важливі моменти:
    • Записи NS у зоні повинні точно збігатися з серверами імен, вказаними у реєстратора домену.
    • Glue Records: Якщо сервер імен (наприклад, ns1.example.com.) знаходиться всередині тієї ж зони, яку він обслуговує (example.com.), виникає циклічна залежність. Щоб її розірвати, у реєстратора необхідно додати “клеєві” (glue) записи — A або AAAA записи для цих серверів імен.
  • Перевірка: dig +short example.com NS

SOA — Start of Authority Record

  • Призначення: Головний службовий запис DNS-зони. Містить інформацію про основний сервер, адміністратора, а також параметри, що керують синхронізацією між основним і вторинними серверами.
  • Формат:
    ім’я TTL IN SOA первинний_сервер. email_адміністратора. ( серійний_номер ; Serial інтервал_оновлення ; Refresh інтервал_повтору ; Retry термін_придатності ; Expire мін_TTL ) ; Minimum TTL
  • Приклад:
    example.com. 3600 IN SOA ns1.example.net. admin.example.com. ( 2025092201 ; Serial (YYYYMMDDNN) 7200 ; Refresh (2 години) 3600 ; Retry (1 година) 1209600 ; Expire (14 днів) 86400 ) ; Minimum TTL (1 день)
  • Пояснення полів:
    • Serial: Версія зони. Крайне важливо збільшувати це число при кожній зміні зони. Вторинні сервери порівнюють свій Serial з Serial на первинному сервері і, якщо він менший, запитують оновлення. Рекомендований формат: YYYYMMDDNN (рік, місяць, день, номер редакції за день).
    • Refresh: Інтервал (у секундах), через який вторинні сервери повинні перевіряти первинний сервер на наявність оновлень.
    • Retry: Інтервал, через який вторинний сервер повинен повторити спробу, якщо перша спроба оновлення не вдалася.
    • Expire: Час (у секундах), після якого вторинний сервер перестане відповідати на запити, якщо не зможе зв’язатися з первинним сервером. Зона вважається “застарілою”.
    • Minimum TTL: Спочатку задавав мінімальний TTL для всіх записів у зоні. Зараз частіше використовується як TTL для негативного кешування (як довго кешувати відповідь “запис не знайдено”).
  • Перевірка: dig +short example.com SOA

PTR — Pointer Record (Reverse DNS)

  • Призначення: Забезпечує зворотне розв’язання — перетворює IP-адресу на доменне ім’я. Керується власником IP-адреси (ISP, хостинг-провайдер), а не власником домену.
  • Формат для IPv4: IP-адреса записується в зворотному порядку, і до неї додається суфікс .in-addr.arpa..
    • IP 192.0.2.5 → 5.2.0.192.in-addr.arpa.
  • Формат для IPv6: Кожна 4-бітна частина (nibble) адреси записується в зворотному порядку, і додається суфікс .ip6.arpa..
    • IPv6 2001:db8::1 → 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
  • Приклад (IPv4):
    5.2.0.192.in-addr.arpa. 3600 IN PTR mail.example.com.
  • Практичне значення: Критично важливо для поштових серверів. Більшість поштових систем перевіряють, щоб PTR-запис IP-адреси відправника збігався з ім’ям, яке сервер представляє в команді HELO/EHLO. Невідповідність — часта причина потрапляння листів у спам.
  • Перевірка: dig -x 192.0.2.5 +short або host 192.0.2.5

SRV — Service Record

  • Призначення: Вказує розташування серверів для конкретних сервісів, включаючи протокол і порт. Дозволяє клієнтам автоматично знаходити потрібний сервер.
  • Формат імені:_сервіс._протокол.домен.
    • Сервіс: sip, xmpp-server, _minecraft тощо.
    • Протокол: tcp, udp.
  • Формат запису: ім’я TTL IN SRV пріоритет вага порт ціль.
  • Приклад:
    _sip._tcp.example.com. 3600 IN SRV 10 60 5060 sipserver.example.com. _minecraft._tcp.example.com. 3600 IN SRV 5 0 25565 mc1.example.com.
  • Пояснення полів:
    • Priority (Пріоритет): Чим менше число, тим вищий пріоритет. Клієнт спочатку спробує підключитися до сервера з найменшим пріоритетом.
    • Weight (Вага): Використовується для балансування навантаження між серверами з однаковим пріоритетом. Ймовірність вибору сервера пропорційна його вазі. Якщо всі ваги однакові, вибір відбувається випадково.
    • Port (Порт): Порт, на якому працює сервіс.
    • Target (Ціль): FQDN сервера, на який слід направити запит. Цей сервер повинен мати A або AAAA запис.
  • Застосування: VoIP (SIP), миттєві повідомлення (XMPP), ігри (Minecraft), каталоги (LDAP).
  • Перевірка: dig +short _sip._tcp.example.com SRV

CAA — Certification Authority Authorization

  • Призначення: Дозволяє власнику домену вказати, які центри сертифікації (CA) мають право випускати SSL/TLS-сертифікати для цього домену. Це важливий механізм безпеки, що запобігає несанкціонованому випуску сертифікатів.
  • Формат: ім’я TTL IN CAA прапорці тег значення
  • Приклад:
    example.com. 3600 IN CAA 0 issue "letsencrypt.org" example.com. 3600 IN CAA 0 iodef "mailto:security@example.com"
  • Пояснення:
    • Прапорці: Зазвичай 0. Прапорець 128 (critical) означає, що CA, яка не розуміє цей тег, повинна відмовитися від випуску сертифіката.
    • Теги:
      • issue: Дозволяє вказаному CA випускати сертифікати. Порожнє значення (;) забороняє випуск усім.
      • issuewild: Дозволяє випуск wildcard-сертифікатів (*.example.com).
      • iodef: URL (зазвичай mailto: або http(s):) для надсилання звітів про спроби порушення політики CAA.
  • Перевірка: dig +short example.com CAA

NAPTR — Naming Authority Pointer Record

  • Призначення: Використовується для складних правил переписування (rewriting) імен і URI. Найчастіше застосовується в телекомунікаційних системах (ENUM для перетворення телефонних номерів у SIP URI) і для динамічного виявлення сервісів.
  • Формат: ім’я TTL IN NAPTR порядок перевага прапорці сервіс регулярний_вираз заміна.
  • Приклад (спрощений для ENUM):
    4.3.2.1.5.5.5.1.e164.arpa. IN NAPTR 100 10 "U" "E2U+sip" "!^.*$!sip:info@example.com!" .
  • Пояснення:
    • Order (Порядок): Обробляється від меншого до більшого.
    • Preference (Перевага): Аналог weight в SRV для записів з однаковим order.
    • Flags: U означає, що результат — URI (наприклад, sip:).
    • Service: Тип сервісу (наприклад, E2U+sip — перетворення в SIP URI).
    • Regexp: Регулярний вираз для перетворення вхідного рядка.
    • Replacement: Альтернатива регулярному виразу (зазвичай порожня, якщо використовується regexp).
  • Застосування: Складні сценарії маршрутизації в VoIP, ENUM.

TLSA — TLSA Certificate Association Record (DANE)

  • Призначення: Прив’язує TLS-сертифікат (або його частину) до DNS-імені за допомогою запису в DNS. Це частина стандарту DANE (DNS-based Authentication of Named Entities). Вимагає включення DNSSEC для забезпечення довіри, інакше запис можна підробити.
  • Формат імені: _порт._протокол.ім’я.
  • Формат запису: ім’я TTL IN TLSA використання селектор тип_зіставлення дані
  • Приклад:
    _443._tcp.www.example.com. 3600 IN TLSA 3 1 1 d2abde...f21
  • Пояснення полів:
    • Usage (Використання):
      • 3 (DANE-EE): Сертифікат кінцевої точки (end entity). Найпоширеніший.
      • 1 (PKIX-EE): Сертифікат кінцевої точки, повинен бути підписаний довіреним CA.
      • 2 (DANE-TA): Довірений (trusted) сертифікат удостовірного центру.
      • 0 (PKIX-TA): Сертифікат CA, повинен бути в ланцюжку довіри.
    • Selector (Селектор):
      • 0: Повний сертифікат.
      • 1: Лише відкритий ключ сертифіката.
    • Matching Type (Тип зіставлення):
      • 0: Точні дані (не використовується).
      • 1: SHA-256 хеш.
      • 2: SHA-512 хеш.
    • Data: Хеш сертифіката або його відкритого ключа в hex-форматі.
  • Застосування: Підвищення безпеки TLS, особливо в середовищах, де не можна довіряти публічним CA.
  • Перевірка: dig +short _443._tcp.www.example.com. TLSA

Записи DNSSEC (DNSKEY, DS, RRSIG, NSEC, NSEC3)

DNSSEC (DNS Security Extensions) — це набір розширень, що додають криптографічний підпис до DNS-записів для захисту від підробки (спуфінгу) та атак “отруєння кешу”.

  • Загальний принцип: Зона підписується приватним ключем. Публічний ключ публікується в записі DNSKEY. Для створення ланцюжка довіри хеш цього ключа (DS-запис) публікується в батьківській зоні (наприклад, для example.com — в зоні .com). Клієнти, що підтримують DNSSEC, можуть перевірити підпис (RRSIG) кожної записи, використовуючи відкритий ключ, і переконатися у її автентичності.
  • DNSKEY: Публічний ключ зони.
    • Приклад:example.com. 3600 IN DNSKEY 257 3 13 AwEAAa3d...9QAB
      • 257 — прапорці (257 = KSK, 256 = ZSK).
      • 3 — протокол (завжди 3).
      • 13 — алгоритм (13 = ECDSA/SHA256).
      • Останнє поле — ключ у base64.
  • DS (Delegation Signer): Хеш відкритого ключа (DNSKEY) дочірньої зони, який публікується в батьківській зоні для створення ланцюжка довіри.
    • Приклад:example.com. 3600 IN DS 54517 13 2 84C8...D34F
      • 54517 — Key Tag (ідентифікатор ключа).
      • 13 — Алгоритм.
      • 2 — Тип дайджесту (SHA-256).
      • Останнє поле — хеш у hex.
  • RRSIG (Resource Record Signature): Цифровий підпис для набору DNS-записів.
    • Приклад (підпис для A-запису):example.com. 3600 IN RRSIG A 13 2 3600 20251001000000 20250901000000 54517 example.com. oNvL...7Q==
      • A — тип записів, які підписані.
      • 13 — алгоритм.
      • 2 — кількість міток у імені.
      • 3600 — оригінальний TTL.
      • 20251001000000 — час закінчення дії підпису.
      • 20250901000000 — час початку дії підпису.
      • 54517 — Key Tag підписуючого ключа.
      • example.com. — ім’я підписувача.
      • Останнє поле — підпис у base64.
  • NSEC / NSEC3: Використовуються для автентифікації негативних відповідей (доведення того, що запис з таким ім’ям або типом не існує). NSEC3 додатково хешує імена для захисту від “вигулювання зони” (zone walking).
  • Включення DNSSEC: Це окремий, складний процес:
    1. Генерація пар ключів (KSK і ZSK) на DNS-сервері.
    2. Публікація DNSKEY записів у зоні.
    3. Генерація DS-запису з KSK.
    4. Публікація DS-запису у реєстратора домену (у батьківській зоні).
    5. Включення підписування зони на DNS-сервері (автоматична генерація RRSIG, NSEC/NSEC3).
    6. Тестування за допомогою dig +dnssec та онлайн-інструментів (наприклад, Verisign DNSSEC Debugger).
  • Перевірка:
    • dig +dnssec example.com A (покаже RRSIG для A-запису, якщо DNSSEC увімкнено і працює).
    • dig +short example.com DNSKEY
    • dig +short example.com DS

SSHFP — SSH Public Key Fingerprint

  • Призначення: Публікує хеш (відбиток) SSH-ключа хоста в DNS. Клієнти SSH можуть використовувати цей запис для автоматичної перевірки автентичності сервера при першому підключенні, запобігаючи атакам “людина посередині” (MITM). Рекомендується використовувати з DNSSEC для гарантії автентичності запису.
  • Формат: ім’я TTL IN SSHFP алгоритм тип_дайджесту відбиток
  • Приклад:
    example.com. 3600 IN SSHFP 4 2 356a192b7913b04c54574d18c28d46e6395428ab
  • Пояснення:
    • Алгоритм:
      • 1 — RSA
      • 2 — DSA
      • 3 — ECDSA
      • 4 — ED25519
    • Тип дайджесту:
      • 1 — SHA-1
      • 2 — SHA-256
    • Відбиток: Хеш відкритого ключа в hex-форматі.
  • Генерація: На сервері можна згенерувати запис командою: ssh-keygen -r example.com
  • Перевірка: dig +short example.com SSHFP

Рідкісні та службові записи

  • HINFO (Host Information): Зберігає інформацію про тип процесора та операційну систему хоста. Не рекомендується до використання, оскільки розкриває потенційно чутливу інформацію про систему.
    • Приклад: server1.example.com. 3600 IN HINFO "Intel Xeon" "Ubuntu 22.04"
  • LOC (Location): Зберігає географічні координати (широта, довгота, висота) хоста.
    • Приклад: example.com. 3600 IN LOC 55 45 21.000 N 37 37 03.000 E 15m
  • RP (Responsible Person): Вказує контактну особу, відповідальну за зону. Email вказується у форматі hostname (крапка замість @).
    • Приклад: example.com. 3600 IN RP admin.example.com. txt-record.example.com.
  • SPF (застаріла): Раніше існувала як окремий тип запису, але зараз повністю замінена TXT. Не слід використовувати.
    • Приклад (не використовувати): example.com. IN SPF "v=spf1 ..."

3. Практичні рекомендації та нюанси налаштування

  • Керування TTL:
    • Стандартне значення: 3600 секунд (1 година) — хороший баланс між продуктивністю (кешировання) та гнучкістю.
    • Перед міграцією: За 24-72 години до планованої зміни (наприклад, зміни IP-адреси) зменшіть TTL для відповідних записів до 300 секунд (5 хвилин). Це скоротить час поширення змін.
    • Після міграції: Коли зміни стабілізуються, поверніть TTL до більш високого значення (наприклад, 3600 або 86400) для зменшення навантаження на DNS-сервери.
  • SOA Serial:
    • Обов’язково збільшуйте серійний номер при кожній зміні зони. Якщо цього не зробити, вторинні сервери не дізнаються про оновлення.
    • Рекомендований формат: YYYYMMDDNN (наприклад, 2024051701). Це наочно і дозволяє легко відстежувати, коли було останнє зміна.
  • CNAME на Apex (кореневому домені):
    • Проблема: Стандарт RFC забороняє CNAME на apex-домені (наприклад, example.com.), тому що він конфліктує з іншими обов’язковими записами (NS, SOA).
    • Рішення: Використовуйте функції, надані вашим DNS-провайдером:
      • ALIAS/ANAME: Нестандартні типи записів, які поводяться як CNAME, але розв’язуються на стороні DNS-сервера провайдера в A/AAAA записи для відповіді клієнту. Це дозволяє використовувати алиаси на apex.
      • CNAME Flattening: Технологія (наприклад, у Cloudflare), при якій CNAME на apex автоматично “вирівнюється” — DNS-сервер повертає A/AAAA записи цільового хоста замість CNAME.
  • Glue Records:
    • Коли потрібні: Якщо ваші сервери імен (наприклад, ns1.example.com.) знаходяться в тій же зоні, яку вони обслуговують (example.com.).
    • Що робити: У реєстратора домену знайдіть розділ для налаштування glue-записів і додайте A (і/або AAAA) записи для ваших серверів імен. Це розриває циклічну залежність.
  • Налаштування PTR для пошти:
    • Вимога: IP-адреса вашого поштового сервера повинна мати PTR-запис, який розв’язується в його повне доменне ім’я (FQDN, наприклад, mail.example.com.).
    • Узгодженість: Ім’я, яке поштовий сервер передає в команді HELO/EHLO, повинно збігатися з ім’ям з PTR-запису, а це ім’я, у свою чергу, повинно мати A-запис, що веде назад до тієї ж IP-адреси. Це називається “Forward-Confirmed Reverse DNS” (FCrDNS) і критично важливо для репутації.
    • Де налаштовувати: У вашого хостинг-провайдера або власника IP-адреси, а не в DNS-зоні вашого домену.
  • Розбиття довгих TXT-записів:
    • Якщо рядок у TXT-записі перевищує 255 байт, її необхідно розділити на кілька частин у зонному файлі. Кожна частина укладається в лапки, і DNS-сервер автоматично їх об’єднує.
    • Приклад:
      example.com. IN TXT ( "v=DMARC1; p=reject; rua=mailto:dmarc@example.com,mailto:dmarc@thirdparty.com; " "ruf=mailto:forensics@example.com; fo=1; adkim=s; aspf=s; pct=100" )

4. Повні шаблони зонних файлів (BIND style)

Нижче наведено готові шаблони для трьох поширених сценаріїв. Замініть example.com, example.net, IP-адреси та ключі на свої значення.

a) Простий сайт (статичний, без пошти)

$TTL 3600
@   IN SOA ns1.hosting.net. hostmaster.example.com. (
        2025092201 ; serial (YYYYMMDDNN)
        7200       ; refresh (2 години)
        3600       ; retry (1 година)
        1209600    ; expire (14 днів)
        86400 )    ; minimum TTL (1 день)

; Авторитетні сервери імен
@       IN NS   ns1.hosting.net.
@       IN NS   ns2.hosting.net.

; Веб-сервер (IPv4 та IPv6)
@       IN A    192.0.2.10
@       IN AAAA 2001:db8::10

; Піддомен WWW (аліас до apex)
www     IN CNAME @

; Безпека: Обмежити центри сертифікації
@       IN CAA  0 issue "letsencrypt.org"
@       IN CAA  0 iodef "mailto:security@example.com"

b) Сайт + власний поштовий сервер

$TTL 3600
@   IN SOA ns1.example.net. admin.example.com. (
        2025092201 ; serial
        7200       ; refresh
        3600       ; retry
        1209600    ; expire
        86400 )    ; minimum

; Сервери імен
@       IN NS   ns1.example.net.
@       IN NS   ns2.example.net.

; --- Веб-розділ ---
@       IN A    192.0.2.10
www     IN CNAME @

; --- Поштовий розділ ---
; A-запис для поштового сервера
mail    IN A    192.0.2.20

; MX-запис, що вказує на поштовий сервер
@       IN MX   10 mail.example.com.

; --- Аутентифікація електронної пошти ---
; SPF: Дозволити IP поштового сервера та Google Workspace
@       IN TXT  "v=spf1 ip4:192.0.2.20 include:_spf.google.com ~all"

; DKIM: Публічний ключ для селектора 'default'
default._domainkey IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQ..."

; DMARC: Політика карантину для збоїв та надсилання звітів
_dmarc  IN TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100"

; --- Безпека ---
@       IN CAA  0 issue "letsencrypt.org"

c) Сайт + CDN + Пошта + DNSSEC (комплексний приклад)

$TTL 300 ; Менший TTL для гнучкості з CDN
@   IN SOA ns1.example.net. hostmaster.example.com. (
        2025092201 ; serial
        7200       ; refresh
        3600       ; retry
        1209600    ; expire
        3600 )     ; minimum (також використовується для негативного кешування)

; Сервери імен
@       IN NS   ns1.example.net.
@       IN NS   ns2.example.net.

; --- Веб-розділ (з CDN) ---
; Кореневий домен: Використовуйте ALIAS/ANAME (залежно від провайдера) для вказівки на походження або край CDN
; Якщо ваш провайдер підтримує ALIAS:
; @     IN ALIAS origin.examplehost.net.
; Якщо використовуєте CNAME flattening для apex (наприклад, Cloudflare):
@       IN A    192.0.2.10 ; Тимчасова або резервна IP, часто керована провайдером

; Піддомен WWW: CNAME до провайдера CDN
www     IN CNAME cdn-provider.example.net.

; --- Поштовий розділ ---
mail    IN A    192.0.2.20
@       IN MX   10 mail.example.com.

; --- Аутентифікація електронної пошти ---
@       IN TXT  "v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all"
default._domainkey IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQ..."
_dmarc  IN TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:abuse@example.com; pct=100"

; --- Безпека ---
@       IN CAA  0 issue "letsencrypt.org"
@       IN CAA  0 issuewild "letsencrypt.org"
@       IN CAA  0 iodef "mailto:security@example.com"

; --- DNSSEC (Приклад ключів - ЗАМІНИТИ НА СВОЇ) ---
; Записи DNSKEY (зазвичай генеруються автоматично DNS-сервером під час підпису)
@       IN DNSKEY 257 3 13 ( ; KSK
        AwEAAbOv...QAB )
@       IN DNSKEY 256 3 13 ( ; ZSK
        AwEAAa3d...9QAB )

; Записи RRSIG генеруються автоматично DNS-сервером під час підпису і не додаються вручну до зонного файлу.
; Записи NSEC/NSEC3 також генеруються автоматично.

; --- Додаткові сервіси (Приклад) ---
; SRV-запис для SIP-сервісу
_sip._tcp IN SRV 10 50 5060 sip1.example.com.

5. Крок за кроком налаштування поштового домену (PTR, SPF, DKIM, DMARC)

Налаштування пошти — це комплексне завдання. Дотримуйтесь цих кроків для забезпечення максимальної доставності та захисту від спаму.

Крок 1: Налаштування A/AAAA для поштового сервера
Переконайтеся, що ваш поштовий сервер має запис A (і бажано AAAA).

mail.example.com. 3600 IN A 192.0.2.20

Крок 2: Налаштування MX-записів
Вкажіть, що пошта для example.com повинна доставлятися на mail.example.com..

example.com. 3600 IN MX 10 mail.example.com.

Крок 3: Налаштування PTR (зворотного DNS)
Це найважливіший і часто пропущений крок. Зверніться до вашого хостинг-провайдера або власника IP-адреси (192.0.2.20) і запросіть налаштування PTR-запису, щоб він вказував на mail.example.com..

  • Перевірка: dig -x 192.0.2.20 +short повинен повернути mail.example.com..

Крок 4: Налаштування SPF (через TXT)
Визначте, які сервери можуть надсилати пошту від імені example.com. Включіть свій сервер і будь-які сторонні сервіси (Gmail, SendGrid тощо).

example.com. 3600 IN TXT "v=spf1 ip4:192.0.2.20 include:_spf.google.com -all"
  • Почніть з ~all (softfail) для тестування, потім перейдіть на -all (hard fail).

Крок 5: Налаштування DKIM

  1. Згенеруйте пару ключів (приватний і публічний) на вашому поштовому сервері (MTA). Виберіть “селектор” (наприклад, default, 202405).
  2. Налаштуйте MTA на підпис вихідних листів за допомогою приватного ключа та вибраного селектора.
  3. Опублікуйте публічний ключ у DNS у вигляді TXT-запису для піддомену селектор._domainkey.example.com..
    default._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQ..."

Крок 6: Налаштування DMARC
Визначте політику обробки листів, які не пройшли перевірку SPF/DKIM, і налаштуйте отримання звітів.

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; ruf=mailto:forensics@example.com; pct=100"
  • Стратегія розгортання:
    1. Почніть з p=none — листи не блокуються, ви лише отримуєте звіти.
    2. Аналізуйте звіти, виправляйте помилки в SPF/DKIM.
    3. Перейдіть на p=quarantine — підозрілі листи потрапляють у спам.
    4. Перейдіть на p=reject — підозрілі листи відхиляються.

Додаткові поради:

  • Переконайтеся, що ім’я в команді HELO/EHLO, яку ваш поштовий сервер надсилає при підключенні, збігається з ім’ям з PTR-запису (mail.example.com.).
  • Використовуйте онлайн-інструменти для перевірки конфігурації: mail-tester.com, mxtoolbox.com, dmarcian.com.

6. Команди для перевірки та налагодження DNS

Інструменти командного рядка — незамінні для адміністратора.

  • dig (Domain Information Groper) — найпотужніший і рекомендований інструмент.
    • Базові запити:
      • dig +short example.com A — отримати лише IPv4-адресу.
      • dig +short example.com AAAA — отримати лише IPv6-адресу.
      • dig +short example.com MX — отримати MX-записи.
      • dig +short example.com TXT — отримати TXT-записи (SPF, DKIM, DMARC).
      • dig +short www.example.com CNAME — отримати CNAME.
      • dig +short _sip._tcp.example.com SRV — отримати SRV-запис.
    • Зворотний DNS:
      • dig -x 192.0.2.1 +short — отримати PTR для IP.
    • Трасування делегування:
      • dig +trace example.com — показує весь шлях від кореневих серверів до авторитетних серверів вашої зони. Ідеально підходить для діагностики проблем із делегуванням.
    • Запит до конкретного сервера:
      • dig @ns1.example.net example.com SOA — запитати SOA-запис у конкретного сервера імен.
    • Перевірка DNSSEC:
      • dig +dnssec example.com A — виконати запит із прапором DO (DNSSEC OK) і показати RRSIG-записи, якщо вони є.
      • dig +short example.com DNSKEY — отримати DNSKEY-записи.
      • dig +short example.com DS — отримати DS-запис (із батьківської зони).
    • Перевірка TLSA (DANE):
      • dig +short _443._tcp.www.example.com. TLSA
    • Перевірка SSHFP:
      • dig +short example.com SSHFP
  • nslookup — старий, але ще зустрічається інструмент.
    • nslookup -type=MX example.com
    • nslookup -type=TXT example.com
    • nslookup 192.0.2.1 (для PTR)
  • host — простий і зручний для базових запитів.
    • host -t A example.com
    • host -t MX example.com
    • host -t TXT example.com
    • host 192.0.2.1 (для PTR)
    • host -t sshfp example.com

7. Безпека та найкращі практики

  • DNSSEC: Увімкніть DNSSEC для критично важливих доменів. Це захищає ваших користувачів від підроблених DNS-відповідей. Почніть із тестового домену, щоб освоїти процедуру (генерація ключів, публікація DS у реєстратора). Використовуйте онлайн-валідатори для перевірки.
  • CAA: Завжди налаштовуйте CAA-записи. Це простий і ефективний спосіб запобігти несанкціонованому випуску сертифікатів для вашого домену. Вкажіть лише ті CA, якими ви користуєтеся (наприклад, letsencrypt.org).
  • Керування ключами DKIM: Регулярно (наприклад, раз на рік) генеруйте нові пари ключів DKIM. Опублікуйте новий публічний ключ у DNS, налаштуйте MTA на використання нового селектора, а через кілька тижнів (переконавшись, що всі старі листи з підписом старого ключа оброблені) видаліть старий TXT-запис.
  • Конфіденційність: Не публікуйте HINFO-записи, оскільки вони розкривають інформацію про обладнання та ПЗ, що може бути корисною для зловмисників.
  • ANY-запити: Багато публічних DNS-резолверів (наприклад, Google Public DNS, Cloudflare) більше не обробляють ANY-запити через їх використання в DDoS-атаках. Не покладайтеся на них.

8. Поширені помилки та як їх уникнути

  1. CNAME конфліктує з іншими записами: Неможливо мати CNAME і, наприклад, A або MX для одного й того ж імені. Рішення: Перегляньте структуру зони. Використовуйте A-записи або ALIAS/ANAME для apex.
  2. Відсутність PTR для поштового сервера: Це головна причина, чому пошта потрапляє у спам. Рішення: Завжди налаштовуйте PTR у вашого хостинг-провайдера.
  3. Незмінний SOA Serial: Якщо не збільшувати серійний номер, вторинні сервери не дізнаються про оновлення. Рішення: Завжди збільшуйте Serial після будь-якої зміни в зоні. Автоматизуйте цей процес, якщо можливо.
  4. Неправильне форматування довгих TXT-записів: Якщо рядок довша за 255 байт і не розділена на частини, вона може бути обрізана або викликати помилку. Рішення: Завжди розділяйте довгі рядки в TXT-записах, уклавши кожну частину в лапки.
  5. Неправильний DS при включенні DNSSEC: Якщо DS-запис, опублікований у реєстратора, не відповідає вашому DNSKEY, зона стане “недовіреною”, і клієнти з увімкненим DNSSEC не зможуть отримати з неї записи. Рішення: Уважно слідкуйте за інструкціями вашого DNS-сервера та реєстратора. Двічі перевіряйте хеші.
  6. Високий TTL перед міграцією: Якщо TTL великий (наприклад, 86400), після зміни IP-адреси користувачі будуть потрапляти на стару адресу протягом доби. Рішення: Завжди знижуйте TTL за день-два до планованої міграції.
  7. CNAME на apex-домені: Пряме використання CNAME для example.com. порушує RFC і може викликати непередбачувану поведінку. Рішення: Використовуйте ALIAS/ANAME або CNAME flattening, надані вашим DNS-провайдером.

9. Контрольний список перед продакшн-релізом або міграцією

Використовуйте цей список для фінальної перевірки перед запуском або перенесенням сайту/сервісу.

  • [ ] Основні записи: A/AAAA для всіх ключових хостів (веб, пошта) налаштовані і ведуть на правильні IP-адреси.
  • [ ] Пошта: MX-записи налаштовані і вказують на хости, що мають A/AAAA записи.
  • [ ] Зворотний DNS: PTR-записи для всіх IP-адрес поштових серверів налаштовані і коректні (перевірено через dig -x).
  • [ ] SPF: TXT-запис SPF налаштований, включає всі дозволені джерела і має правильний механізм завершення (-all або ~all).
  • [ ] DKIM: Публічний ключ опублікований у DNS, MTA налаштований на підпис листів. Підпис перевірено на тестовому листі.
  • [ ] DMARC: TXT-запис DMARC опублікований. Для нового розгортання рекомендується починати з p=none.
  • [ ] Сервери імен: NS-записи в зоні збігаються з серверами, вказаними у реєстратора. Налаштовані glue-записи, якщо необхідно.
  • [ ] SOA Serial: Серійний номер був збільшений після всіх останніх змін.
  • [ ] CAA: Налаштовані CAA-записи для обмеження випуску сертифікатів.
  • [ ] TTL: TTL був зменшений заздалегідь (якщо планувалася міграція).
  • [ ] Перевірка: Виконані перевірки за допомогою dig +trace, dig MX, dig TXT та онлайн-інструментів (наприклад, MXToolbox).
  • [ ] DNSSEC (якщо увімкнено): DS-запис коректно доданий у реєстратора, перевірки DNSSEC проходять успішно.
  • [ ] Резервне копіювання: Експорт поточної зони збережено.
  • [ ] План відкату: Чітко прописані кроки для відкату змін у разі збою.
  • [ ] Моніторинг: Налаштовані системи моніторингу для відстеження доступності DNS-серверів і змін у зоні.

10. Додаткові приклади та пояснення полів

  • SRV — Глибоке занурення:_xmpp-client._tcp.example.com. 3600 IN SRV 5 20 5222 xmpp1.example.com. _xmpp-client._tcp.example.com. 3600 IN SRV 5 30 5222 xmpp2.example.com. _xmpp-client._tcp.example.com. 3600 IN SRV 10 100 5222 backup.example.com.
    • Клієнт спочатку звернеться до серверів з пріоритетом 5 (xmpp1 і xmpp2).
    • Між xmpp1 і xmpp2 вибір відбуватиметься пропорційно їх вазі: xmpp1 має 40% шансу (20/(20+30)), xmpp2 — 60% (30/(20+30)).
    • Сервер backup.example.com. (пріоритет 10) буде використовуватися лише якщо обидва сервери з пріоритетом 5 недоступні.
  • TLSA — Розшифровка прикладу:_443._tcp.www.example.com. IN TLSA 3 1 1 d2abde...f21
    • 3 (DANE-EE): Клієнт повинен використовувати саме цей сертифікат (або його відкритий ключ), незалежно від ланцюжка довіри CA.
    • 1 (Selector): У записі зберігається хеш не всього сертифіката, а лише його відкритого ключа. Це зручніше, оскільки при перевиданні сертифіката з тим же ключем змінювати TLSA-запис не потрібно.
    • 1 (Matching Type): Використовується хеш SHA-256.
  • SSHFP — Розшифровка прикладу:
    example.com. IN SSHFP 4 2 356a192b7913b04c54574d18c28d46e6395428ab
    • 4: Алгоритм — ED25519 (сучасний і безпечний).
    • 2: Тип дайджесту — SHA-256.
    • 356a19...28ab: SHA-256 хеш відкритого ключа ED25519.

11. Корисні сценарії

  • Підключення сайту до CDN:
    1. Зазвичай CDN-провайдер просить зробити CNAME для піддомену (наприклад, www) на їх адресу (наприклад, example.cdnprovider.com).
    2. Якщо ви хочете використовувати CDN для кореневого домену (example.com), використовуйте функцію ALIAS/ANAME або CNAME flattening вашого DNS-провайдера.
    3. Переконайтеся, що CDN правильно налаштований для роботи з вашим SSL-сертифікатом (часто CDN бере на себе термінацію SSL). Урахування CAA-записів у цьому випадку важливе.
  • Переміщення хоста (міграція):
    1. За 48-72 години до міграції: Зменшіть TTL для A/AAAA записів вашого сайту до 300 секунд.
    2. Зачекайте: Зачекайте, поки старий TTL “пошириться” (пройде термін, рівний старому TTL, наприклад, 3600 секунд).
    3. У день міграції: Змініть A/AAAA записи, вказавши нові IP-адреси.
    4. Перевірка: Використовуйте dig +short example.com A з різних публічних DNS (Google 8.8.8.8, Cloudflare 1.1.1.1) для перевірки поширення змін.
    5. Після стабілізації (через 24-48 годин): Збільшіть TTL назад до оптимального значення (наприклад, 3600).

12. Готовий JSON для імпорту в панель провайдера

Нижче наведено розширений JSON-шаблон, що містить майже всі типи записів, розглянуті в цьому посібнику. Цей формат є узагальненим і може потребувати адаптації під конкретний API вашого DNS-провайдера (Cloudflare, AWS Route 53, DigitalOcean тощо).

Cloudflare:

{
  "zone_name": "example.com",
  "zone_type": "full",
  "records": [
    {
      "type": "A",
      "name": "@",
      "content": "192.0.2.10",
      "ttl": 3600,
      "proxied": false
    },
    {
      "type": "AAAA",
      "name": "@",
      "content": "2001:db8::10",
      "ttl": 3600,
      "proxied": false
    },
    {
      "type": "CNAME",
      "name": "www",
      "content": "example.com",
      "ttl": 3600,
      "proxied": false
    },
    {
      "type": "MX",
      "name": "@",
      "content": "mail.example.com",
      "priority": 10,
      "ttl": 3600
    },
    {
      "type": "TXT",
      "name": "@",
      "content": "v=spf1 ip4:192.0.2.20 include:_spf.google.com ~all",
      "ttl": 3600
    },
    {
      "type": "TXT",
      "name": "_dmarc",
      "content": "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100",
      "ttl": 3600
    },
    {
      "type": "NS",
      "name": "@",
      "content": "ns1.example.net",
      "ttl": 3600
    },
    {
      "type": "NS",
      "name": "@",
      "content": "ns2.example.net",
      "ttl": 3600
    },
    {
      "type": "SRV",
      "name": "_sip._tcp",
      "data": {
        "target": "sipserver.example.com",
        "port": 5060,
        "priority": 10,
        "weight": 60
      },
      "ttl": 3600
    },
    {
      "type": "CAA",
      "name": "@",
      "data": {
        "flags": 0,
        "tag": "issue",
        "value": "letsencrypt.org"
      },
      "ttl": 3600
    },
    {
      "type": "TLSA",
      "name": "_443._tcp",
      "data": {
        "usage": 3,
        "selector": 1,
        "matching_type": 1,
        "certificate": ""
      },
      "ttl": 3600
    },
    {
      "type": "SSHFP",
      "name": "@",
      "data": {
        "algorithm": 4,
        "digest_type": 2,
        "fingerprint": "d6f8..."
      },
      "ttl": 3600
    },
    {
      "type": "HINFO",
      "name": "@",
      "data": {
        "cpu": "INTEL",
        "os": "Linux"
      },
      "ttl": 3600
    },
    {
      "type": "LOC",
      "name": "@",
      "data": {
        "latitude": "37.7749N",
        "longitude": "122.4194W",
        "altitude": 30
      },
      "ttl": 3600
    },
    {
      "type": "RP",
      "name": "admin",
      "data": {
        "mbox": "admin.example.com",
        "txt": "Responsible person for the domain"
      },
      "ttl": 3600
    },
    {
      "type": "NAPTR",
      "name": "_sip._tcp",
      "data": {
        "order": 100,
        "preference": 10,
        "flags": "U",
        "service": "SIP+D2U",
        "regexp": "",
        "replacement": "_sip._udp.example.com"
      },
      "ttl": 3600
    },
    {
      "type": "DS",
      "name": "@",
      "data": {
        "key_tag": 12345,
        "algorithm": 8,
        "digest_type": 2,
        "digest": ""
      },
      "ttl": 3600
    },
    {
      "type": "DNSKEY",
      "name": "@",
      "data": {
        "flags": 256,
        "protocol": 3,
        "algorithm": 8,
        "public_key": ""
      },
      "ttl": 3600
    },
    {
      "type": "RRSIG",
      "name": "@",
      "data": {
        "type_covered": "A",
        "algorithm": 8,
        "labels": 1,
        "original_ttl": 3600,
        "signature_expiration": 1700000000,
        "signature_inception": 1690000000,
        "key_tag": 12345,
        "signer_name": "example.com",
        "signature": ""
      },
      "ttl": 3600
    },
    {
      "type": "NSEC",
      "name": "@",
      "data": {
        "next_domain": "example.net",
        "types": ["A","AAAA","MX","TXT","NS"]
      },
      "ttl": 3600
    }
  ]
}

Route 53:

{
  "Comment": "Full DNS cheat sheet import",
  "Changes": [
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "A",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "192.0.2.10"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "AAAA",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "2001:db8::10"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "www.example.com.",
        "Type": "CNAME",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "example.com"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "MX",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "10 mail.example.com"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "TXT",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "\"v=spf1 ip4:192.0.2.20 include:_spf.google.com ~all\""}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "_dmarc.example.com.",
        "Type": "TXT",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "\"v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100\""}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "NS",
        "TTL": 3600,
        "ResourceRecords": [
          {"Value": "ns1.example.net"},
          {"Value": "ns2.example.net"}
        ]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "_sip._tcp.example.com.",
        "Type": "SRV",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "10 60 5060 sipserver.example.com"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "CAA",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "0 issue \"letsencrypt.org\""}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "_443._tcp.example.com.",
        "Type": "TLSA",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "3 1 1 "}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "SSHFP",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "4 2 d6f8..."}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "HINFO",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "\"INTEL\" \"Linux\""}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "LOC",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "37.7749N 122.4194W 30m"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "admin.example.com.",
        "Type": "RP",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "admin.example.com Responsible person for the domain"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "_sip._tcp.example.com.",
        "Type": "NAPTR",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "100 10 U SIP+D2U \"\" _sip._udp.example.com"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "DS",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "12345 8 2 "}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "DNSKEY",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "256 3 8 "}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "RRSIG",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "A 8 1 3600 1700000000 1690000000 12345 example.com "}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "NSEC",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "example.net A AAAA MX TXT NS"}]
      }
    }
  ]
}

Повна підтримка всіх типів записів: A, AAAA, CNAME, MX, TXT, NS, SRV, CAA, TLSA, SSHFP, HINFO, LOC, RP, NAPTR, DS, DNSKEY, RRSIG, NSEC. TTL та пріоритети вже встановлені і можуть бути адаптовані за потреби. Використовує ResourceRecords для кожного запису, як вимагає AWS.
Прямий імпорт через AWS CLI за допомогою команди:

aws route53 change-resource-record-sets --hosted-zone-id ZONE_ID --change-batch file://dns_records.json

Висновок

DNS — це потужна та гнучка система, знання якої критично важливо для будь-кого, хто керує веб-проєктами, поштовими системами або мережевою інфраструктурою. Цей посібник охоплює всі аспекти — від простих A-записів до складних механізмів безпеки, таких як DNSSEC і DANE.

Ключові висновки:

  • Плануйте зміни: Завжди знижуйте TTL перед міграцією.
  • Тестуйте: Використовуйте dig, nslookup та онлайн-інструменти для перевірки кожної настройки.
  • Безпека понад усе: Налаштуйте SPF, DKIM, DMARC для пошти. Увімкніть CAA для контролю сертифікатів. Розгляньте можливість використання DNSSEC для критично важливих доменів.
  • Документуйте: Ведіть контрольні списки та зберігайте резервні копії зон.

Цей матеріал призначений бути вашим універсальним довідником. Збережіть його, і він допоможе вам вирішити будь-яке завдання, пов’язане з DNS.

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *