Типи серверів доменних імен

Типи серверів доменних імен. Master, Slave, Cache, Stealth, Root.

В даному матеріалі розбирається типізація DNS серверів за їх призначенням, розглядаються основний функціонал серверів кожного типу і його значення для надійної і ефективної роботи системи доменних імен. Перш ніж приступити до читання даного матеріалу, необхідно ознайомитися з матеріалом "Як працює система доменних імен".

Master-сервер (primary, первинний) доменних імен є відповідальним (authoritative) за інформацію про зону в тому сенсі, що Новомосковскет опис зони з локального диска комп'ютера, на якому він функціонує і відповідає згідно з цим описом на запити resolver-ів. Опис зони master-сервера є первинним, тому що його створює вручну адміністратор зони. Відповідно, вносити зміни в опис зони може тільки адміністратор даного сервера. Всі інші сервери тільки копіюють інформацію з master-сервера. Взагалі кажучи, таке визначення дещо застаріла, і пізніше буде ясно чому. Але при настройках реальних серверів ми будемо використовувати саме це визначення.

Для зони можна визначити тільки один master-сервер, тому що першоджерело може і повинен бути тільки один.

Slave-сервер (secondary, вторинний, дублюючий) також є відповідальним (authoritative) за зону. Його основне призначення полягає в тому, щоб підстрахувати роботу основного сервера доменних імен (master server), відповідального за зону, на випадок його виходу з ладу, а також для того, щоб розвантажити основний сервер, прийнявши частину запитів на себе. Так, наприклад, з 13 серверів, які обслуговують кореневу зону, 12 є slave-серверами.

Адміністратор slave-серверу не прописує дані опису зони. Він тільки забезпечує налаштування свого сервера таким чином, щоб його сервер копіював опис зони з master-сервера, підтримуючи його (опис зони) в актуальному узгодженому з master-сервером стані.

Зазвичай, час узгодження опису зони між slave-сервером і master-сервером задається адміністратором master-сервера в описі зони. Slave-сервер в момент свого запуску копіює це опис і потім керується ним при оновленні інформації про зону. Slave-сервера періодично через заданий інтервал часу опитують master-сервер на предмет зміни опису зони. Якщо зміни мають місце бути, то опис зони копіюється на slave-сервер.

Специфікація DNS дозволяє реалізувати й інший механізм оновлення інформації - оповіщення про зміни. У цьому випадку ініціатива оновлення описів зони на slave-серверах належить не цим серверам, а master-сервера. Останній оповіщає slave-сервери від тому, що в базу були внесені зміни, і необхідно ці зміни скопіювати на slave-сервери.

Рис.1. Схема підключення master і slave серверів зони

З малюнка 1 видно, що корпоративна локальна мережа і мережа реєстратора мають незалежні підключення до Інтернет, через різних канальних провайдерів. Зокрема резервування серверів в ru-center (www.nic.ru) забезпечує таку схему підключення, тобто master-сервер може бути розміщений на майданчику корпоративної локальної мережі, а slave на майданчику ru-center.

Розміщення обох серверів на майданчику реєстратора, наприклад, ru-center, також забезпечує незалежне підключення серверів, тому що зазвичай реєстратор має кілька точок підключення до Інтернет.

В сучасних RFC, які розширюють тлумачення механізмів взаємодії між учасниками обміну даними в рамках DNS, типізацію серверів і їх поділ на master-сервери і slave-сервери дають щодо процедур копіювання зони.

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

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

> Set type = soa
> rambler.ru
Server: ns.rambler.ru
Address: 217.73.192.49

Позиція refresh говорить про те, що час опитування в стандартному режимі складає 3 години. А ось з іншого звіту для зони relarn.ru цей час і того більше - добу:

> relarn.ru
Server: ns.relarn.ru
Address: 194.226.65.3

relarn.ru
origin = ns.relarn.ru
mail addr = noc-dns.relarn.ru
serial = 650127367
refresh = 86400 (1D)
retry = 3600 (1H)
expire = 604800 (1W)
minimum ttl = 86400 (1D)
relarn.ru nameserver = ns.relarn.ru
relarn.ru nameserver = ns.ussr.EU.net
relarn.ru nameserver = ns.spb.su
relarn.ru nameserver = ns2.ripn.net
ns.relarn.ru internet address = 194.226.65.3
ns.ussr.EU.net internet address = 193.124.22.65
ns.spb.su internet address = 193.124.83.69
ns2.ripn.net internet address = 194.226.96.30
>

