DNS-сервер, який відповідає за імена хостів в своїй зоні, повинен зберігати інформацію про хости в базі даних і видавати її за запитом інших пристроїв. База даних DNS являє собою текстовий файл, що складається з початкових записів RR (resource records). Ці записи описують комп'ютери і їх функції в локальній зоні. Для організації обміну інформацією з віддаленими серверами DNS має бути запущено програмне забезпечення сервера DNS (зазвичай це програма named).

Файли зон містять інформацію про простір імен і можуть містити директиви і записи ресурсів. Директиви вказують серверу доменних імен на виконання певних завдань або застосування спеціальних налаштувань в зоні. Ресурсні записи визначають параметри зони і співвідносять користувачів з певними хостами. У файлі зони необов'язково можуть бути присутніми директиви, але в ньому обов'язково повинні бути ресурсні записи.

Перш за все в базі даних сервера DNS повинна бути оголошена зона, за яку даний сервер несе відповідальність. Далі в ній повинні бути оголошені всі хост-комп'ютери, наявні в зоні. І, нарешті, в базі даних можна оголошувати спеціальну інформацію, що стосується зони (наприклад, про сервери електронної пошти і DNS-сервери). Формат запису бази даних був розроблений таким чином, щоб DNS-сервер міг почерпнути з неї будь-яку інформацію, потрібну для його роботи.

SOA

Start of Authority SOA - Обліковий запис Початку Відповідальності SOA– Відмічає початок зони, є першим записом у файлі зони. Кожна Зона містить один обліковий запис SOA, яка підтримує такі можливості для кожної Зони:

