Література

1. http://muff.kiev.ua/content/rfc-3022-traditsionnaya-translyatsiya-setevykh-adresov-ip-nat

2. http://www.iz-news.ru/lect/nat/

3. http://users.i.com.ua/~sipnet/NAT0.htm

Тема 8. Служба доменних імен

Поняття доменного імені

Домен – це область простору ієрархічних (див. рисунок 8.1) імен мережі Інтернет, яка обслуговується набором серверів доменних імен (DNS) та централізовано адмініструється. Домен ідентифікується іменем домену.

Рисунок 8.1 – Простір доменних імен

Доменне ім'я (domain name) – це адреса мережного з'єднання, який ідентифікує власника адреси. Реєстрація доменів – являє собою занесення інформації про домен та його адміністратора в центральну базу даних з метою забезпечення унікальності використання домена, а також отримання прав на адміністрування домену адміністратором. Послуга з реєстрації домену вважається наданою з моменту занесення інформації в базу даних. Реєстрація домену діє протягом одного року після дати реєстрації домена.

Адреси в Інтернет будуються на доменній системі адресації (domain name system, DNS), тобто кожен адреса складається з декількох рівнів. При цьому існують два основних способи адресації: символьний, який, призначений для використання людьми і чисельний, заснований на IP-адресах і використовуваний комп'ютером. Кожен з десятків мільйонів комп'ютерів, що входять в Інтернет має свою власну унікальну доменну адресу (domain address), часто звану також доменним ім'ям (domain name) комп'ютера або просто іменем вузла (host name). Ця адреса виглядає як кілька слів, скорочень або інших ланцюжків символів без пробілів (букви повинні бути тільки латинськими), що йдуть підряд і розділених крапками.

Складові частини доменної адреси називаються сегментами і утворюють ієрархічну систему. Самий останній (крайній правий) сегмент, званий доменом верхнього рівня, визначає приналежність комп'ютера до мережі тієї чи іншої країни і складається звичайно з двох букв, наприклад. ru - Росія, ua - Україна ... У США традиційно використовується інша система – тематична. У цій системі домен верхнього рівня складається з трьох букв і позначає приналежність власника адреси до одного з наступних класів:.Com - комерційні сайти, .Edu - освітні організації, .Org - інші організації...

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

Так само як і "будинок" у поштовій адресі одночасно розташований на певній вулиці, в деякому місті і в деяких країнах, один і той же комп'ютер належить відразу до декількох доменах: наприклад, комп'ютер www.rkom.spb.ru, належить одночасно до домену фірми Рком (rkom.spb.ru), до домену Петербурга (spb.ru) і до домену Росії (ru). Домени Інтернету, як матрьошки, вкладаються один в одного, і чим дрібніше домен, тим з більшого числа сегментів полягає його позначення.

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

company.com комерційна фірма "Company"

stanford.edu Стенфордський університет, США

ivanov.msk.ru особистий комп'ютер людини на прізвище Іванов, що живе в Москві.

Доменні адреси комп'ютерів, про які ми зараз говорили, призначені для людей. Коли один вузол намагається відшукати в Інтернеті інший, він користується іншим типом адреси – так званим IP-адресою (IP – Internet Protocol - міжмережевий протокол). Якщо доменну адресу можна порівняти з ім'ям людини, то IP-адреса – це його "номер телефону", який тільки і дає реальну можливість зв'язатися з ним. IP-адреса схожий на доменну адресу тим, що також складається із сегментів, що утворюють ієрархічну систему. Однак на відміну від доменної адреси, число цих сегментів в IP-адресі завжди дорівнює чотирьом, а самі сегменти являють собою не рядки символів, а числа в діапазоні від 0 до 255. Крім того, в IP-адресах ієрархічна драбина спускається зліва направо, а не справа наліво, як у доменних адресах. Це означає, що два комп'ютери - сусіда по Інтернету будуть, швидше за все, відрізнятися останнім сегментом своїх IP-адрес і першим сегментом доменних адрес.

Приклад:

194. 105. 195. 17

147. 115. 3. 27

представляють дві IP адреси.

Для визначення за доменною адресою IP-адреси на спеціальних вузлах Мережі є Таблиці відповідності. Такі вузли називаються серверами DNS (Domain Name Service, "служба доменних імен"). Комп'ютеру повинен бути відома адреса хоча б одного такого сервера. Якщо цей сервер не знатиме IP-адресу сайту, який вам потрібен, він звернеться до інших, найближчим до нього серверів системи DNS, до своїх сусідів, і так далі. Коли потрібна IP-адреса буде, нарешті, знайдений на одному з серверів DNS, її тут же перешлють на ваш комп'ютер.

Принцип роботи служби доменних імен

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