Про те, що позначають інші позиції цих звітів, ми поговоримо тоді, коли будемо обговорювати опис зони (запис SOA), а поки тільки зауважимо, що внесення змін до опису зони не призводить до появи можливості миттєвого їх використання.

Таким чином, механізм повідомлення про зміни в описі зони необхідний для прискорення введення в життя зроблених змін.

Принцип роботи DNS NOTIFY наступний:

На малюнку пояснется роботи наведеної вище схеми:

Рис.2. Схема роботи DNS NOTIFY

На малюнку 2 primary master є для обох slave-серверів master-сервером c точки зору процедури передачі зони. Але в принципі, для одного з серверів він може бути і не визначений в якості master-сервера. У цьому випадку з'являється додаткова ланка в дереві залежності обміну даними зони. У цьому випадку зміни будуть передаватися від сервера до сервера так, як це показано на малюнку 3:

Рис.3. Схема роботи DNS NOTIFY при Дволанковий оповіщенні про зміну опису зони.

Тепер пояснимо механізм динамічного оновлення опису зони (Dynamic Updates або DNS UPDATE). Спочатку опис зони було, та й до сих пір в більшості випадків залишається, статичним. Це означає, що є на Primary master файл опису зони, в який адміністратор вручну або за допомогою скриптів зміни змісту файлу вносить зміни. Для того щоб вони стали актуальними, тобто їх побачили resolver-и, необхідне перезавантаження сервера. Ідея динамічного оновлення опису зони полягає в тому, щоб, по-перше, вносити зміни в опис зони без перезавантаження сервера, а, по-друге, робити це віддалено, тобто адміністратору не потрібно отримувати доступ до файлів опису зон ні для ручного редагування, ні для скриптів. Тим самим клас клієнтів в моделі "клієнт-сервер" в рамках DNS обміну розширюється на групу клієнтів адміністрування.

DHCP істотно полегшує роботу мережевого адміністратора, якому не потрібно налаштовувати кожен комп'ютер, підключений до мережі, вручну. Динамічне іменування тягне за собою постійну зміну інформації в описі зони.

Якщо сервер не є Primary master-сервером зони, то він відправляє (ретранслює) запит на оновлення свого master-сервера. Таким чином запит на обнавленіе досягає Primary master-сервера зони.

Як тільки Primary master-сервер зробить оновлення опису зони, він може за механізмом DNS NOTIFY оповістити про це slave-сервери, які, в свою чергу, оновлять свої опису зони.

В рамках динамічного оновлення можна видаляти і додавати окремі записи опису ресурсів в опису зони, набори записів опису ресурсів, виділених за певною ознакою, скажімо записи певного типу, або записи пов'язані з певним доменом. Можливо редагування опису зони за умовою.

Для того, щоб успішно виконувалися обміни зі slave-серверами, при кожній зміні зони змінюється і номер її версії. Це дозволяє slave-серверів підтримувати свої опису зони в актуальному, узгодженому з Primary master-сервером стані.

Динамічне оновлення опису зони породжує іншу проблему - багаторазову передачу по мережі опису зони між master-серверами і slave-серверами. Якщо опис зони велике, то і обсяг трафіку, який передається по мережі, буде немаленький.

При цьому варто відзначити, що власне самі зміни опису зони не настільки і великі, тому що наприклад, при DHCP при кожній зміні додається / видаляється одна-дві записи опису ресурсів. Кожне таке зміна буде породжувати обмін описом зони.

При традиційному обміні описом зони (AXFR) Між master-сервером і slave-сервером передається повний опис зони.

Ми більш детально зупинимося на цьому питанні в розділі, присвяченому налаштувань BIND і файлів опису зон.

Проте, існують ще файли статичної настройки (конфігурації) серверів доменних імен, де такий сервер може бути прописаний. Його можна прописати в якості master-сервера для slave або конфігурувати таким чином, що він буде працювати в якості slave для конкретної зони.