Primary DNS Server (origin) (Ім'я первинного DNS сервера)

Вказує доменне ім'я первинного DNS сервера для Зони. Зазвичай вказується в формі повністю певного доменного імені (з крапкою на кінці). Тут міститься найбільш достовірна інформація про домен. Кожна зона може містити підбір декількох облікових записів NS.

Mailbox of the Responsible Person (contact) (Поштова скринька відповідальної особи) Вказує адресу електронної пошти особи, відповідальної за утримання Зони. Хороша практика - вказувати тут робочу адресу (hostmaster, root, admin ...), а не адресу конкретної людини. Правило перетворення contact на адресу: перша зліва крапка замінюєтся на знак (@).

Serial Number (serial) (Серійний номер)

Використовується вторинними DNS серверами для перевірки змін Зони. Якщо номер Serial Number вище, ніж у вторинних DNS серверів, то автоматично буде зроблений перенос Зони. При внесенні змін в Зоні або її облікових записах це число автоматично зросте. Може будуватися по будь-яким правилам, але обов'язково повинно збільшуватися при кожній зміні файлу зони.

Краще за все використовувати формат: YYYYMMDDXX (рік, місяць, день, номер зміни зони за поточний день). Цей порядковий номер використовуєтся при передачі інформації від основного (primary) до вторинних (secondary) серверів.

Вторинний сервер запитує у основного SOA-запис і порівнює порядковий номер зони, який зберігається на вторинному сервері, з порядковим номером зони основного серверу. Якщо номер на основному сервері більший (тобто вторинний сервер містить вже застарілу інформацію), вторинний сервер запитує передачу всього файлу зони (zone transfer). Приклад: 19990110001

Refresh Interval(refresh) (Інтервал оновлень) - інтервал часу між опитуваннями вторинних серверів.

Показує, як часто вторинні DNS сервери перевіряють, чи були внесені зміни в Зоні. Кожні "refresh" секунд вторинний сервер перевіряє порядковий номер SOA. Величина, що вказана в refresh, повинна відображати реальну частоту оновлення зони. Для більш стабільних зон можна вказувати великі значення refresh.

Рекомендоване значення: 8-24 години (28800 - 86400)

Приклад:

86400 ; refresh (1 day)

Retry Interval (retry) (Інтервал повторних спроб)

Інтервал часу, через який вторинний сервер повинен повторити спробу, якщо основний сервер не відповідає. Не слід вказувати це значення занадто маленьким. Показує, як часто вторинні DNS сервери перевіряють чи були внесені зміни, якщо refresh нічого не показав.

Рекомендується: година(3600) або дві (7200).

Приклад:

7200 ; retry (2 hour)

Expire Interval (expire) (Інтервал закінчення дії)

• скільки часу вторинний сервер повинен зберігати інформацію про зону, якщо основний сервер недоступний, тобто як довго зона була доступна після оновлення. Після закінчення цього терміну, вторинний сервер відмічає, що його відповіді не являються достовірними (non-authoritative answer). Як правило, це достатньо велика величина: 3600000 - 42 дні.

Приклад

1209600 ; expire (14 days)

Вторинні сервери автоматично видалять Зону, якщо в ній не було оновлення в цьому проміжку часу.

Minimum (default) TTL (minimum)

Використовується за замовчуванням TTL для нових облікових записів, створених поза Зоною. Скільки часу необхідно зберігати запис в кэш-пам'яті будь-якого name-сервера, який запитує інформацію про домен. Після цього інформація застаріває і name-сервер повинен буде надіслати запит на один з авторитетних серверів (primary, secondary).

Minimum TTL Повинно відповідати середній частоті змін в зоні, але не більше 345600 (4 days).

TTL (time to live) - визначає час актуальності даних при кешуванні запитів (значення TTL задає довжину проміжку часу, що використовують інші сервер DNS для визначення тривалості кешування інформації для цього запису, після чого ця інформація буде знищена як застаріла.). Задається в секундах. Якщо TTL становить 86 400 секунд, тобто 24 години, це означає, що при зміні запису DNS, до 24 годин після змін, DNS-сервери по всьому світу можуть видавати старі дані з кеша, поки він не буде оновлений. Саме це значення може зменшити або збільшити непотрібний DNS-трафік до авторитетного name-сервера. Якщо ви міняєте записи, краще встановити minimum менше, щоб застаріла інформація не залишалася в мережі. Для досить стабільної зони значення minimum обирайте в межах декількох днів.

Обрані значення TTL: На вибір TTL: 900 (15 м) 3600 (1 ч) 10800 (3 ч) 21600 (6 ч) 43200 (12 ч) 86400 (24 ч) 259200 (72 ч)

NS

Запис NS (name server) вказує на DNS-сервер для даного домена. Записи типу NS (Name Server - cервер імен) описують authoritative DNS-сервери для домену. Кількість записів типу NS у файлі зони повинна точно відповідати кількості DNS-серверів, які обслуговують домен і містити всі DNS-сервери, вказані в домені. Запис NS використовується для позначення сервера, який підтримує опис зони.

A

Запис A (address record) або запис адреси пов'язує ім'я хоста з адресою IP.

Наприклад, запит A-запису на ім'я imena.ua поверне його IP адресу — 195.39.196.42 Запис AAAA (IPv6 address record) пов'язує ім'я хоста з адресою протоколу IPv6. Наприклад, запит AAAA-запису на ім'я K.ROOT-SERVERS.NET поверне IPv6 адресу — 2001:7fd::1

MX

Запис типу MX (Mail Exchange - поштовий сервер) визначає поштовий сервер - машину, яка обробляє пошту для домену. Пріоритет: визначає значення пріоритетності поштового сервера. Чим менше число, тим вище пріоритет поштового сервера (0 означає найвищий пріоритет, 65535 - найнижчий). Поштовий сервер з більш високим пріоритетом є основним, а поштові сервери з більш низькими пріоритетами будуть другорядними і вступлять в роботу в тому випадку, якщо всі більш пріоритетні сервери з яких-небудь причин недоступні або непрацездатні.

CNAME

Запис CNAME (canonical name record) або канонічний запис імені (псевдонім) використовується для перенаправлення на інше ім'я. Записи CNAME дозволяють дати машинам зручні або значущі імена. CNAME зручно використовувати, якщо ви змінюєте ім'я машини, але хочете залишити доступ для клієнтів, які пам'ятають старе ім'я.

Особливості даного типу запису:

• CNAME не можна використовувати для основного домену (@).
• При використанні CNAME для будь-якого субдомену створити для нього запис іншого типу (А, ТХТ та інші) неможливо.

TXT

Використання: Технологія SPF (Sender Policy Framework) є одним із способів ідентифікації відправника електронного листа і надає додаткову можливість фільтрації потоку пошти на предмет наявності в ньому спамерських повідомлень. За допомогою SPF пошта ділиться на "дозволену" і "заборонену" відносно домена отримувача або відправника.

SRV

Запис цього типу використовують для пошуку серверів, які забезпечують роботу різноманітних служб в доменному імені.

Формат SRV запису наступний:

_Service._Proto.domain.tld. TTL_number IN SRV priority_number weight_number port_number host_name

Опис полів:

Service: назва служби (приклад: ldap, kerberos, gc та інші) Proto: протокол, за допомогою якого клієнти можуть підключитись до цієї служби (приклад: tcp, udp) Name: ім'я домену, в якому розміщена дана служба TTL: визначає "час життя" для конкретного запису. Необов'язковий параметр. Якщо значення параметра в записі не вказано, то "час життя" визначається параметром Default TTL. SRV: тип запису Priority: пріоритет даного серверу. Чим менше число, тим вищий пріоритет (0 означає найвищий пріоритет, 65535 - самий низький) Weight: відносна вага для серверів з одинаковим пріоритетом. Призначений для розподілу навантаження між серверами, для яких вказано рівний пріоритет. Частота звернення клієнта до серверів з одним пріоритетом повинна бути пропорційна вазі сервера. Якщо встановити на двох серверах вагу 5, то кожен отримає 50% звернень (рівномірне навантаження). Port: порт, на якому розміщена вказана служба на даному сервері Target: доменне ім'я сервера, який надає відповідну службу. Target: доменне ім'я сервера, який надає відповідну службу.

PTR

PTR - перетворення IP-адреси в ім'я (прописує власник ip)

За допомогою зворотних доменів (зворотних зон) IP-адреси перетворюються в імена хостів. Існує спеціальний домен in-addr.arpa, записи в якому використовуються для перетворення IP-адрес в символьні імена.

Формат запису PTR:

IN-ADDR name [TTL] [ class ] PTR name

Увага!! Трансляція IP-адрес в домені знаходиться у володінні провайдера і саме провайдер делегує (або не делегує) права на ведення реверсної зони.