Комп'ютери в мережі спілкуються між собою, використовуючи IP-адреси – числові імена, що мають такий вигляд: 217.107.217.21. IP-адресу можна порівняти з номером телефону – щоб один комп'ютер міг звернутися до іншого, йому необхідно знати його IP-адресу. Однак у IP-адрес є два недоліки: по-перше, їх існує лише обмежена кількість (що нам зараз не дуже важливо), а по-друге, що важливіше, IP-адресу дуже важко запам'ятати людині. Продовжуючи аналогію з телефонними номерами, чи пам'ятаєте ви номери телефонів всіх своїх друзів і знайомих? Ймовірно, ні. Але ви завжди можете скористатися записником.

В Інтернеті роль записника грає DNS – Domain Name System, система доменних імен. Кожен сайт в мережі має своє доменне ім'я (наприклад, www.jino.ru), яке система DNS пов'язує з IP-адресою сервера – комп'ютера, на якому розташований цей сайт. І коли в адресному рядку браузера ви вводите-якої домен, він автоматично перетворюється в IP-адресу, і вже використовуючи його, ваш комп'ютер зв'язується з сервером. Сама схема визначення IP-адреси по імені домену (див. рисунок 8.2) досить складна і багатоступенева, і саме через це виникає більшість проблем при реєстрації і перенесенні доменів.

Після набору імені домену в браузері ваш комп'ютер зв'язується з DNS-серверами провайдера доступу в Інтернет, запитуючи IP-адресу, до якого прив'язаний цей домен (крок 1 на схемі). DNS-сервери провайдера шукають у своєму кеші необхідну пару домен – IP-адресу і, якщо знаходять її, видають вам цей IP (відразу переходимо до кроку 6). Якщо в кеші нічого не знайшлося, DNS-сервер провайдера робить запит до одного з кореневих DNS-серверів, яких всього кілька по всьому світу (крок 2). Кореневий сервер, у свою чергу, шукає в своїй базі даних адреси DNS-серверів хостера, до якого прив'язаний домен (NS-сервери домену), і повідомляє їх DNS-сервера провайдера (крок 3). (Насправді, тут все трохи складніше, але для простоти ми опустимо деякі подробиці).

Рисунок 8.2 – Схема визначення IP-адреси по імені домену

Отримавши адреси NS-серверів, провайдер робить запит до одного з них, отримує у відповідь шуканий IP-адресу (кроки 4-5), запам'ятовує його в кеші (щоб згодом не звертатися щоразу до кореневого DNS-сервера) і передає вашому браузеру. Браузер, нарешті, запитує сайт у хостера і показує його вам (кроки 7-8).

Очевидно, що в цій схемі є два вузьких місця, які призводять до проблем при перенесенні доменів.

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

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

Зазвичай, ці проблеми вирішуються самі собою в перебігу декількох годин – після оновлення бази даних DNS і кеша провайдера. Тому, якщо після реєстрації або переносу домену (зміни NS-серверів), сайт відразу не став працювати, не хвилюйтеся – просто зачекайте деякий час.

Поняття доменних зон

Доменні зони мають свою ієрархію (див. рисунок 8.3).

Рисунок 8.3 – Різновиди доменних зон

Зони бувають міжнародні та національні (вказують на певну країну). Національні, в свою чергу, поділяються по регіональній приналежності і по сфері діяльності. Всі міжнародні доменні імена відносяться до імен I рівня (зона складається з одного слова, наприклад, imya.com, imya.org, imya.net). Національні доменні імена можуть бути як I рівня, так і II чи III. Прикладом національного доменного імені I рівня можуть бути імена: imya.ua, imya.ru, imya.de і т.д.

Доменні імена, що визначають орієнтування web-ресурсу на певну географічну зону в межах держави, прийнято називати регіональними. Наприклад, сайт компанії по виробництву вікон, з доменним ім'ям vikno.kiev.ua, красномовно говорить про те, що офіс вищезгаданої компанії розміщений на території Києва чи київської області, а tusovka.vn.ua – це місце тусовки з переважною більшістю вінничан.

В залежності від тематики web-ресурсу і/або сфери зайнятості організації чи приватні особи можуть віддавати перевагу іменам в певних зонах. Наприклад, українська комерційна структура цілком логічно обере доменне ім’я в зоні *.com.ua, а університет, стіни якого розміщені в межах британських кордонів – *.gov.uk.

Вся ця класифікація і поділ доменних зон виникли давно, однак, в наш час – час стрімкого розвитку web-технологій і, зокрема, Інтернету – на логічну класифікацію практично не звертають увагу, а обирають ім'я в зоні, в якій воно ще не зайняте.

Зворотні зони

Завдання пошуку доменного імені за IP-адресою є зворотною до прямої задачі – пошуку IP-адреси по доменному імені. Пряме завдання вирішується в DNS за допомогою записів типу A (Address). Зворотний ж завдання вирішується за допомогою записів-покажчиків типу PTR (Pointer), які спільно з записами SOA і NS складають опис так званої "зворотної" зони.