Для чого потрібен такий невидимий сервер. Наприклад, для того, щоб вносити оновлення в зону, перебуваючи під захистом firewall. В цьому випадку Primary master можна зробити невидимим, а всі інші, в тому числі і заявлені при реєстрації домену, slave-серверами зони. Це дозволяє нейтралізувати атаки на зону, тому що оновлення завжди буде проводитися з "невидимого" Primary master:

Рис.4. Схема організації DNS-серверів з невидимим primary master сервером

> www.w3.org
Server: [144.206.192.60]
Address: 144.206.192.60

Non-authoritative answer:
Name: www.w3.org
Addresses: 18.29.1.35, 18.7.14.127, 18.29.1.34

Список цих серверів можна отримати досить просто. Нижче наведено звіт програми nslookup:

>.
Server: [144.206.192.60]
Address: 144.206.192.60

Authoritative answers can be found from:
(Root) nameserver = A.ROOT-SERVERS.NET
(Root) nameserver = B.ROOT-SERVERS.NET
(Root) nameserver = C.ROOT-SERVERS.NET
(Root) nameserver = D.ROOT-SERVERS.NET
(Root) nameserver = E.ROOT-SERVERS.NET
(Root) nameserver = F.ROOT-SERVERS.NET
(Root) nameserver = G.ROOT-SERVERS.NET
(Root) nameserver = H.ROOT-SERVERS.NET
(Root) nameserver = I.ROOT-SERVERS.NET
(Root) nameserver = J.ROOT-SERVERS.NET
(Root) nameserver = K.ROOT-SERVERS.NET
(Root) nameserver = L.ROOT-SERVERS.NET
(Root) nameserver = M.ROOT-SERVERS.NET
A.ROOT-SERVERS.NET internet address = 198.41.0.4
B.ROOT-SERVERS.NET internet address = 128.9.0.107
C.ROOT-SERVERS.NET internet address = 192.33.4.12
D.ROOT-SERVERS.NET internet address = 128.8.10.90
E.ROOT-SERVERS.NET internet address = 192.203.230.10
F.ROOT-SERVERS.NET internet address = 192.5.5.241
G.ROOT-SERVERS.NET internet address = 192.112.36.4
H.ROOT-SERVERS.NET internet address = 128.63.2.53
I.ROOT-SERVERS.NET internet address = 192.36.148.17
J.ROOT-SERVERS.NET internet address = 198.41.0.10
K.ROOT-SERVERS.NET internet address = 193.0.14.129
L.ROOT-SERVERS.NET internet address = 198.32.64.12
M.ROOT-SERVERS.NET internet address = 202.12.27.33
>

Згідно з цим звітом Primary master сервером для кореневої зони є сервер A.ROOT-SERVERS.NET. Саме він відповідає за все зміни в описі зони. Решта сервери щодо кореневої зони є slave-серверами. Slave-сервери оновлюють свої опису зони кожні 30 хвилин. Якщо протягом тижня Primary master буде непрацездатний, то по ідеї вся система доменних імен втратить зв'язність. В RFC-2870, де описані вимоги до роботи root серверів, містяться загальні слова про те, як не допустити такого розвитку подій, але там немає конкретного плану дій.

Насправді кожен з 13 серверів - це не одна машина. Так, наприклад, k.root-servers.net (європейський) складається з k1, k2 і k3, m.root-servers.net (японський) складається з двох основних серверів і двох серверів гарячого резерву, які підключені до трьох незалежних точкаv обміну трафіком, f.root-servers.net складається з двох двопроцесорних Alpha, по 4GB оперативної пам'яті в кожній, з балансуванням навантаження через маршрутизатор Cisco.

Середні цифри такі:

Вихідний трафік: 600 Kbps
Вхідний трафік: 2.2 Kbps
Число пакетів за добу: 26M

Розподіл запитів за типами:

Статистика обслуговування запитів, яка названа жахливою (Scary statistics):

- Тільки 26% правильних (valid) запитів до кореневої зоні.

- 66% запитів до неіснуючих доменів верхнього рівня (non existent TLDs)

Обговорити на Facebook