Новини освіти і науки:

G+

Тлумачний словник
Авто
Автоматизація
Архітектура
Астрономія
Аудит
Біологія
Будівництво
Бухгалтерія
Винахідництво
Виробництво
Військова справа
Генетика
Географія
Геологія
Господарство
Держава
Дім
Екологія
Економетрика
Економіка
Електроніка
Журналістика та ЗМІ
Зв'язок
Іноземні мови
Інформатика
Історія
Комп'ютери
Креслення
Кулінарія
Культура
Лексикологія
Література
Логіка
Маркетинг
Математика
Машинобудування
Медицина
Менеджмент
Метали і Зварювання
Механіка
Мистецтво
Музика
Населення
Освіта
Охорона безпеки життя
Охорона Праці
Педагогіка
Політика
Право
Програмування
Промисловість
Психологія
Радіо
Регилия
Соціологія
Спорт
Стандартизація
Технології
Торгівля
Туризм
Фізика
Фізіологія
Філософія
Фінанси
Хімія
Юриспунденкция

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

Завдання пошуку доменного імені за 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 чудово справляються з цим завданням, але про це якось іншим разом.

Читайте також:

<== попередня сторінка	\|	наступна сторінка ==>
Поняття доменних зон	\|	Основи налаштування служби доменних імен

Не знайшли потрібну інформацію? Скористайтесь пошуком google:

Генерація сторінки за: 0.019 сек.