Насправді в DNS рішення задачі пошуку доменного імені за IP-адресою дещо незвично. Здавалося б, що для вирішення цього завдання можна використовувати опис "прямий" зони. У ній адже вся інформація є!

Насправді вирішувати "зворотну" завдання по "прямій" зоні незручно. Пошук зведеться до повного перебору всіх зон, бо зручного апарату рефералів (відсилань по NS записам) для IP-адрес в прямих зонах немає.

Якщо IP-адреса, для якого шукається доменне ім'я, потрапить в зону відповідальності сервера доменних імен, або потрібне відповідність виявиться закешовану, то доменне ім'я сервер знайде легко. Якщо IP-адреса не опиниться в зоні відповідальності сервера, то тоді скористатися стандартною процедурою пошуку сервер не зможе.

Адже перше, що робить сервер у вище описаній ситуації – це звернення до кореневого сервера, а він-то звідки знає, кому належить запитуваний IP-адресу? В системі доменних імен підтримується ієрархія доменних імен, але не IP-адрес.

Ось тут і виникає досить логічне і просте рішення, яке дозволяє використовувати стандартний механізм пошуку доменного імені для вирішення "зворотної" завдання – спеціальний домен, структура якого співпадає зі структурою IP-адрес. Називається цей домен IN-ADDR.ARPA.

Спочатку трохи історії. У той час коли затівалася система доменних імен (приблизно 1983 рік – рік виходу RFC 882 і 883) під Інтернет малася на увазі мережа ARPA, а крім неї ще обговорювалася можливість побудови єдиного адресного простору з CSNET. З цієї причини крім класу записів опису ресурсів IN - INTERNET (у той час ARPA) був ще клас опису ресурсів CS - CSNET (Computer Science Network).

У рамках цієї концепції в мережі ARPA вводився домен для адрес Інтернет (IN-ADDR – Internet ADDRess). При цьому окремо обмовлялося, що для інших мереж алгоритм пошуку доменного імені за IP-адресою може відрізнятися від того, який запропонований для адресного простору мережі ARPA.

При цьому доменні адреси в ARPA закінчувалися словом "ARPA", ось приклад з RFC 883:

.. 9999999 IN NS B.ISI.ARPA

9999999 CS NS UDEL.CSNET

B.ISI.ARPA 9999999 IN A 10.3.0.52

UDEL.CSNET 9999999 CS A 302-555-0000

У ньому ми бачимо, що у записів класу IN доменне ім'я закінчується на ARPA, а у всіх записів класу CS – на CSNET. Таким чином домен IN-ADDR був доменному верхнього рівня в рамках Інтернет (ARPA) на той час.

Зараз вже немає ні CSNET, ні пізніших CH (CHAOS) і HS (Hesiod), які можна знайти в специфікації RFC 1035. Була реорганізована і зникла ARPA. Але задуманий для адресного простору ARPA домен IN-ADDR.ARPA залишився.

Насправді, у квітні 2000 року між DARPA (колишньої ARPA) і ICAAN було укладено угоду про те, що домен верхнього рівня (TLD) ARPA буде використовуватися для цілей підтримки інфраструктури Інтернет.

Крім того, саме слово "ARPA" слід розшифровувати як "Address and Routing Parameter Area Domain (ARPA)", і не слід його асоціювати з мережею ARPANET.

Основне призначення домену ARPA – забезпечувати відображення чисельних величин, що визначаються протоколами мережевого обміну, в простір імен.

Делегування піддоменів в домені ARPA покладено на IAB (Internet Architecture Board). В даний час в ARPA виділено три піддомена:

• in-addr.arpa для відображення IP-адрес IPv4 в простір доменних імен;

• ip6.arpa для відображення IP-адрес IPv6 в простір доменних імен;

• е164.arpa для відображення телефонних номерів формату Е.164.

Сама зона ARPA підтримується кореневими серверами і серверами TLD зон, хоча відповідно до рекомендацій RFC 2870 для ARPA бажано виділення окремих серверів.

Імена в домені IN-ADDR.ARPA утворюють ієрархію цифр, які відповідають IP-адресами. Правда, записуються ці імена у зворотному порядку щодо написання IP-адреси.

Наприклад, машина vega-gw.vega.ru, яка має адресу 194.226.43.1 повинна бути описана в домені in-addr.arpa як 1.43.226.194.in-addr.arpa, тобто адреса записується у зворотному порядку.

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

Рисунок 8.4 – Приклад структури частини домену in-addr.arpa

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

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

Однак насправді сама ідея інверсного запису IP-адреси спирається на принципи побудови цієї адреси. Зрозуміло, що перша група цифр, найближчих до кореня IN-ADDR.ARPA, задає номер мережі, а інші номер хоста. Зважаючи на той факт, що спочатку при створенні доменної адресації в ARPA йшлося про мережах класу A (перший байт-октет визначає номер мережі), то перша цифра в доменному імені в зоні IN-ADDR.ARPA – це номер мережі, а всі наступні – це номер хоста:

1.0.0.10.IN-ADDR.ARPA

Приклад визначає перший хост в 10-ій мережі.

Пошук цієї адреси зайняв би пошук сервера, відповідального за 10.IN-ADDR.ARPA, а той би відповів ім'ям відповідним адресою хоста.

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

Тепер, перш ніж обговорювати проблеми пошуку доменних імен в IN-ADDR.ARPA, необхідно повернутися до формату опису зон цього домену, які прийнято називати "зворотними".

Зворотний зона складається, головним чином із записів типу "Pointer" або PTR-записів. Формат запису має наступний вигляд:

[name][ttl] IN PTR [host]

Поле ім'я задає номер. Це, як вже обговорювалося, чи не реальний IP-адресу машини, а ім'я в спеціальному домені in-addr.arpa або в одній з його зон. Наведемо приклад PTR запису:

$ORIGIN 43.226.194.in-addr.arpa.

1 IN PTR vega-gw.vega.ru.

По всій видимості провайдер виділили організації мережу класу С 194.226.43.0 (В нотації CIDR 194.226.43.0/24). При цьому організації було також делеговано право ведення "зворотної" зони 43.226.194.in-addr.arpa. Ось у цій зоні адміністратор зони і почав описувати "зворотні" відповідності.

Слід визнати, що відповідність зворотних зон мереж - це загальна практика опису "зворотних" зон. Тут точно також треба делегувати зони з "зворотного" домену. А робиться це, як правило, на основі розбиття мережі на підмережі або мережі.

Як приклад для нашої навчальної зони у файлі named.boot (BIND 4 або named.conf для BIND 8 – 9) визначена "зворотна" зона 43.226.194.in-addr.arpa. Її опис буде виглядати приблизно так:

$TTL 3600

@ IN SOA vega-gw.vega.ru hostmaster.vega.ru (

101 ; serial number

86400 ; refresh within a day

3600 ; retry every hour

3888000 ; expire after 45 days

3600 ) ; negative caching

IN NS vega-gw.vega.ru.

IN NS ns.relarn.ru.

;

1 IN PTR vega-gw.vega.ru.

4 IN PTR dos1.vega.ru.

5 IN PTR dos2.vega.ru

2 IN PTR zone1-gw.zone1.vega.ru.

3 IN PTR zone2-gw.zone2.vega.ru.

З цього прикладу видно, що для зворотного зони вказані ті ж записи опису зони, що і для "прямої". Крім того, зворотну зону зовсім не обов'язково розбивати відповідно з поділом прямий зони на інші зони. Мова в даному випадку йде про зони zone1 і zone2. З точки зору домену in-addr.apra всі машини належать одній зоні – 43.226.194.in-addr.arpa.

Інша справа машина з IP-адресою 127.0.0.1 (localhost). З точки зору домену in-addr.arpa вона належить іншій гілці ієрархії, відмінної від тієї, якій належать всі інші хости. Тому для домену 127.in-addr.arpa на будь-якій машині є окремий файл зворотного зони, хоча localhost, якому відповідає цей IP-адреса, зазвичай описується в прямій зоні домену разом з іншими хостами. Ось приклад опису цієї зони:

; From: @(#)localhost.rev 5.1 (Berkeley) 6/30/90

; $FreeBSD: src/etc/namedb/PROTO.localhost.rev,v 1.6 2000/01/10

; 15:31:40 peter Exp $

;

; This file is automatically edited by the `make-localhost' script in

; the /etc/namedb directory.

;

$TTL 3600

@ IN SOA generate.polyn.kiae.su. root.generate.polyn.kiae.su. (

00000001 ; Serial

3600 ; Refresh

900 ; Retry

3600000 ; Expire

3600 ) ; Minimum

IN NS generate.polyn.kiae.su.

1 IN PTR localhost.polyn.kiae.su.

>

Як випливає з коментаря цього файлу для його генерації можна використовувати спеціальний sh-скрипт make-localhost, який входить в комплект поставки BIND. Він бере в якості основи файл прототипу PROTO.localhost.rev підставляє в нього ім'я хоста і ім'я домену.

Цікаво, що замість користувача hostmaster, що рекомендовано в RFC2142, в даному випадку вказується користувач root. Воно й зрозуміло. Користувача hostmaster може і не бути, адже не всі читають все підряд RFC, а користувач root є обов'язково. Тим більше, що це швидше за все і є адміністратор локального сервера доменних імен.

Слід при цьому пам'ятати, що у файлі конфігурації named.conf має бути блок, який вказує на цю "зворотну" зону:

zone "0.0.127.IN-ADDR.ARPA" {

type master;

file "localhost.rev";

};

Насправді ми опустили одне цікаве питання, а як прямий IP-адреса формату IPv4 перетвориться в доменне ім'я, яке має інверсну запис цифр.

Ці функції покладені на resolver. Resolver перетворює 32-бітову адресу в текстовий рядок, розміщуючи октети у зворотному порядку, розділяючи їх символами ".". До отриманого імені resolver через роздільник "." додає суфіксом "in-addr.arpa". Після цього формує PTR запит до системи доменних імен.

Запитання делегування зон у IN-ADDR.ARPA не настільки прості, як може здатися на перший погляд. Ця проблема тісно пов'язана з отриманням пулів IP-адрес. Крім отримання адреси, потрібно ще отримати право на ведення зворотного домену, відповідного вашому адресного пулу.

Насправді, ніхто крім власника адресного пулу не знає, як розподілено адресний простір. Віддати комусь ведення "зворотної" зони – це значить, по-перше, не забезпечити оперативність управління цією зоною, якщо тільки немає коштів віддаленого управління, як, наприклад, в nic.ru, а, по-друге, така послуга коштує грошей. З цих причин зворотну зону краще вести самим.

Хто відповідає за батьківську зону вашого зворотного домену, визначається розміром вашого адресного пулу і тим, як цей адресний пул був отриманий.

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

Перш за все, слід знати, що спочатку всі адреси, які ми використовуємо в RuNet, отримують RIPE Network Coordination Centre (RIPE – це Reseaux IP Europeens), який є одним з трьох регіональних Інтернет реєстраторів котрі підтримують глобальну інфраструктуру Інтернет.

З попереднього абзацу важливо тільки те, що всі блоки адрес в нотації CIDR xxxx.xxxx.xxxx.xxxx/16 і xxxx.xxxx.xxxx.xxxx/24 видаються цією організацією локальним Інтернет реєстраторам (Local Internet Registres – LIR). А ось вже вони і розподіляють ці адреси між своїми клієнтами.

У звичайній класифікації мереж Інтернет це означає, що RIPE NCC відповідає за делегування в зоні IN-ADDR.ARPA не тільки мереж класу B, але і мереж класу C. Мережі класу B зараз майже не видають, тому сміливо можна зупинитися на мережах класу C.

Якщо Ви не є LIR, а Вам виділена мережа класу C, то направити заявку на делегування зворотної зони в RIPE NCC Ви безпосередньо все одно не зможете. Зробити це зможе тільки провайдер, що має статус LIR, який, власне, цю мережу в RIPE NCC отримав. Отже, потрібно зв'язуватися з ним і з'ясовувати всі питання делегування зворотної зони. Якщо Вам виділений пул адрес з мережі класу B, то всі питання з делегування зворотної зони потрібно також направляти свого провайдера, тому що саме йому делеговано право управління зворотним зони цієї мережі.

Якщо Ви самі маєте статус LIR, то краще за все не читати це короткий опис, а звернутися до першоджерел на ripe.net.

Проте слід знати, що для делегування зони необхідно три речі:

• отримати адресний блок;

• забезпечити підтримку зони /16 або /24 відповідно до вимог RIPE NCC;

• направити заявку в RIPE NCC на делегування домену.

Адресний блок отримують у відповідності з документом RIPE "IPv4 Address Allocation and Assignment Policies in the RIPE NCC Service Region".

Вимоги щодо підтримки зони полягають в тому, що параметри запису SOA зони повинні відповідати RFC 1912. при цьому серійний номер зони слід записувати у вигляді YYYYMMDDnn.

Для зон /24 LIR повинен організувати два сервери (один у себе, а інший бажано в іншого провайдера, в усякому разі, має бути забезпечене незалежне підключення). Для зон /16 має бути забезпечено 3 сервери, причому один з них повинен бути сервер RIPE NCC ns.ripe.net. Він повинен виконувати функцію slave (secondary) для зони.

Заявка на делегування зони, яка надсилається в RIPE NCC роботу реєстрації на адресу auto-inaddr@ripe.net, повинна виглядати приблизно так:

domain: 65.35.80.in-addr.arpa

descr: Reverse delegation for Bluelight 2nd /24

admin-c: JJ231-RIPE

tech-c: JAJA1-RIPE

zone-c: WF2121-RIPE

nserver: ns.bluelight.nl

nserver: ns2.bluelight.nl

mnt-by: BLUELIGHT-MNT

changed: jan@bluelight.nl 19991110

source: RIPE

Про призначення полів і правила їх заповнення найкраще впоратися у вашого LIR, або в nic.ru, або в RIPE.

Насправді, загальний порядок при створенні своєї власної "зворотної" зони точно такий же, як і при створенні "прямий". Спочатку створюється її опис, і запускаються сервери, які будуть її обслуговувати, а потім заповнюються заявки і починається робота з провайдером.

Окремо звернемо увагу на те, що для кожної "зворотної" зони, яка відповідає мережі класу C (адреси в CIDR xxxx.xxxx.xxxx/24) потрібно своє власне опис зони. Не можна в один файл заважати кілька зон даного типу. Заважати їх може тільки у файлі, що описує батьківську зону типу xxxx.xxxx/16, наприклад, в зоні 206.144.in-addr.arpa можуть бути записи PTR для зон 160.206.144.in-addr.arpa і 192.206.144.in -addr.arpa, і то, тільки за умови, що дані зони не делеговані на інший сервер.

Дійсно, NS запис для делегування буде знаходитися в тому ж файлі опису зони, що записи PTR. BIND відловити цю колізію і проігнорує відповідні PTR запису.

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

Але насправді для невеликих компаній набагато більш серйозною проблемою стає делегування зворотних зон для пулів адрес, менших, ніж мережа класу С. Розглянемо цю проблему більш детально. Всі приклади братимемо з RFC 2317, тобто. саме воно рекомендоване RIPE NCC для вирішення нашої проблеми. Саме цей спосіб підтримується в самому RIPE NCC.

Спочатку про істоту проблеми. Провайдер "нашаткувати" в мережі класу С (пул адрес в нотації CIDR/24) на кілька частин. Таким чином кордони пулів адрес не доводяться на межі октетів.

Нехай ми маємо справу з мережею 192.0.2.0/24. Провайдер розділив адресний простір таким чином:

192.0.0/25 – організація А

192.0.128/26 – організація Б

192.0.192/26 – організація З

Класичне опис зворотного зони може виглядати приблизно так:

$ORIGIN 2.0.192.in-addr.arpa.

;

1 PTR host1.a.ru.

2 PTR host2.a.ru.

3 PTR host3.a.ru.

;

129 PTR host1.b.ru.

130 PTR host2.b.ru.

131 PTR host3.b.ru.

;

193 PTR host1.c.ru.

194 PTR host2.c.ru.

195 PTR host3.c.ru.

Делегувати підтримку такої зони можна тільки комусь одному. Всі інші будуть залежні від власника зони і всі зміни повинні будуть вносити через нього.

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

$ORIGIN 2.0.192.in-addr.arpa.

@ IN SOA ns.provider.ru. hostmaster.provider.ru. (…)

;

; 0-127 /25

;

0/25 IN NS ns.a.ru.

0/25 IN NS ns.slave.ru.

;

1 IN CNAME 1.0/25.2.0.192.in-addr.arpa.

2 IN CNAME 2.0/25.2.0.192.in-addr.arpa.

3 IN CNAME 3.0/25.2.0.192.in-addr.arpa.

;

; 129-191 /26

;

128/26 IN NS ns.b.ru.

128/26 IN NS ns.slave.ru.

;

129 IN CNAME 129.128/26.2.0.192.in-addr.arpa.

130 IN CNAME 130.128/26.2.0.192.in-addr.arpa.

131 IN CNAME 131.128/26.2.0.192.in-addr.arpa.

;

; 193-255 /26

;

192/26 IN NS ns.c.ru.

192/26 IN NS ns.slave.ru.

;

193 IN CNAME 193.192/26.2.0.192.in-addr.arpa.

194 IN CNAME 194.192/26.2.0.192.in-addr.arpa.

195 IN CNAME 195.192/26.2.0.192.in-addr.arpa.

Самі організації при цьому зобов'язані створити зони такого змісту:

$ORIGIN 0/25.2.0.192.in-addr.arpa.

@ IN SOA ns.a.ru hostmaster.a.ru (…)

IN NS ns.a.ru.

IN NS ns.slave.ru.

;

1 IN PTR host1.a.ru.

2 IN PTR host2.a.ru.

3 IN PTR host3.a.ru.

Для блоку 128/26 відповідно послідовність "0/25" слід замінити на "128/26", а сервер ns.a.ru на сервер ns.b.ru. Для блоку 192/26 потрібно також буде виконати відповідні заміни.

Ідея даного методу полягає в тому, що, потрапляючи в зону 2.0.192.in-addr.arpa, локальний сервер доменних імен або resolver на свій запит доменного імені отримують CNAME, тобто сервер зони каже, що ім'я, яке йому було повідомлено не є канонічним ім'ям хоста, зазначеним в адресній запису. Це лише синонімом канонічного імені. При цьому канонічне ім'я повідомляється в якості відповіді на запит. Звертаючись з канонічного імені, локальний сервер доменних імен або resolver отримують у відповідь посилання на інший сервер, оскільки в нашій зоні вказаний NS для підтримки зон з канонічними іменами. Переходячи на новий сервер, локальний сервер доменних імен або resolver отримують вже звичайну PTR запис ресурсів і можуть повідомити доменне ім'я додатком, яке ініціювало запит до зворотної зоні.

Може здатися накладним набивати велика кількість CNAME в зонах типу 2.0.192.in-addr.arpa. Але тут можна скористатися директивою керування $GENERATE, яка істотно скоротить число набираються вручну записів опису ресурсів.

Слід також звернути увагу на те, що імена зон у 2.0.192.in-addr.arpa можуть бути будь-якими допустимими іменами, а не тільки "0/25" або "192/26", як це зазначено у прикладі. Більше того, імена можуть вказувати на зони з абсолютно інших доменів, що не входять в in-addr.arpa. Правда, зони повинні містити відповідні PTR запису опису ресурсів.

Ми на самому початку цього матеріалу згадували про інверсних запитах, які не слід плутати зі стандартними запитами до серверів домену IN-ADDR.ARPA. Яка їх доля?

В принципі, підтримка інверсних запитів в серверах доменних імен можлива. У всякому разі, вони зобов'язані такі запити розпізнавати і відповідати на них, або списками доменних імен, або 0, або сполученням, про те, що дану опцію сервер не підтримує.

При цьому реальна область застосування такого сорту запитів обмежується рамками одного сервера.

І у висновку про те, навіщо взагалі потрібно шукати доменні імена по IP_адресам. Цьому є кілька причин.

По-перше, багато мережеві сервіси блокують доступ, якщо не можуть відобразити IP-адреса хоста, з якого до них звертаються, в доменне ім'я. Так чинять, наприклад, ftp-сервери і сервери електронної пошти.

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

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

Цікаво, що на 1999 рік за даними RIPE NCC з 163124 зон, які могли б бути делеговані (зареєстровані IP-адреси), реально було делеговано тільки 85352 або приблизно 52%.

І ще одне зауваження. Ми тут взагалі не розглядали "зворотне" відображення в рамках такої "екзотики", як адресний простір IPv6. Насправді сучасні версії BIND чудово справляються з цим завданням, але про це якось іншим разом.

Головні і другорядні сервери DNS

Майстер, або первинний сервер (в термінології BIND) – має право на внесення змін до даних зони. Зазвичай зоні відповідає тільки один майстер-сервер. У разі Microsoft DNS-сервера і його інтеграції з Active Directory майстер-серверів може бути декілька (так як реплікація змін здійснюється не засобами DNS-сервера, а засобами Active Directory, за рахунок чого забезпечується рівноправність серверів і актуальність даних).

Слейв, або вторинний сервер, який не має права на внесення змін до даних зони і отримує повідомлення про зміни від майстер-сервера. На відміну від майстер-сервера, їх може бути (практично) необмежена кількість. Слейв також є авторитативним сервером (і користувач не може розрізнити майстер і слейв, різниця з'являється тільки на етапі конфігурування/внесення змін в налаштування зони).

Вторинний сервер потрібен для забезпечення надійності (відмовостійкість), коли первинний сервер не в змозі обробити запит, цей запит переходить до вторинного сервера. Вторинний сервер не обов’язково має бути один, і чим більше вторинних серверів тим більше надійність.

Кешування запитів

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

Основи налаштування служби доменних імен

Так як сервер імен BIND встановлюється за замовчуванням, його настроювання порівняно проста.

Стандартна конфігурація named запускає простий кешуючий сервер в обмеженому середовищі chroot, який прослуховує запити на інтерфейсі зворотного зв'язку (loopback) з адресою (127.0.0.1). Для одноразового запуску демона в цій конфігурації використовуйте команду

# /etc/rc.d/named onestart

Щоб демон named запускався під час завантаження, помістіть в /etc/rc.conf наступний рядок:

named_enable="YES"

Файли конфігурації демона named розташовані в каталозі /etc/namedb і, за винятком випадку, коли вам потрібно просто Резолвер, вимагають модифікації.

Налаштування за замовченням головного файлу /etc/namedb/named.conf підійдуть до більшості випадків використання сервера.

Для кожного нової зони, яку обслуговуватиме сервер імен, у файл named.conf повинна бути додана запис.

Наприклад, найпростіша запис для домену example.org може виглядати ось так:

zone "example.org" {

type master;

file "master/example.org";

};

Зона є первинною, що відображається в полі type, і інформація про зону зберігається у файлі /etc/namedb/master/example.org, що вказується в полі file.

zone "example.org" {

type slave;

file "slave/example.org";

};

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

Приклад файлу зони example.org для основного сервера (що розташовується у файлі /etc/namedb/master/example.org) має такий вигляд:

$TTL 3600 ; 1 hour default TTL

example.org. IN SOA ns1.example.org. admin.example.org. (

2006051501 ; Serial

10800 ; Refresh

3600 ; Retry

604800 ; Expire

300 ; Negative Response TTL

)

; DNS Servers

IN NS ns1.example.org.

IN NS ns2.example.org.

; MX Records

IN MX 10 mx.example.org.

IN MX 20 mail.example.org.

IN A 192.168.1.1

; Machine Names

localhost IN A 127.0.0.1

ns1 IN A 192.168.1.2

ns2 IN A 192.168.1.3

mx IN A 192.168.1.4

mail IN A 192.168.1.5

; Aliases

www IN CNAME example.org.

Зауважте, що всі імена хостів, що закінчуються на «.», Задають повне ім'я, тоді як всі імена без символу «.» На кінці вважаються заданими щодо origin. Наприклад, ns1 перетвориться в ns1.example.org.

Файл зони має наступний формат:

recordname IN recordtype value

Найбільш часто використовувані записи DNS:

• SOA - початок зони відповідальності;

• NS - авторитативним сервер імен;

• A - адреса хоста;

• CNAME - канонічне ім'я для аліаса;

• MX - обмін поштою;

• PTR - покажчик на доменне ім'я (використовується в зворотних зонах DNS).

example.org. IN SOA ns1.example.org. admin.example.org. (

2006051501 ; Serial

10800 ; Refresh after 3 hours

3600 ; Retry after 1 hour

604800 ; Expire after 1 week

300 ) ; Negative Response TTL

example.org. – ім'я домену, а також Оріджін для цього файлу зони.

ns1.example.org. – основний/авторитативним сервер імен для цієї зони.

admin.example.org. – людина, що відповідає за цю зону, адресу електронної пошти з символом «@» заміненим на точку. (<admin@example.org> стає admin.example.org).

2006051501 – послідовний номер файлу. При кожній зміні файлу зони це число має збільшуватися. В даний час для нумерації багато адміністраторів вважають за краще формат ггггммддвв. 2006051501 означатиме, що файл востаннє змінювався 15.05.2006, а останнє число 01 означає, що це була перша модифікація файлу за день. Послідовний номер важливий, оскільки він служить для того, щоб вторинні сервери дізнавалися про оновлення зони.

IN NS ns1.example.org.

Це NS-запис. Такі записи повинні бути для всіх серверів імен, які будуть відповідати за зону.

localhost IN A 127.0.0.1

ns1 IN A 192.168.1.2

ns2 IN A 192.168.1.3

mx IN A 192.168.1.4

mail IN A 192.168.1.5

Записи типу A служать для позначення імен машин. Як це видно вище, ім'я ns1.example.org буде перетворено в 192.168.1.2.

IN A 192.168.1.1

Цей рядок привласнює IP адреса 192.168.1.1 поточного Оріджін, в даному випадку домену example.org.

www IN CNAME @

Записи з канонічними іменами зазвичай використовуються для присвоєння машинам псевдонімів. У цьому прикладі www є псевдонімом для «головною» машини, ім'я якої з волі випадку співпало з ім'ям домену example.org (192.168.1.1). Записи типу CNAME не можна використовувати спільно з іншими типами записів для одного і того ж імені хоста (recordname).

IN MX 10 mail.example.org.

MX-запис вказує, які поштові сервери відповідають за обробку вхідної електронної пошти для зони. mail.example.org є ім'ям поштового сервера, а 10 позначає пріоритет цього поштового сервера.

Можна мати кілька поштових серверів з пріоритетами, наприклад, 10, 20 і так далі. Поштовий сервер, який намагається доставити пошту для example.org, спочатку спробує зв'язатися з машиною, що має MX-запис з найбільшим пріоритетом (найменшим числовим значенням у полі MX), потім з пріоритетом трохи менше і так далі, до тих пір, поки пошта не буде відправлена.

Для файлів зон in-addr.arpa (зворотні записи DNS) використовується той же самий формат, що відрізняється тільки використанням записів PTR замість A або CNAME.

$TTL 3600

1.168.192.in-addr.arpa. IN SOA ns1.example.org. admin.example.org. (

2006051501 ; Serial

10800 ; Refresh

3600 ; Retry

604800 ; Expire

300 ) ; Negative Response TTL

IN NS ns1.example.org.

IN NS ns2.example.org.

1 IN PTR example.org.

2 IN PTR ns1.example.org.

3 IN PTR ns2.example.org.

4 IN PTR mx.example.org.

5 IN PTR mail.example.org.

У цьому файлі дається повна відповідність імен хостів IP-адресами в нашому описаному раніше вигаданому домені.

Слід зазначити, що всі імена в правій частині PTR-записи повинні бути повними доменними іменами (тобто, закінчуватися точкою «.»).