Рашид Ачілов

Створюємо зони DNS

Domain Name System- своєрідна "нервова система" мережі Інтернет. Саме завдяки їй ви, набираючи, потрапляєте на сайт журналу «Системний адміністратор», а не кудись ще. Як створити, налаштувати та запустити DNS-сервер для невеликого підприємства?

Структура DNS

В даний час Інтернет - це величезна мережа, в яку входять мільйони вузлів, які розташовані по всьому світу. Для того щоб запит, зроблений з одного комп'ютера, міг досягти мети, розташованої на іншому комп'ютері, потрібно насамперед цю мету поставити. Можна, звичайно, вказати IP-адресу безпосередньо. Якщо він вам відомий, звісно. Але тут існує можливість дуже просто помилитися - інформація про те, де знаходиться потрібна вам адреса вже могла змінитися, і в найкращому випадкуви побачите повідомлення про те, що адреса не знайдена, а в гіршому – опинитеся на сайті, який абсолютно не має жодного відношення до того, що було потрібно. Надійніше та простіше звернутися до системи, яка зберігає відповідність між символічними іменами типу www.сайт та IP-адресами, що відповідають їм у даний момент (у нашому випадку 217.144.98.99). DNS і є такою системою. Оскільки від її успішного функціонування залежить робота всієї мережі Інтернет, ця система функціонує за принципом розподіленої бази даних – є «добре відомі» сервери, числом 13, їх ще називають «кореневими» (root servers), що містять інформацію про сервери, що містять інформацію про сервери і т. д. Як будинок, який збудував Джек.

Вся мережа Інтернет, яка описується зоною "." (Точка) ділиться на так звані TLD (Top Level Domains – домени верхнього рівня), що розподіляються або за функціональною, або за географічною ознакою. Існує також термін primary domain - "первинний домен", або "домен першого рівня", але цей термін використовується значно рідше. Розподіл за географічною ознакою здійснюється відповідно до ISO 3166, що встановлює для всіх країн світу дво- та трилітерні коди. Розподіл за функціональною ознакою здійснюється при необхідності створення нового TLD. Тут слід зазначити, що всіма питаннями щодо TLD займається ICANN (Internet Corporation for Assigned Names and Numbers), і саме цей орган вирішує чи створювати новий TLD.

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

Таким чином, процес пошуку інформації, припустимо, про веб-сервер www.granch.ru, буде виглядати наступним чином:

• Клієнт звертається до свого сервера DNS, адреса якого була задана системним адміністратором із запитом «Скажи мені адресу, що відповідає імені www.granch.ru».
• Сервер DNS знає адреси серверів, з яких слід починати пошук у тому випадку, якщо в його кеші не зберігається запитана інформація, тому він звертається до одного з них.
• Кореневий сервер надсилає йому адресу сервера, що відповідає за зону.
• Сервер DNS звертається до сервера зони.
• Сервер зони.ru надсилає йому адресу сервера, який відповідає за зону granch усередині його зони.
• Сервер DNS звертається до сервера зони granch.
• І нарешті, сервер зони granch.ru повідомляє йому адресу, що відповідає імені www. У даному випадкуце буде 81.1.252.58.

Цей процес проілюстрований на рис. 1 де цифри позначають послідовність запитів.

Як вбудувати інформацію в структуру DNS?

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

Куди вбудовуємо?

За різні TLD відповідають різні сервери, і якщо за географічні домени відповідає, як правило, один сервер (точніше кажучи, одна організація), то за функціональні домени може відповідати, взагалі кажучи, необмежену кількість так званих реєстраторів, тобто компаній, які уклали спеціальні договори з ICANN про те, що саме вони реєструватимуть імена в деяких функціональних доменах. Короткий опис функціонального домену та адреса його реєстратора наведено у .

Якщо реєстраторів кілька, то дається адреса основної (наприклад, VeriSign для домену.com). Домени.gov і.mil зарезервовані виключно за американським урядом і американськими військовими організаціями, причому резервування.gov оформлене відповідним RFC - RFC 2146 . Повний список усіх існуючих у теперішній моментгеографічних ж TLD із зазначенням реєстратора домену та необхідної контактної інформації можна подивитися в . Хоча якщо, скажімо, в зоне.com можна вибирати з величезного списку, то для зон.ru і.su РУЦЕНТР, без варіантів.

Тут слід зазначити кілька моментів. Фактично зона.su належить до неіснуючої держави радянський Союз(Soviet Union), хоча продовжує обслуговуватися і відкрита для реєстрації. Реєстрація там досить дорога – 100 доларів за реєстрацію чи підтримку на рік.

Немає пріоритету, згідно з яким одна організація або людина має перевагу при реєстрації домену над іншим. Один американський бізнесмен, котрий займався виробництвом пластикових вікон, зареєстрував домен windows2000.com. Коли те саме спробувала зробити Microsoft, вона з подивом виявила, що це ім'я вже зайняте, і за нього компанії довелося викласти велику суму. Існує навіть поняття «кіберсквотерство» – процес реєстрації доменів з метою їхнього подальшого перепродажу. РУЦЕНТР теж вирішив прикласти до цього руку, і за новими правилами, які вводяться з 1 червня 2006 року, домени, що звільняються, виставляються на «аукціон доменних імен» і передаються тому, хто дасть більше. Імена утримуються на «аукціоні» протягом року, якщо за цей термін ніхто на нього не претендує, ім'я виводиться у вільну реєстрацію.

При створенні перерахованих вище TLD планувалося також створення TLD .xxx для сайтів з тематикою «для дорослих». ICANN відхилила цю пропозицію. Нещодавно його було винесено на повторне голосування, і ICANN знову його відхилила. Натомість з'явився TLD .tel, розрахований на використання одночасно у комп'ютерах та мобільних пристроях.

Існує RFC 1480, що описує правила реєстрації імен домену. Правила ці надзвичайно громіздкі і заплутані і передбачають створення імен із 6-7 рівнів типу Hamilton.High.LA-Unified.K12.CA.US

Як вбудовуємо?

Раніше все було набагато складніше. Для реєстрації зони.com мені довелося заповнювати безліч текстових форм - з даними на організацію, з даними на контактних осіб... Ці форми потім надсилалися на спеціальні адреси, звідки приходили відповіді - прийняті чи ні. Потім попередньо сформований файл зони тестувався, і знову ж таки поштою надходило повідомлення про те, успішно завершено тестування чи ні.

Нині все стало набагато простіше. І Network Solutions, і РУЦЕНТР обзавелися веб-інтерфейсами, за допомогою яких усе перераховане вище (за винятком, звичайно, складання файлу зони) можна зробити кількома кліками миші. Усі дані можна виправити, доповнити чи видалити будь-якої миті. Раніше з РУЦЕНТРом потрібно укладати договір на обслуговування, але починаючи з 1 червня 2006 року в дію вводяться нові правила, згідно з якими достатньо зареєструватися на їхньому сайті. Закордонні реєстратори, як правило, обходяться кредитними картками, але якщо домен з будь-якої причини не може бути зареєстрований, гроші будуть повернуті не раніше ніж через три дні.

Реєстратору потрібно вказати IP-адресу та маску підмережі сервера, на якому буде запущено програму DNS-сервера, і який міститиме основну базу даних, яку створюється і редагується вами в міру необхідності. Цей сервер називатиметься первинним сервером (master server). Крім того, потрібно вказати як мінімум одну IPадресу сервера, що містить резервну копіюбази у разі відмови первинного сервера. Такі сервери називають вторинними серверами (slave servers). Щоб довго не думати про те, де розмістити вторинний DNS, РУЦЕНТР пропонує розмістити його на їхньому майданчику. Вартість послуг РУЦЕНТРу становить 15 доларів на рік за домен у зонах.ru, .net, .com, .org, 50 доларів за домен у зонах.biz, .info, 100 доларів за домен у зоні. підтримку вторинного DNS у будь-якій (у тому числі й зареєстрованій не мають) зоні.

Чому вимога до наявності вторинного DNS-сервера є обов'язковою? Оскільки стабільність роботи DNSвкрай важлива стабільність роботи мережі Інтернет загалом, то особа чи організація, реєструюча домен, зобов'язана задовольняти деяким умовам, що стосуються стабільності роботи DNS:

• Повинно бути передбачено не менше двох серверів, які обслуговують цей домен.
• Ці сервери повинні бути доступні щонайменше 22 години на добу.

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

www.krokodil.ru

Отже, припустимо, ми хочемо створити сайт www.krokodil.ru (на момент написання статті це ім'я було вільним), присвячений розведенню крокодилів у домашніх умовах. Підключення за виділеною лінією є, мережа класу С, а саме 212.20.5.0 – 212.20.5.255 (цей діапазон в даний час вільний) провайдером виділено. Цей приклад дещо нехарактерний для сьогодення з його дефіцитом IP-адрес, але він узятий спеціально для того, щоб розглянути створення зворотної зони. Також буде розглянуто варіант із підключенням через мережу 212.20.5.0/31. Внутрішня мережа нашої крокодилячої контори складається з шести комп'ютерів і буде відокремлена від Інтернету firewall-proxy і т.д. керуванням FreeBSD. Що нам знадобиться для здійснення задуманого?

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

По-перше, нам знадобиться програма DNS-сервера. На сьогоднішній день лише одна програма реалізує необхідний набір функцій. Це DNS-сервер BIND, що розповсюджується ISC (Internet System Consortium Inc., ) - Некомерційною організацією, яка займається розробкою серверів BIND, DHCP, INN і NTP. Якщо він відсутній у вашій системі, його потрібно завантажити та встановити. FreeBSD поставляється разом з BIND 9.3.2, тому в цій статті розглядатиметься саме ця версія. Слід зазначити, що для версій BIND 8.x опис конфігурації, що наводиться нижче, абсолютно неприйнятно, оскільки формат конфігураційних файлів BIND 8.x докорінно відрізняється від формату конфігураційних файлів BIND 9.x.

По-друге, знадобиться розподілити виділені IP-адреси і наділити адресами внутрішні комп'ютери. Тут все надзвичайно просто: нехай 212.20.5.1 - шлюз провайдера, 212.20.5.2 - адреса UNIX-сервера, 10.87.1.0/24 - внутрішня підмережа, в якій з 1-ї по 6-й - робочі станції, 254 - адреса сервера. Решта адрес буде зарезервована для майбутнього розширення.

По-третє, потрібно заздалегідь підготовлений файл опису зони, який визначатиме не велика кількістьзовнішніх адрес: krokodil.ru - кореневий сервер зони, www.krokodil.ru, ftp.krokodil.ru, mail.krokodil.ru та ns.krokodil.ru. Ім'я ns (nameserver) є практично традиційним найменуванням комп'ютерів, на яких працює служба DNS, хоча, звичайно, ніхто не завадить вам назвати його, наприклад, jaws.krokodil.ru. Буде визначено також імена для комп'ютерів внутрішньої мережі, доступні лише зсередини: tooth1.krokodil.ru – tooth6.krokodil.ru.

Записи DNS

Існує досить багато типів різноманітних записів, які можна поміщати в DNS. Обсяг цієї статті дозволяє розглянути лише найважливіші з них, для отримання повної інформації слід звернутися до відповідних RFC: RFC 1033 та RFC 1035 визначають формати основних записів, RFC 1122 – формат запису PTR, RFC 2782 – формат запису SRV. Ми розглянемо лише записи, які знадобляться для формування файлів зон, необхідні реєстрації домену:

• Запис SOA, що задає початок опису зони.
• Запис NS, що визначає сервер імен зони.
• Запис A, що задає відповідність між IP-адресою та ім'ям (пряме перетворення).
• Запис MX, який описує настройки доставки пошти для даного комп'ютера.
• Запис CNAME задає альтернативні імена.
• Запис PTR, що задає відповідність між ім'ям та IPадресою (зворотне перетворення), використовується в описі «зворотної» зони.

Формат записів DNS загальний для всіх типів записів:

[ім'я] [клас]<тип> <данные>

• ім'я- Це ім'я об'єкта, з яким асоціюються дані;
• ttl- Час життя об'єкта;
• клас- Клас запису;
• тип- Тип запису;
• дані- Асоційовані з цим об'єктом дані.

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

• Завдання імені зони в директиві $ORIGIN, наприклад:

$ORIGIN krokodil.ru

• Завдання імені зони в директиві zone конфігураційного файлу BIND.

Спеціальний символ "@" означає поточне ім'я зони. Майте на увазі, що директива $ORIGIN скасовує директиву zone і діє до появи наступної директиви $ORIGIN або до кінця файлу. До моменту появи першої директиви $ORIGIN вона вважається заданому значеннюдирективи zone конфігураційного файлу BIND.

Якщо ім'я задано, воно має починатися з першої позиції рядка.

TTL зазвичай опускається і задається глобально директивою $TTL. Директива $TTL для BIND 9.x є обов'язковою і, як правило, задається на початку файлу. У полі даних цієї директиви визначається час життя (в секундах) елемента, протягом якого він може знаходитися в кеші і вважатися достовірним. У даному прикладіце дві доби (48 годин).

$TTL 172800

Клас запису може приймати одне з таких значень:

• IN- Запис ресурсів Інтернет.
• CH– запис ресурсів ChaosNet – абсолютно незнайомий російському користувачумережі, що застосовувалась на машинах фірми Symbolics.
• HS– запис ресурсів Hesiod – службового протоколу BIND.

Тип запису – одне із типів, перелічених вище.

Слід звернути увагу, що поля ім'я, ttl і клас можуть бути опущені. При цьому як їх значення приймається останнє певне значення (при цьому завдання @ буде коректним визначенням), а якщо значення не було визначено ніде, то для поля клас приймається значення за умовчанням «IN», для інших полів – призводить до повідомлення про помилку.

Окрім записів, у файлі зони можуть бути команди. Усього команд чотири – $TTL, $ORIGIN, $INCLUDE та $GENERATE. Опис команди $GENERATE наведено в документації на програму BIND, а також і, команда $INCLUDE працює відповідно до свого написання - включає вказаний файлу поточний файл.

Примітка: знак ";" (Точка з комою) є ознакою коментаря.

Запис SOA

Цей запис визначає початок зони. Будь-яка зона повинна починатися із запису SOA. Поява іншого запису SOA автоматично закінчує першу зону та починає другу. Формат запису SOA наведено нижче. Практично запис SOA називає зону і задає для неї деякі умовчання.

2005122001; Serial number

3600; Retry every hour

172800); Minimum 2 дні

Розберемо приклад. Знак @ у полі імені означає, що потрібно взяти ім'я зони, задане раніше директивою $ORIGIN. Клас запису – IN, тип запису – SOA. SOA – це єдиний запис, який має такий складний перелік параметрів.

Перший параметр – це адреса головного сервера імен зони. У цьому прикладі це krokodil.ru. Другий параметр – адреса електронної пошти особи, відповідальної за дану зону. Зверніть увагу, що адреса записана як username.domain, а не username@domain.

Другий параметр – це список значень, укладений у дужки. Теоретично можна його записати в один рядок, але майже я ніде цього не бачив, всюди використовується форма запису, наведена в прикладі. Список складається з п'яти елементів:

• Серійний номер зони. Цей параметр грає надзвичайно важливу рольу поширенні оновлення, виконаного на первинному сервері, за всіма його вторинними серверами. Необхідно якимось чином повідомити вторинний сервер про те, що дані на первинному сервері змінилися. Якщо первинний сервер був перезапущений, він відсилає всім вторинним серверам повідомлення про можливу зміну (DNS NOTIFY). Отримавши це повідомлення, вторинний сервер запитує серійний номер – якщо на первинному сервері серійний номер більше, ніж вторинному, вторинний сервер виконує команду оновлення зони. Крім того, вторинний сервер виконує періодичні перевірки серійного номера з тією самою метою. Тому слід запам'ятати одне просте правило: виправив зону – збільши серійний номер! Серед адміністраторів DNS поширена практика, відповідно до якої серійний номер формується так: YYYYMMDDv, де:
  • YYYY, MM, DD– поточний рік (4 цифри), місяць та день відповідно
  • v- Версія зони за день. Якщо вноситься кілька змін на день, число послідовно збільшується на одиницю.
Звичайно, вас ніхто не зобов'язуватиме слідувати подібній практиці. Наприклад, сервери DNS у Windows її не дотримуються, а просто нумерують її 1, 2, 3 і т.д.
• Значення періоду оновлення, після якого підпорядкований сервер повинен зв'язатися з головним і перевірити, чи серійний номер зони не змінився. Якщо серійний номер змінився, підпорядкований сервер завантажить нові дані. У цьому прикладі 10800 секунд (3 години).
• Час, через який підлеглий сервер намагатиметься звернутися до головного, якщо спроба отримати новий серійний номер закінчилася невдало. У цьому прикладі 3600 секунд (одна година).
• Час, протягом якого підлеглі сервери обслуговуватимуть запити по цій зоні за тривалої відсутності головного сервера . Система має працювати, навіть якщо головний серверне працює тривалий період часу, тому у значенні даного параметра встановлено 1728000 секунд (20 діб).
• Час кешування негативних відповідей. У цьому прикладі 172800 секунд (2 доби).

Запис NS

Цей запис визначає імена серверів, що підтримують зону, тобто. провідних її основу. Тут мають бути перераховані імена первинного та всіх вторинних серверів. Зазвичай цей запис слідує безпосередньо за записом SOA. У полі дані заноситься одне значення – ім'я або IP-адреса сервера DNS-зони незалежно від того, чи вона головна чи підлегла. Усі вказані тут імена мають бути повністю визначеними, тобто закінчуватись точкою!

IN NS ns.krokodil.ru.

IN NS ns4.nic.ru

У наведеному прикладі описується спочатку головний сервер нашої зони ns.krokodil.ru, та був підлеглий сервер – вузол РУЦЕНТРа ns4.nic.ru.

Запис A

Запис типу A – це основний вміст файлів зони прямого перетворення або просто «прямої» зони, тобто видає ім'я комп'ютера за його адресою. Вона складається кожного комп'ютера. Для зручності читання ці записи зазвичай групуються в порядку зростання IP-адрес, а також групуються із записами MX, що відповідають даній IP-адресі, хоча це, звичайно, не є обов'язковим. У полі ім'я заноситься ім'я, яке призначається IP-адресою, у полі дані – IP адреса, якій призначається ім'я. За наявності адреси додаткових імен, ім'я, призначене адресою записом типу A, називають основним ім'ям.

tooth1 IN A 10.87.1.1

tooth2 IN A 10.87.1.2

tooth3 IN A 10.87.1.3

tooth4 IN A 10.87.1.4

tooth5 IN A 10.87.1.5

tooth6 IN A 10.87.1.6

У цьому прикладі описано призначення IP-адрес комп'ютерам внутрішньої мережі, яка має адресу 10.87.1.0/24. Для комп'ютерів внутрішньої мережі, зазвичай, немає необхідності формування будь-яких додаткових записів, крім хіба що CNAME.

Запис CNAME

Запис типу CNAME – це додаткова можливість DNS. Вона дозволяє призначити одній IP-адресі більше одного імені. У полі ім'я заноситься додаткове ім'я, яке призначається IP-адресою, у поле дані – основне ім'я, призначене раніше записом типу A, або інше додаткове ім'я, призначене записом CNAME. При цьому ім'я, яке стоїть у полі даних запису, називають канонічним (звідси назва запису – Canonical Name). Однією IP-адресою можна призначити необмежену кількість додаткових імен за допомогою записів CNAME, але в записах іншого типу має бути вказане ім'я, призначене записом A, а не записом CNAME. Нижче наведено приклад правильного та неправильного призначення додаткових імен.

Правильно:

ns IN A 10.87.1.1

name1 IN CNAME ns

IN MX 10 ns

Неправильно:

ns IN A 10.87.1.254

name1 IN CNAME ns

IN MX 10 name1

Записи CNAME можуть вказувати одна на іншу, але не більше семи рівнів, восьмий обов'язково повинен йти запис, який вказує на ім'я, призначене записом типу A. У літературі зустрічається рекомендація використовувати множинні записи типу A замість призначення адресою безлічі додаткових імен. З цього приводу можна сказати, що на даний момент згадується в RFC 2219 у плані «не існує абсолютних рекомендацій з цього приводу, кожен повинен вирішувати для себе, що для нього краще». Численні CNAME простіше для адміністрування, множинні A-записи легше обробляються, оскільки відбувається менше перенаправлень.

Запис MX

Запис типу MX – це другий елемент файлу зони. Цей запис розшифровується як "Mail eXchanger", і призначений для вказівки IP-адрес або імен комп'ютерів, які приймають пошту для вузла, описаного в полі name. У цьому полі може бути порожнім, а також вказано повністю або не повністю визначене ім'я. Якщо поле name порожнє або вказано не повністю визначене ім'я, то ім'я доповнюється з директиви $ORIGIN. Формування записів MX у складних випадках, коли налаштовується досить велика зона з розгалуженою схемою прийому пошти, – дуже нетривіальне завдання, яке тісно переплітається з роботою програм, які використовують протокол SMTPдля доставки пошти, тому ми розглянемо найпростіший випадок – вся пошта приймається сервером UNIX. У полі дані заносяться два значення – пріоритет та ім'я або IP-адреса комп'ютера, що приймає пошту, що спрямовується на цей комп'ютер. З однією IP-адресою може бути пов'язано, взагалі кажучи, необмежену кількість записів типу MX, і всі вони повинні мати різний пріоритет. Пошта направляється відповідно до пріоритету – поштовий агент сортує записи у порядку наростання пріоритетів і саме так робить спроби доставити пошту. Припустимо, ми домовилися з адміністратором вузла behemot.ru про те, що зможемо використовувати його сервер як транзитний вузол, який отримуватиме нашу пошту з метою подальшої доставки її адресатам, коли зв'язок відновиться. Тоді опис сервера krokodil.ru буде виглядати так:

krokodil.ru. IN A 212.20.5.2

IN MX 10 krokodil.ru

IN MX 50 behemot.ru

www IN CNAME krokodil.ru.

mail IN CNAME krokodil.ru.

ftp IN CNAME krokodil.ru.

Це комплексний приклад, він одразу показує використання записів MX, А та CNAME. Тут ми:

• Призначаємо адресою 212.20.5.2 ім'я krokodil.ru.
• Вказуємо, що пошту, яка надсилається за адресами типу [email protected], прийматимуть (у зазначеному порядку):
• сервер krokodil.ru;
• сервер behemot.ru
• Визначаємо додаткові імена www.krokodil.ru, mail.krokodil.ru та ftp.krokodil.ru. Зверніть увагу, що всі імена у правій частині повністю визначені, тобто закінчуються на точку. Якщо цього не зробити, то в кінці імені автоматично підставлятиме значення поточної директиви $ORIGIN. В даному випадку це призвело до появи імен типу www.krokodil.ru.krokodil.ru.

Запис PTR

Це особливий тип записів. У нашому прикладі ми «спеціально» взяли повну підсітку, щоб розглянути випадок «нормальної» роботи із записами PTR. Випадок із мережею 212.20.5.0/31 буде розглянутий трохи згодом.

Запис PTR призначений реалізації зворотного перетворення – імен в IP-адреси. Подібні перетворення дуже широко застосовуються в різних програмах, що надають доступ до деяких мережевих ресурсів: вони перевіряють відповідність прямого та зворотного перетворення і у разі розбіжності або відсутності запису PTR можуть відмовити у доступі. Зона, що містить записи PTR, називається зоною зворотного перетворення або просто «зворотною» зоною.

Записи PTR не мають жодного відношення до записів A, MX, CNAME та інших, що описують пряме перетворення. Зроблено це навмисно з метою використовувати для обох перетворень той самий набір програмних модулів. Тут, щоправда, на нас чекає складність наступного виду- Повністю певне доменне ім'я виду www.krokodil.ru. «нарощує розмірність» зліва направо (тобто укрупнення вузлів йде у міру просування текстом імені зліва направо), а IP-адреса 212.20.5.2 – справа наліво. Для уніфікації програмних модулів прийняли таку умовність: всі IP-адреси – це імена, що входять до спеціального TLD in-addr.arpa. "Зонами" в цьому домені є підмережі, а ім'я зони записується у вигляді IP-адреси, що читається навпаки. Таким чином, "ім'я" нашої зворотної зони буде 5.20.212.in-addr.arpa для зворотної зони, що містить опис для зовнішньої мережі і 1.87.10.in-addr.arpa для зворотної зони, що містить опис внутрішньої мережі.

Точно так, як для використання доменного імені необхідно його зареєструвати, так і для використання зворотного перетворення необхідно зареєструвати зворотну «зону» у координатора зворотних зон. На відміну від зон прямого перетворення тут є лише один координатор, і реєстрація в нього безкоштовна. Реєстрацією зворотних зон займається RIPE NCC. Вся інформація про реєстрацію зворотної зони наведена в .

Для чого потрібно реєструвати зворотну зону? Сервер верхнього рівня зони in-addr.arpa повинен знати, що для виконання запиту зворотного перетворення йому слід звернутися до сервера, в даному випадку до нашого 212.20.5.2. Зрозуміло, будь-де реєструвати зворотну зону внутрішньої підмережі не потрібно.

Сам запис PTR виглядає дуже просто – у поле ім'я заноситься остання частина IP-адреси, у поле дані – цілком певне ім'я прямого перетворення. Звертаю увагу на останнє – ім'я, що заноситься в поле даних, має бути повністю визначеним, оскільки записи PTR самі задають зв'язок між IP-адресою та ім'ям, вони не можуть отримати нізвідки інформацію про те, до якої зони слід віднести не повністю кваліфіковане ім'я прямого перетворення .

$ORIGIN 1.87.10.in-addr.arpa

1 IN PTR tooth1.krokodil.ru.

2 IN PTR tooth2.krokodil.ru.

3 IN PTR tooth3.krokodil.ru.

4 IN PTR tooth4.krokodil.ru.

5 IN PTR tooth5.krokodil.ru.

6 IN PTR tooth6.krokodil.ru.

У цьому прикладі ми задали зворотне перетворення для комп'ютерів внутрішньої мережі. Для сервера ми запишемо один рядок (у реальному прикладі директиви $ORIGIN вказувати не треба, вони наведені тільки щоб було зрозуміло, про яку зону йдеться):

$ORIGIN 5.20.212.in-addr.arpa

2 IN PTR krokodil.ru

Тут слід зазначити, що записи CNAME для завдання множинної зворотної відповідності не використовуються, тому при запиті «яке ім'я відповідає адресі 212.20.5.2» результатом завжди буде krokodil.ru незалежно від кількості встановлених для нього псевдонімів.

Чим відрізнятиметься випадок, коли провайдер виділяє блок 212.20.5.0/31 замість повноцінної підмережі? З погляду формування всіх записів, крім PTR, нічим. Процедура створення прямої зони та її реєстрації не залежить від кількості адрес, тим більше, що для більшості випадків багато адрес і не треба. Проте з погляду записів PTR різниця є. У бік спрощення. А може, й ні – залежно від провайдера. І полягає вона в тому, що записи:

gate.krokodil.ru. IN A 212.20.5.1

krokodil.ru. IN A 212.20.5.2

будуть перебувати на вашому сервері і керуватися вами, але записи:

1 IN PTR gate.krokodil.ru.

2 IN PTR krokodil.ru.

повинні бути сформовані провайдером, тому що можливість самому реєструвати зворотну зону і самому їй керувати надається лише за наявності мережі класу не менше ніж С. Це, з одного боку, полегшує роботу – не потрібно реєструватися в RIPE, але з іншого боку, ускладнює – для внесення змін в ім'я сервера потрібно щоразу зв'язуватися з провайдером.

Файлова структура

Самому BIND, звичайно, все одно, в якому порядку йдуть записи і як вони відформатовані. Це важливо лише тим, хто супроводжуватиме зону, особливо, якщо зміни до неї вноситимуться часто. Тут я опишу розподіл зон файлами так, як це використовується в тих зонах, які я супроводжую. Зрозуміло, це не єдиний можливий лад і, можливо, не найкращий. Але це працює.

Зони зовнішні та внутрішні

BIND 8.x мав один надзвичайно великий недолік - він не дозволяв диференціювати інформацію, що видається залежно від будь-яких факторів - доводилося або показувати зайве, або приховувати потрібне. Зовнішнім клієнтам немає потреби знати про наявність комп'ютерів внутрішньої мережі, але, оскільки розділити інформацію було можливості, будь-який комп'ютер міг встановити структуру внутрішньої мережі у вигляді запитів DNS. BIND 9.x вільний від цього недоліку – він дозволяє за допомогою списків керування доступом (Access Control List, АСL) розподілити запити щодо «уявлень» (views). Уявлення може мати довільні імена, зазвичай створюється внутрішнє уявлення «internal», якому задовольняють клієнти внутрішньої підмережі, і зовнішнє уявлення «extrenal», якому задовольняють й інші. Тут пам'ятайте, що це одна і та ж зона, просто показується вона по-різному - як правило, у файлах зовнішніх зон присутня тільки та інформація, яка необхідна зовнішнім клієнтам - зовнішньому сервері, про шляхи доставки пошти і т. д., а у файлах внутрішніх зон відображається вся мережева топологія. Крім того, якщо супроводжується зворотна зона, необхідно точно так само розділити по файлах інформацію про адреси зворотного перетворення.

Отже, повернемось до нашого прикладу.

Файлова структура буде такою. У нас є пряма зона krokodil.ru та зворотна зона 5.20.212.in-addr.arpa. Крім того, обов'язково повинна бути зворотна зона зона 0.0.127.in-addr.arpa для забезпечення коректного зворотного перетворення localhost 127.0.0.1. Зона ця потрібна для того, щоб BIND не намагався запитувати кореневі сервери про себе, що відбувається, коли 127.0.0.1 вказує на «localhost.» Запис прямого перетворення 127.0.0.1 localhost.krokodil.ru буде занесено до файлу прямого перетворення внутрішньої зони. Для того щоб не завантажувати мережу передачею непотрібних даних, для зовнішніх і внутрішніх зон використовуються різні записи SOA - записи в зовнішніх зонах змінюються дуже рідко, а у внутрішніх досить часто. Отже, ми маємо такі файли:

• localhost.rev- Файл зони зворотного перетворення 0.0.127.in-addr.arpa. Цей файл існує лише для внутрішнього уявлення.
• zone212.rev- файл зони зворотного перетворення 5.20.212.in-addr.arpa.
• zone10.rev- Файл внутрішньої зони зворотного перетворення 1.87.10.in-addr.arpa.
• direct-krokodil-ru.int- Файл внутрішньої зони прямого перетворення krokodil.ru.
• direct-krokodil-ru.ext- Файл зовнішньої зони прямого перетворення krokodil.ru.
• krokodil-ru-int.soa– файл із записами SOA та NS для внутрішніх зон.
• krokodil-ru-ext.soa– файл із записами SOA та NS для зовнішніх зон.

Незважаючи на великий список, файли досить короткі, тому наводяться тут повністю, крім коментарів.

Зробимо одне зауваження щодо імені localhost. RFC 1912 спеціально згадує налаштування файлів з роздільною здатністю імені 127.0.0.1 та localhost. У прикладі зона localhost відповідає RFC 1912, хоча у житті цілком можна зустріти дозвіл імені 127.0.0.1 localhost.domain.tld і відповідне йому зворотне дозвіл.

Файл localhost.rev. Використовує один запис SOA разом із внутрішньою зоною зворотного перетворення:

$INCLUDE /etc/namedb/krokodil-ru-int.soa

1 IN PTR localhost.

Файл zone212.rev:

1 IN PTR gate.krokodil.ru.

2 IN PTR krokodil.ru.

Файл zone10.rev:

$INCLUDE /etc/namedb/krokodil-ru-int.soa

1 IN PTR tooth1.krokodil.ru.

2 IN PTR tooth2.krokodil.ru.

3 IN PTR tooth3.krokodil.ru.

4 IN PTR tooth4.krokodil.ru.

5 IN PTR tooth5.krokodil.ru.

6 IN PTR tooth6.krokodil.ru.

Файл direct-krokodil-ru.int:

$INCLUDE /etc/namedb/krokodil-ru-int.soa

krokodil.ru. IN A 10.87.1.254

IN MX 10 krokodil.ru

www IN CNAME krokodil.ru.

mail IN CNAME krokodil.ru.

proxy IN CNAME krokodil.ru

ftp IN CNAME krokodil.ru.

ns IN CNAME krokodil.ru.

localhost. IN A 127.0.0.1

tooth1 IN A 10.87.1.1

tooth2 IN A 10.87.1.2

tooth3 IN A 10.87.1.3

tooth4 IN A 10.87.1.4

tooth5 IN A 10.87.1.5

tooth6 IN A 10.87.1.6

Файл direct-krokodil-ru.ext:

$INCLUDE /etc/namedb/krokodil-ru-ext.soa

krokodil.ru. IN A 212.20.5.2

IN MX 10 krokodil.ru

IN MX 50 behemot.ru

www IN CNAME krokodil.ru.

mail IN CNAME krokodil.ru.

ftp IN CNAME krokodil.ru.

gate IN A 212.20.5.1

Файл krokodil-ru-int.soa:

@ IN SOA krokodil.ru. hostmaster.krokodil.ru. (

2006051202; Serial number

10800; Refresh every 3 hours

3600; Retry every hour

1728000; Expire every 20 days

172800); Minimum 2 дні

IN NS krokodil.ru

Файл krokodil-ru-ext.soa:

$TTL 172800

@ IN SOA korkodil.ru. hostmaster.krokodil.ru. (

2005122001; Serial number

10800; Refresh every 3 hours

3600; Retry every hour

1728000; Expire every 20 days

172800); Minimum 2 дні

IN NS krokodil.ru

IN NS ns4.nic.ru

Висновок

Як створити, налаштувати та запустити DNS-сервер для невеликого підприємства? Насправді не так складно, як здається спочатку, - достатньо пройти цей шлях один раз, подальші діїйдуть «на автоматі».

додаток

Домени верхнього рівня

Спочатку, згідно з RFC 920, у списку функціональних TLD були присутні тільки .com, .gov, .mil, .edu, .org , які представляли відповідно комерційні, урядові, військові організації, освітні установи та некомерційні організації. Згодом цей список дещо розширився – у 1985 р. додався TLD .net, який представляє організації-постачальники мережевих послуг, а 1988 – TLD .int, що представляє міжнародні організації. У 2001-2002 до цього списку додалися практичні невідомі російському користувачу TLD .aero, .biz, .cat, .coop, .jobs, .mobi, .museum, .name, .pro і. Більше Детальна інформаціянаведено у . Географічні домени розподілені раз і назавжди. Хоча це не означає, що ви не можете зареєструвати свій домен. Багато географічних доменів, які випадково збіглися з «добре відомими» скороченнями, є надзвичайно привабливими. Наприклад, .md (Молдавія) дуже приваблива для медичних установта мешканців штату Меріленд, США; .tv (Тувалу) – для сайтів, пов'язаних із телебаченням; .tm (Туркменістан) збігається із написанням скорочення «Trade Mark», а.nu (Ніуе – є такий острів-колонія) – для сайтів у стилі «ню».

http://www.ripe.net.

http://www.ripe.net/rs/reverse/rdns-project/index.html .

Немет Е., Снайдер Р., Сібас С., Хейн Т.Р. UNIX: керівництво системного адміністратора. Для професіоналів/Пер. з англ. - Спб.: Пітер; К.: Видавнича група BHV, 2002 р. - 928 с.: Іл.

Cricket Liu, Paul Albitz, DNS і BIND, Third Edition, 1998 (вид-во O'Reilly, ISBN 1-56592-512-2).

Історична довідка: Систему доменних імен розробив у 1983 році Пол Мокапетріс. Тоді ж було проведено перше успішне тестування DNS, що стало згодом одним із базових компонентів. мережі Internet. З допомогою DNSстало можливим реалізувати масштабований розподілений механізм, що встановлює відповідність між ієрархічними іменами сайтів та числовими IP-адресами.

У 1983 році Пол Мокапетріс працював науковим співробітником інституту інформатики (Information Sciences Institute, ISI), що входить до складу інженерної школи університету Південної Каліфорнії ( USC). Його керівник, Джон Постел, запропонував Полу придумати новий механізм, що встановлює зв'язки між іменами комп'ютерів і адресами Internet, - замість централізованого каталогу імен і адрес хостів, що використовувався тоді, який підтримувала каліфорнійська компанія SRI International.

"Всі розуміли, що стара схема не зможе працювати вічно, - згадує Мокапетріс. - Зростання Internet ставало лавиноподібним. До мережі, що виникла на основі проекту ARPANET, ініційованого Пентагоном, приєднувалися все нові й нові компанії та дослідницькі інститути".

Запропоноване Мокапетрисом рішення - DNS - являло собою розподілену базу даних, яка дозволяла організаціям, що приєдналися до Internet, отримати свій домен.

"Щойно організація підключалася до мережі, вона могла використовувати скільки завгодно багато комп'ютерів і сама призначати їм імена", - підкреслив Мокапетріс. Назви доменів компаній отримали суфікс.com, університетів – .edu і так далі.

Спочатку DNS була розрахована на підтримку 50 млн записів і допускала безпечне розширення до декількох сотень мільйонів записів. За оцінками Мокапетріса, наразі налічується близько 1 млрд. імен DNS, у тому числі майже 20 млн. загальнодоступних імен. Інші належать системам, розташованим за міжмережевими екранами. Їхні імена невідомі звичайним Internet-користувачам.

Нова система впроваджувалась поступово, протягом кількох років. У цей час ряд дослідників експериментували з її можливостями, а Мокапетріс займався в ISIобслуговуванням та підтриманням стабільної роботи " кореневого сервераКопії таблиць хостів зберігалися на кожному комп'ютері, підключеному до Internet, ще приблизно до 1986 року. Потім почався масовий перехід на використання DNS.

Необхідність відображення імен мережевих вузлів в IP-адресах

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

Існують два таких механізми - локальний для кожного комп'ютера файл hosts і централізована ієрархічна служба імен DNS.

Використання локального файлу host s та системи доменних імен DNS для дозволу імен мережевих вузлів

На початковому етапі розвитку мереж, коли кількість вузлів у кожній мережі була невелика, достатньо було на кожному комп'ютері зберігати та підтримувати актуальний стан простого текстового файлу, в якому містився список мережних вузлів цієї мережі. Список влаштований дуже просто - у кожному рядку текстового файлу міститься пара "IP-адреса - ім'я мережного вузла". У системах сімейства Windows цей файл розташований у папці %system root%\system32\drivers\etc (де %system root% позначає папку, в якій встановлена ​​операційна система). Відразу після інсталяції Windows створюється файл hosts з одним записом 127.0.0.1 localhost.

Зі зростанням мереж підтримувати актуальність та точність інформації в файлі hostsстає дедалі важче. Для цього потрібно постійно оновлювати вміст файлу на всіх вузлах мережі. Крім того, така проста технологіяне дозволяє організувати простір імен до будь-якої структури. Тому виникла потреба у централізованій базі даних імен, що дозволяє здійснювати перетворення імен в IP-адреси без зберіганнясписку відповідності кожного комп'ютера. Такою базою стала DNS (Domain Name System) – система іменування доменів, яка розпочала масову роботу у 1987 році.

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

Служба DNS: простір імен, домени

DNS – це ієрархічна база даних, зіставляє імена мережних вузлів та їх мережевих служб IP-адрес вузлів. Вміст цієї бази, з одного боку, розподілено за великою кількістю серверів служби DNS, а з іншого боку є централізовано керованим. В основі ієрархічної структури бази даних DNS лежить доменний простір імен (domain namespace), основною структурною одиницею якого є домен, що поєднує вузли (хости), а також піддомени. Процес пошуку в БД служби DNS імені певного мережного вузла і зіставлення цього імені IP-адреси називається "дозвіл імені вузла в просторі імен DNS".

Служба DNS складається з трьох основних компонентів:

Простір імен DNS та відповідні ресурсні записи (RR, resource record)- Це сама розподілена база даних DNS;

Сервери імен DNS- комп'ютери, що зберігають базу даних DNS та відповідають на запити DNS-клієнтів;

DNS-клієнти (DNS-clients, DNS-resolvers)-комп'ютери, що надсилають запити серверам DNS для отримання ресурсних записів

Простір імен.

Простір імен DNS - ієрархічна деревоподібна структура, що починається з кореня, що не має імені та позначається точкою ".". Схему побудови простору імен DNS найкраще проілюструвати з прикладу мережі Інтернет ( Мал. 4.8).

Мал. 4.8.

Для доменів 1-го рівня розрізняють 3 категорії імен:

ARPA- спеціальне ім'я, яке використовується для зворотного дозволу DNS (з IP-адреси в повне ім'явузла);

Загальні (generic) імена 1-го рівня- 16 (на даний момент) імен, призначення яких наведено у табл. 4.4;

Дволітерні імена для країн- імена для доменів, зареєстрованих у відповідних країнах (наприклад, ru – для Росії, ua – для України, uk – для Великобританії тощо).

Таблиця 4.4.
Ім'я домену	Призначення
	Співтовариства авіаторів
	Компанії (без прив'язки до країни)
	Комерційні організації, переважно США (наприклад, домен microsoft.com для корпорації Microsoft)
	Кооперативи
	Освітні установи у США
	Урядові установи США
	Домен для організацій, які надають будь-яку інформацію для споживачів
	міжнародні організації (наприклад, домен nato.int для НАТО)
	Військові відомства США
	Глобальний домен для приватних осіб
	Домен для Інтернет-провайдерів та інших організацій, які управляють структурою мережі Інтернет
	Некомерційні та неурядові організації, переважно в США
	Домен для професійних об'єднань (лікарів, юристів, бухгалтерів та ін.)
	Кадрові агенції
	Туроператори

Для безпосереднього відображення простору імен у простір IP-адрес служать т.зв. ресурсні записи (RR, resource record). Кожен сервер DNS містить ресурсні записи для частини простору імен, за яку він несе відповідальність ( authoritative). табл. 4.5містить опис найчастіше використовуваних типів ресурсних записів.

Таблиця 4.5.
Тип ресурсного запису	Функція запису	Опис використання
	Host AddressАдреса хоста, або вузла	Відображає ім'я вузла на IP-адресу (наприклад, для домену microsoft.com вузлу з ім'ям) www.microsoft.comзіставляється IP-адреса за допомогою такого запису: www A 207.46.199.60)
	Canonical Name (alias) Канонічне ім'я (псевдонім)	Відображає одне ім'я на інше
	Mail Exchanger Обмін поштою	Керує маршрутизацією поштових повідомлень для протоколу SMTP
	Name Server Серверімен	Вказує на сервери DNS, відповідальні за конкретний домен та його піддомени
	Pointer Вказівник	Використовується для зворотного дозволу IP-адрес в імена вузлів у домені in-addr.arpa
	Start of Authority Початковий запис зони	Використовується для вказівки основного сервера для даної зони та опису властивостей зони
	Service Locator Вказівник на службу	Використовується для пошуку серверів, на яких функціонують певні служби (наприклад, контролери доменів Active Directory або сервери глобального каталогу)

Повне ім'я вузла (FQDN, fully qualified domain name) складається з кількох імен, званих мітками (label) і розділених точкою. Найлівіша мітка відноситься безпосередньо до вузла, решта міток - список доменів від домену першого рівня до того домену, в якому знаходиться вузол (даний список проглядається праворуч наліво).

Сервери імен DNS.

Сервери імен DNS (або DNS-сервери) - це комп'ютери, на яких зберігаються частини БД простору імен DNS, за які дані сервери відповідають, і функціонує програмне забезпечення, яке обробляє запити DNS-клієнтів на дозвіл імен і видає відповіді на отримані запити.

DNS-клієнти.

DNS-клієнт - це будь-який мережевий вузол, який звернувся до DNS-сервера для дозволу імені вузла в IP-адресу або, назад, IP-адреси в ім'я вузла.

Служба DNS: домени та зони

Як говорилося вище, кожен DNS-сервер відповідає за обслуговування певної частини простору імен DNS. Інформація про домени, що зберігається в БД сервера DNS, організується в спеціальні одиниці, які називаються зонами (zones). Зона – основна одиниця реплікації даних між серверами DNS. Кожна зона містить певну кількість ресурсних записів для відповідного домену і, можливо, його піддоменів.

Системи сімейства Windows Server підтримують такі типи зон:

Стандартна основна (standard primary)- основна копія стандартної зони; тільки в даному екземплярізони допускається проводити будь-які зміни, які потім реплікуються на сервери, що зберігають додаткові зони;

Стандартна додаткова (standard secondary)- копія основної зони, доступна в режимі "тільки-читання", призначена для підвищення стійкості до відмов і розподілу навантаження між серверами, що відповідають за певну зону; процес реплікації змін у записах зон називається "передачею зони" ( zone transfer) (інформація в стандартних зонах зберігається в текстових файлах, файли створюються в папці "%system root%\system32\dns", ім'я файлу, як правило, утворюється з імені зони з додаванням розширення файлу ".dns"; термін "стандартна" використовується лише у системах сімейства Windows);

Інтегрована в Active Directory(Active Directory-integrated)- вся інформація про зону зберігається у вигляді одного запису в базі даних Active Directory (такі типи зон можуть існувати тільки на серверах Windows, які є контролерами доменів Active Directory; в інтегрованих зонах можна жорсткіше управляти правами доступу до записів зони; зміни в записах зони між різними екземплярами інтегрованої зони виробляються не по технологіїпередачі зони службою DNS, а механізмами реплікації служби Active Directory);

Зона-заглушка (stub; тільки в Windows 2003) - особливий тип зони, яка для даної частини простору імен DNS містить найменший набір ресурсних записів (початковий запис зони SOA, список серверів імен, що відповідають за дану зону, та кілька записів типу A для посилань на сервери імен для даної зони).

Розглянемо з прикладу співвідношення між поняттями домену і зони. Проаналізуємо інформацію, подану на Мал. 4.9.

Мал. 4.9.

У цьому прикладі простір імен DNS починається з домену microsoft.com, який містить 3 піддомени: sales.microsoft.com, it.microsoft.comі edu.microsoft.com(Домени на малюнку позначені маленькими горизонтальними овалами). Домен - поняття суто логічне, що стосується лише розподілу імен. Поняття домену ніяк не пов'язане з технологією зберіганняінформації про домену. Зона- це спосіб представлення інформації про домен та його піддомени у сховищі тих серверів DNS, які відповідають за даний домен та піддомени. У цій ситуації, якщо для зберігання вибрано технологію стандартних зон, то розміщення інформації про домени може бути реалізовано таким чином:

записи, які стосуються доменів microsoft.comі edu.microsoft.com, Зберігаються в одній зоні у файлі "microsoft.com.dns" (на малюнку зона позначена великим похилим овалом);

управління доменами sales.microsoft.comі it.microsoft.comделеговано іншим серверам DNS, для цих доменів на інших серверах створено відповідні файли "sales.microsoft.com.dns" та "it.microsoft.com.dns" (дані зони позначені великими вертикальними овалами).

Делегування управління – передача відповідальності за частину простору імен іншим серверам DNS.

Зони прямого та зворотного перегляду

Зони, розглянуті в попередньому прикладі, є зон прямого перегляду (forward lookup zones). Дані зони служать для дозволу імен вузлів IP-адреси. Типи записів, що найчастіше використовуються для цього: A, CNAME, SRV.

Для визначення імені вузла за його IP-адресою є зони зворотного перегляду ( reverse lookup zones), основний тип запису у "зворотних" зонах - PTR. Для вирішення цього завдання створено спеціальний домен з ім'ям in-addr.arpa. Для кожної IP-мережі у такому домені створюються відповідні піддомени, утворені з ідентифікатора мережі, записаного у зворотному порядку. Записи в такій зоні зіставлятимуть ідентифікатору вузла повне ім'я FQDN даного вузла. Наприклад, для IP-мережі 192.168.0.0/24 необхідно створити зону з ім'ям "0.168.192.in-addr.arpa". Для вузла з IP-адресою 192.168.0.10 та ім'ям host.company.ru в даній зоні має бути створений запис "10 PTR host.company.ru".

Алгоритми роботи ітеративних та рекурсивних запитів DNS

Усе запити, що надсилаються DNS-клієнтом DNS-серверу для дозволу імен, поділяються на два типи:

ітеративні запити (клієнт надсилає серверу DNS запит, В якому вимагає дати найкращу відповідь без звернень до інших DNS-серверів);

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

Звичайні DNS-клієнти (наприклад, робочі станції користувачів) зазвичай посилають рекурсивні запити.

Розглянемо на прикладах, як відбувається взаємодія DNS-клієнта та DNS-сервера при обробці ітеративних та рекурсивних запитів.

Припустимо, що користувач запустив програму Оглядач Інтернету та ввів в адресному рядку адресу http://www.microsoft.com. Перш ніж браузер встановить сеанс зв'язку з веб-сайтом за протоколом HTTP, клієнтський комп'ютер повинен визначити IP-адресу веб-сервера. Для цього клієнтська частина протоколу TCP/IP робочої станції користувача (так званий resolver) спочатку переглядає свій локальний кеш дозволених раніше імен у спробі знайти там ім'я www.microsoft.com. Якщо ім'я не знайдено, клієнт надсилає запит DNS-серверу, вказаному в конфігурації TCP/IP даного комп'ютера (назвемо даний DNS-сервер "локальним DNS-сервером"), на дозвіл імені www.microsoft.comв IP-адресу цього вузла. Далі сервер DNS обробляє запит залежно від типу запиту.

Варіант 1 (ітеративний запит).

Якщо клієнт відправив серверу ітеративний запит (нагадаємо, що зазвичай клієнти надсилають рекурсивні запити), обробка запиту відбувається за такою схемою:

microsoft.com;

якщо така зона знайдена, то у ній шукається запис для вузла www; якщо запис знайдено, результат пошуку відразу ж повертається клієнту;

www.microsoft.comу своєму кеші дозволених раніше DNS-запитів;

якщо шукане ім'я є в кеші, результат пошуку повертається клієнту; якщо локальний DNS-сервер не знайшов у своїй базі даних шуканий запис, то клієнту надсилається IP-адреса одного з кореневих серверів DNS;

клієнт отримує IP-адресу кореневого сервера та повторює йому запит на дозвіл імені www.microsoft.com;

кореневий сервер не містить у своїй БД зони "microsoft.com", але йому відомі DNS-сервери, що відповідають за зону "com", і кореневий сервер надсилає клієнту IP-адресу одного із серверів, що відповідають за цю зону;

клієнт отримує IP-адресу сервера, що відповідає за зону "com", і надсилає йому запит на дозвіл імені www.microsoft.com;

сервер, який відповідає за зону com, не містить у своїй БД зони microsoft.com, але йому відомі DNS-сервери, які відповідають за зону microsoft.com, і даний DNS-сервер посилає клієнту IP-адресу одного з серверів, які вже відповідають за зону microsoft.com;

клієнт отримує IP-адресу сервера, що відповідає за зону microsoft.com, і надсилає йому запит на дозвіл імені www.microsoft.com;

сервер, який відповідає за зону microsoft.com, отримує даний запит, знаходить у своїй базі даних IP-адресу вузла www, розташованого в зоні microsoft.com, І посилає результат клієнту;

клієнт отримує шукану IP-адресу, зберігає дозволений запит у своєму локальному кеші і передає IP-адресу веб-сайту програмі Оглядач Інтернету (після чого Оглядач встановлює зв'язок із веб-сайтом за протоколом HTTP).

Варіант 2 ( рекурсивний запит).

Якщо клієнт надіслав серверу рекурсивний запит, То обробка запиту відбувається за такою схемою:

спочатку локальний DNS-сервер шукає серед зон, за які він відповідає, зону microsoft.com; якщо така зона знайдена, то у ній шукається запис для вузла www; якщо запис знайдено, результат пошуку відразу ж повертається клієнту;

інакше локальний DNS-сервер шукає запитане ім'я www.microsoft.comу своєму кеші дозволених раніше DNS-запитів; якщо шукане ім'я є в кеші, результат пошуку повертається клієнту;

якщо локальний DNS-сервер не знайшов у своїй базі даних шуканий запис, то сам локальний DNS-сервер виконує серію ітеративних запитів на дозвіл імені www.microsoft.com, і клієнту надсилається або знайдена IP-адреса, або повідомлення про помилку.

Реалізація служби DNS у системах сімейства Windows Server

Головна особливість служби DNS у системах сімейства Windows Server полягає в тому, що DNS розроблялася для підтримки служби каталогів Active Directory. Для виконання цієї функції потрібні забезпечення двох умов:

підтримка службою DNS динамічноїреєстрації (dynamic updates);

підтримка службою DNS записів типу SRV.

Служба DNS систем Windows Server задовольняє обидві умови, і реалізація служб каталогів Active Directory може бути забезпечена тільки серверами на базі систем Windows Server.

Розглянемо кілька простих прикладів керування службою DNS:

встановлення служби DNS;

створення основної та додаткової зони прямого перегляду;

створення зони зворотного перегляду;

виконання динамічної реєстрації вузлів у зоні.

мережа складається із двох серверів Windows 2003 Server;

операційна система - обмежена за часом 120-денна російська версія Windows 2003 Server Enterprise Edition;

перший сервер встановлений на ПК з процесором Intel Pentium-4 3Ггц та оперативною пам'яттю 512 МБ, ім'я сервера - DC1, IP-адреса - 192.168.0.1/24;

другий сервер працює як віртуальна система за допомогою Microsoft VirtualPC 2004, ім'я сервера -DC2, IP-адреса - 192.168.0.2/24 ;

ім'я домену у просторі DNS та відповідне ім'я в службі каталогів Active Directory - world.ru (мережа повністю ізольована від інших мереж, тому в даному прикладі автори були вільні у виборі імені домену; у реальній обстановці конкретного навчального закладу викладачеві потрібно скоригувати цю інформацію).

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

Встановлення служби DNS

Встановлення служби DNS (як і інших компонентів системи) здійснюється досить просто за допомогою майстра установки компонентів Windows:

Відкрийте Панель управління.

Виберіть пункт "Встановлення та видалення програм".

Натисніть кнопку "Встановлення компонентів Windows".

Виберіть "Мережеві служби"- кнопка "Додатково"(у жодному разі не знімайте галочку у назви "Мережеві служби").

Позначте службу DNS.

Мал. 4.10.

Якщо система попросить вказати шлях до дистрибутиву системи, введіть шлях до папки з дистрибутивом.

Виконаємо цю дію на обох серверах.

Створення основної зони прямого перегляду.

На сервері DC1 створимо стандартну зону з ім'ям world.ru.

Відкриємо консоль DNS.

Виберемо розділ "Зони прямого перегляду".

Запустимо майстер створення зони (тип зони - "Основна", динамічні оновлення - дозволити, інші параметри - за промовчанням).

Введемо ім'я зони – world.ru.

Дозволимо передачу цієї зони на будь-який сервер DNS (Консоль DNS - зона world.ru - Властивості- Закладка "Передачі зон"- Позначте "Дозволити передачі"і "На будь-який сервер").

Створення додаткової зони прямого перегляду.

На сервері DC2 створимо додаткову стандартну зону з ім'ям world.ru.

Відкриємо консоль DNS.

Виберемо розділ "Зони прямого перегляду"

"Додаткова", IP-адреса master-сервера (з якого копіюватиметься зона) - адреса сервера DC1, інші параметри - за замовчуванням)

Введемо ім'я зони – world.ru.

Перевіримо у консолі DNS появу зони.

Налаштування вузлів для динамічної реєстрації на сервері DNS.

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

Сервер DNS

Створити відповідну зону.

Дозволити динамічні оновлення.

Це вже нами виконано.

Клієнт DNS.

Вказати в налаштуваннях протоколу TCP/IP адресу відданого DNS-сервера - той сервер, на якому дозволені динамічні оновлення (у нашому прикладі - сервер DC1).

У повному імені комп'ютера вказати відповідний DNS-суфікс (у нашому прикладі – world.ru). Для цього - "Мій комп'ютер" - "Властивості"- Закладка "Ім'я комп'ютера"- Кнопка "Змінити"- Кнопка "Додатково"- у порожньому текстовому полі впишемо назву домену world.ru - кнопка "ОК"(3 рази)).

Мал. 4.11.

Після цього система запропонує перезавантажити комп'ютер. Після перезавантаження на сервер DNS в зоні world.ru автоматично створяться записи типу A для наших серверів ( Мал. 4.12).

Мал. 4.12.

Створення зони зворотного перегляду.

Відкриємо консоль DNS.

Виберемо розділ "Зони зворотного перегляду".

Запустимо майстер створення зони (вибрати: тип зони - "Основна", динамічні оновлення - дозволити, інші параметри - за замовчуванням)

В полі "Код мережі (ID)"введемо параметри ідентифікатора мережі – 192.168.0.

Виконаємо команду примусової реєстрації клієнта на сервері DNS – ipconfig /registerdns.

Наші сервери зареєструються в зворотній зоні DNS ( Мал. 4.13):

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

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

Створення зон

Зона DNS є базою даних, що містить записи, якіпов'язують імена з адресами в області простору імен DNS , що описується . Хочадля відповідей на запити імен DNS-сервер може використовувати кешовануінформацію з інших серверів, він уповноважений відповідати на запити лише улокально керованої зони. Для будь-якої області простору імен DNSпредставленого ім'ям домену (наприклад, google .ru ), існує лише одинповноваження джерела даних зони.
При необхідності створити на DNS-сервері нову зону можна скористатися майстром створення нової зони (New Zone Wizard) в диспетчері DNS (DNS Manager). Для запуску майстра клацніть правою кнопкоюмиші значок сервера в дереві консолі диспетчера DNS і застосуйте команду Створити нову зону (New Zone).

Майстер створення нової зони містить наступні сторінкиконфігурації:

■ Тип зони (Zone Type);

■ Область реплікації зони інтегрованоюв Active Directory (Active Directory Zone Replication Scope);

■ Зона прямого або зворотного перегляду (Forward or Reverse Lookup Zone);

■ Ім'я зони (Zone Name);

■ Динамічне оновлення (Dynamic Update).

У наступних розділах описано концепції конфігурації, пов'язані з цими п'ятьма сторінками майстра.

Вибір типу зони

На сторінці Тип зони (Zone Type) майстра створення нової зони (New Zone Wizard) можна вибрати створення основної зони, додаткової або зони заглушки. Створивши основну зону або зону-заглушку на контролері домену, ви зможете зберігати дані зони в Active Directory.

* Основні зони

Найпоширенішим типом зон DNS є основна зона (Primary zone). Вона забезпечує вихідні дані читання/запису джерела, що надають локальному DNS-серверуповноваження відповідати на запити DNS області простору імен DNS.

Локальний DNS-сервер, що керує основною зоною, є первинним джерелом даних про цю зону. Сервер зберігає головну копію даних зони в локальному файлі або доменних службах Active Directory (Active Directory Domain Services, AD DS). Якщо зона зберігається у файлі, а не в Active Directory, цей файл за замовчуванням отримує ім'я ім'я_зони.dnsі зберігається в папці %systemroot %System 32Dns на сервері.

* Додаткові зони

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

Додаткові зони (Secondary zones) надають можливість знизити обсяг трафіку запитів DNS в областях мережі, де відбувається інтенсивне запитування та використання даних зони. Крім того, у разі недоступності сервера, який керує основною зоною, додаткова зона може забезпечувати дозвіл імен доти, доки основний сервер знову не стане доступним.

Вихідні зони, у тому числі додаткові зони отримують інформацію, називаються мастер-зонами, а процедури копіювання даних, які забезпечують регулярне оновлення інформації зони, називаються передачами зон. Майстер-зоною може бути основна зона чи інша додаткова зона. Майстер-зону можна призначити для створюваної додаткової зони у майстрі створення нової зони (New Zone Wizard). Оскільки додаткова зона — це копія основної зони, яку керує ще один сервер, її не можна зберігати в Active Directory .

* Зони-заглушки

Аналогічні додатковій зоні, проте містять записи ресурсів, необхідні для ідентифікації повноважних DNS-серверів головної зони. Зони-заглушки (Stub zone) часто застосовуються для того, щоб батьківська зона (наприклад, google. ru) могла використовувати оновлюваний список серверів імен, доступних у делегованій дочірній зоні (наприклад: translate. Вони також служать для покращення дозволу імен та спрощення адміністрування DNS.

* Зберігання зон вActiveDirectory

При створенні основної зони або заглушки на контролері домену, на сторінці Тип зони (Zone Type) майстра можна вибрати опцію збереження зони в Active Directory. Дані зон, інтегрованих в Active Directory, автоматично реплікуються в Active Directory відповідно до параметрів, вибраних на сторінці Область реплікації зони, інтегрованої в Active Directory (Active Directory Zone Replication Scope). Завдяки цій опції немає потреби налаштовувати передачу зон на додаткові сервери.

Інтеграція зони DNS у Active Directory дає кілька переваг. По-перше, оскільки служби Active Directory виконують реплікацію зон, немає потреби в налаштуванні окремого механізму передачі зон DNS між основним та додатковими серверами. Множинна реплікація в мережі автоматично забезпечує стійкість до відмов і підвищену продуктивність завдяки доступності безлічі основних серверів з правом читання/запису. По-друге, служби Active Directory дозволяють виконувати оновлення та реплікацію окремих властивостей записів ресурсів на DNS-серверах. Оскільки не передається безліч повних записів ресурсів, знижується навантаження на мережні ресурси під час передачі зон. Нарешті, зони, інтегровані в Active Directory, забезпечують також опціональні можливості впровадження вимог безпеки динамічних оновлень, налаштування яких здійснюється на сторінці динамічного оновлення (Dynamic Update) майстра створення зони.

ПРИМІТКА: Контролери домену з правом читання та зони, інтегровані в Active Directory

На традиційних контролерах доменів копії зони надається право читання/запису. На контролерах доменів з доступом лише для читання (Read-Only Domain Controller, RODC) копії зони призначається лише право читання.

* Стандартні зони

При створенні зони на контролері домену опція збереження зони в Active Directory на сторінці Тип зони (Zone Type) вибирається за замовчуванням. Однак цей прапорець можна зняти та створити так звану стандартну зону. На сервері, що не є контролером домену, можна створювати лише стандартні зони, а прапорець на цій сторінці неактивний.

На відміну від зони, інтегрованої в Active Directory, стандартна зона зберігає свої дані в текстовому файлі на локальному сервері DNS. Крім того, у разі використання стандартних зон можна конфігурувати лише основну копію з правом читання та запису даних зони. Всім іншим копіям зони (додаткові зони) призначено право лише для читання.

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

Вибір області реплікації зони, інтегрованої вActiveDirectory

На сторінці Область реплікації зони, інтегрованої в Active Directory (Active Directory Zone Replication Scope) майстра створення нової зони (New Zone Wizard) можна вибрати контролери домену в мережі для збереження даних зони. Ця сторінка з'являється лише при виборі опції збереження зони та Active Directory . Опції вибору області реплікації зон визначають контролери домену, серед яких буде реплікація даних зон.

На цій сторінці представлені такі опції:

■ Збереження зони на всіх контролерах домену, які також є DNS-серверами у всьому лісі Active Directory;

■ Збереження зони на всіх контролерах домену , які також є DNS-серверами і локальному домені Active Directory;

■ Збереження зони на всіх контролерах домену та локальному домені Active Directory (використовується для сумісності з Windows 2000);

■ Збереження зони на всіх контролерах домену , зазначених та області налаштованого розділу каталогу Active Directory.

Докладніше ці опції описані у другій темі.

Створення зон прямого та зворотного перегляду

На сторінці Зона прямого або зворотного перегляду (Forward or Reverse Lookup Zone) майстра створення попів зони (New Zone Wizard) необхідно вибрати тип створюваної зони; зона прямого перегляду (Forward Lookup Zone) чи зона зворотного перегляду (Reverse Lookup Zone).

У зонах прямого перегляду DNS-сервери порівнюють повні доменні імена FQDN з IP-адресами. У зонах зворотного перегляду DNS-сервери зіставляють I-адреси імен FQDN. Таким чином, зони прямого перегляду відповідають на запити дозволу імен FQDN в IP-адреси, а зони зворотного перегляду відповідають на запити дозволу IP-адрес в імена FQDN. дозволяється дозвіл, наприклад google .com. Зони зворотного перегляду іменуються і в зворотному порядку перших трьох октетів адресного простору, для якого забезпечується роздільна здатність імен плюс додатковий тег in-addr.arpa. Наприклад, при роздільній здатності імен для підмережі 192.168.1.0/24 зона зворотного перегляду отримає ім'я 1.168.192.in-addr.arpa. У зоні прямого перегляду окремий записбази даних, що зіставляє ім'я вузла з адресою, називається записом вузол(А). У зоні зворотного перегляду окремий запис бази даних, що зіставляє IP-адресу, з ім'ям вузла, називається вказівникомабо PTR-записом.

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

Зона прямого перегляду

Зона зворотного перегляду

ПРИМІТКА: Майстер налаштування DNS-сервера

Для одночасного створення зон прямого та зворотного перегляду можна використовувати майстер налаштування DNS-сервера (Configure A DNS Server Wizard). Щоб запустити майстер, у дереві консолі диспетчера DNS клацніть правою кнопкою миші піктограму сервера та застосуйте команду Налаштувати DNS-сервер (Configure A DNS Server).

Вибір імені зони

На сторінці Ім'я зони (Zone Name) майстра створення нової зони (New Zone Wizard) можна вибрати ім'я зони прямого перегляду, що створюється, Зони зворотного перегляду отримують особливі імена відповідно до діапазону IP-адрес, для яких є повноважними.

Якщо зона створюється для дозволу імен у домені Active Directory, найкраще вказати ім'я зони, яке відповідає імені домену Active Directory. Наприклад, якщо організація містить два домени Active Directory, з іменами google.

У разі створення зони для простору імен DNS не в середовищі ActiveDirectory потрібно вказати ім'я Інтернет-домену організації, наприклад wikipedia .org .

ПРИМІТКА: ДодаванняDNS-сервера на контролер домену

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

Налаштування параметрів динамічного оновлення

Клієнтські комп'ютери DNSможуть реєструвати та динамічно оновлювати свої записи ресурсів за допомогою DNS-сервера. За замовчуванням DNS-клієнти зі статичними IP-адресами оновлюють записи вузлів (А або АААА) і вказівників (PTR), а DNS-клієнти, що є DHCP-клієнтами, лише записи вузлів. У середовищі робочої групи DHCP-сервер оновлює записи вказівника від імені DHCP-клієнта під час кожного оновлення конфігурації IP.

Для успішного динамічного оновлення DNS зона, в якій клієнти реєструють або оновлюють записи, має бути налаштована для прийому динамічних оновлень. Існує два типи такого оновлення:

■ Безпечнеоновлення (Secureupdates )

Дозволяє виконувати реєстрацію лише з комп'ютерів домену Active Directory та оновлення лише з комп'ютера, який спочатку виконував реєстрацію.

■ Небезпечніоновлення (Nonsecureupdates )

Дозволяє виконувати оновлення з будь-якого комп'ютера.

На сторінці Динамічне оновлення (Dynamic Update) майстра створення нової зони (New Zone Wizard) для створюваної зони можна дозволити безпечні, небезпечні динамічні оновлення або взагалі заборонити оновлення.

Аналіз вбудованих записів ресурсів

Під час створення нової зони автоматично створюється два типи записів. По-перше, така зона завжди включає початковий запис зони SOA (Start Of Authority), що визначає основні властивості зони. Крім того, нові зони містять хоча б один запис сервера імен NS (Name Server), що вказує ім'я сервера (серверів) зони. Далі описано функції цих двох записів ресурсів.

Початкові записи зони

Під час завантаження зони DNS-сервер використовує початковий запис зони SOA (Start Of Authority) для визначення основних властивостей та повноважень зони. Ці параметри також характеризують частоту передачі зон між основним і додатковим сервером. Якщо двічі клацнути запис SOA, відкриється вкладка Початковий запис зони (SOA) діалогового вікна властивостей зони.

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

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

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

ПРИМІТКА: Передача зон на основному сервері

Клацніть кнопку Збільшити (Increment) ініціюється передача зони.

■ Основнийсервер (PrimaryServer )

■ Відповідальнеособа (Responsible Person)

У цьому полі вводиться ім'я відповідної особи (RP), що відповідає доменній поштовій скриньці адміністратора зони. Ім'я, введене в поле, завжди повинно завершуватися точкою. За промовчанням використовується ім'я hostmaster.

■ Інтервалоновлення (Refresh Interval)

Значення цього поля визначає час очікування додаткового DNS-сервера перед запитом оновлення зони на головному сервері. Після закінчення інтервалу оновленнядодатковий DNS-сервер запитує на головному сервері копію поточного запису SOA. Після отримання відповіді додатковим DNS-сервер порівнює серійний номер поточного запису SOA головного сервера (зазначеної у відповіді) із серійним номером свого локального запису SOA. Якщо ці значення відрізняються, додатковий DNS-сервер запитує передачу зони з головного сервера DNS. За промовчанням призначається інтервал оновлення 15 хвилин.

■ Інтервалповтору (Retry Interval)

■ Термінспливаєпісля (Expires After)

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

■ Мінімальнийтермінжиття TTL (Minimum (Default)T TL)

Значення TTL не стосуються записів ресурсів у повноважних зонах. І в цих зонах для значень TTL використовується час життя кешу запису ресурсів на неповноважних серверах. DNS-сервер, який вніс у кеш запис ресурсу з попереднього запиту, скидає цей запис, але після запису TTL.

■ Термін життя(TTL)записи(TTL For This Record)

Значення , вказане у цьому йолі, визначає термін життя поточного запису SOA . Це значення замінює стандартне значення, зазначене в попередньому полі.

Записи серверів імен

Запис сервера імен (NS) вказує повноважний сервер для зони. При створенні зони в Windows Server 2008 кожен сервер, що управляє основною копією зони, інтегрованої в Active Directory, отримає власний запис NS в новій зони за промовчанням. При створенні стандартної основної зони за промовчанням буде додано запис NS локального сервера.

Для серверів, які керують додатковими зонами, потрібно вручну додати записи NS до основної копії зони.

Записи NS створюються за допомогою іншої процедури, ніж у разі створення інших типів ресурсів. Щоб додати запис NS, двічі клацніть будь-який існуючий запис NS у диспетчері DNS. Відкриється вкладка Сервери імен (Name Servers) діалогового вікна властивостей зони. На вкладці Сервери імен натисніть кнопку Додати (Add), щоб додати ім'я FQDN та IP-адресу сервера, що управляє додатковою зоною локальної основної зони. Додавши новий сервер, клацніть ОК - у диспетчері DNS з'явиться новий запис NS, що вказує на цей сервер.

ПРИМІТКА: Включення передачі до додаткових зон

Додаткова зона не розпізнає цей запис як дійсний сервер імен, поки містить дійсну копію даних зони. Щоб додаткова зона отримала ці дані, потрібно увімкнути передачу зон для цього сервера на вкладці Передача зон (Zone Transfers) діалогового вікна властивості зони. Ця вкладка більш детально описана у наступній темі.

Нижче наведено приклад запису, створеного у файлі стандартної зони:

@ NS dns1.lucernepublishing.com.

Символ @ представляє зону, визначену записом SOA у файлі зони. Потім повний записзіставляє домен wikipedia .org із DNS-сервером dns1.wikipedia .org .

Створення записів ресурсів

Крім записів SOA і NS, автоматично створюються ще деякі записи ресурсів. Наприклад, під час встановлення нового сервера DNS, коли сервер призначається контролером домену, багато записів SRV доменних служб Active Directory (AD DS ) створюються автоматично в локально керованій зоні. Крім цього, за допомогою динамічного оновлення багато DNS-клієнтів за замовчуванням автоматично реєструють записи вузлів (А і АААА) і покажчиків (PTR) в зоні.

Незважаючи на те, що багато записів ресурсів створюються автоматично, в корпоративних середовищах зазвичай потрібно створити деякі записи ресурсів вручну, наприклад поштові обмінники MX (Mail Exchanger) для поштових серверів, псевдоніми (CNAME) для веб-серверів і серверів додатків, а також записи вузлів для серверів і клієнтів , які не можуть виконувати власні оновлення.

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

Після вибору запису в контекстному меню відкриється діалогове вікно, де можна вказати ім'я запису та пов'язаний з ним комп'ютер. Зазначимо, що ім'я комп'ютера з IP-адресою пов'язують лише записи вузла. Більшість типів записів пов'язують ім'я служби або псевдонім із вихідним записом вузла. Таким чином, запис MX покладається на присутність у зоні запису вузла SRV 12.nwtraders .msft.

Типи записів

Нижче наведено поширені записи ресурсів, що створюються вручну:

■ вузол (АабоАЛАА);

■ псевдонім (CNAME);

■ поштовийобмінник (MX);

■ покажчик (PTR);

■ розташуванняслужби (SRV).

Вузол (А чи АААА)

Більшість мереж основну частину записів ресурсів у базі даних зони становлять записи ресурсів вузлів. Ці записи використовуються в зоні зв'язування комп'ютерних імен (імен вузлів) з IP-адресами.

Навіть при включенні динамічних оновлень для зон у деяких сценаріях запису вузлів потрібно буде додавати записи до зони вручну. На малюнку далі компанія Contoso, Inc. використовує доменне ім'я contoso .com у загальнодоступному просторі імен та внутрішньому домені Active Directory . У цьому випадку публічний веб-сервер www.contoso.com розташований поза доменом Active Directory і виконує оновлення лише на публічному повноважному DNS-сервері contoso.com. Але внутрішні клієнти пересилають запити DNS на внутрішні DNS - сервери. Оскільки запис А сервера www.contoso.com не оновлюється динамічно на внутрішніх DNS-серверах, його додають вручну, щоб внутрішні клієнти могли дозволяти імена та підключатися до громадського веб-сервера.

Записи вузлів можна додавати вручну, якщо у мережі використовується сервер UNIX. Наприклад, компанія Fabrikam, Inc. має у своїй приватній мережі один домен Active Directory з ім'ям fabrikam, com. Ця мережа також включає UNIX-сервер App1.fabrikam,com, який запускає важливий додаток для виконання щоденних операцій компанії. Оскільки UNIX-сервери не можуть виконувати динамічні оновлення, доведеться вручну додати запис вузла сервера Арр1 на DNS-сервер, який управляє зоною fabrikam, com. Інакше користувачі не можуть підключатися до сервера програм, вказуючи його ім'я FQDN.

Псевдонім (CNAME)

Ці записи іноді називають канонічними іменами. Вони дають змогу використовувати кілька імен для вказівки одного вузла. Наприклад, відомі імена серверів (ftp, www), як правило, реєструються за допомогою записів CNAME. Ці записи зіставляють імена вузлів, відповідні їх службам, із реальним записом Акомп'ютера, керуючого службою.

■ Коли потрібно перейменувати вузол, вказаний у записі тієї ж зони.

■ Якщо групове ім'я відомого сервера (наприклад, www) потрібно дозволити в групу окремих комп'ютерів (кожен з яких містить індивідуальні записи А), які забезпечують одну і ту ж службу (наприклад, група резервних веб-серверів).

Поштовий обмінник (MX )

Ці записи використовуються програмами електронної пошти для локалізації поштового сервера у зоні. Вони дозволяють зіставляти доменне ім'я, вказане на адресу електронної пошти із записом Акомп'ютера, керуючого поштовим сервером в домені. Таким чином, цей тип запису дозволяє DNS-серверу обробляти адреси електронної пошти, у яких не вказано поштовий сервер.

Часто записи MX створюються для забезпечення відмови стійкості ще одного поштового сервера на випадок недоступності бажаного сервера.

Багато серверів призначаються значення переваг. Чим нижче це значення, тим вищий порядок переваги сервера.

ПРИМІТКА: Символ @

У цьому прикладі символ @ представляє локальне доменне ім'я, що міститься на адресі електронної пошти.

ПокажчикPTR

Цей запис використовується лише в зонах зворотного перегляду для підтримки зворотного перегляду, який здійснюється при дозволі IP-адрес в імена вузлів або імена FQDN. Зворотний перегляд виконується в кореневих зонах домену in-addr. Arpa. Записи PTR можна додавати до зони вручну або автоматично.

Нижче наведено приклад текстового представлення у файлі зони запису PTR, створеної в диспетчері DNS, яка зіставляє IP-адресу 192.168.0.99 імені вузла server 1.google.

99 PTRserver 1.google.ru .

ПРИМІТКА: Номер 99 записуPRT

У зоні зворотного перегляду останній октет IPv 4-адреси еквівалентний імені вузла. Тому число 99 є ім'я, призначене вузлу всередині зони 0.168.192.in -addr .arpa . Ця зона відповідає підмережі 192.168.0.0.

Розташування службиSRV

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

Як програму, що використовує SRV, можна навести Windows Server 2008 Active Directory. Служба мережного входу в систему Netlogon використовує записи SRV для локалізації контролерів домену, виконуючи пошук домену Служби Active Directory полегшеного доступу до каталогів (Lightweight Directory Access Protocol, LDAP). DNS, щоб підвищити стійкість до відмови або усунути несправності мережних служб.

УвімкненняDNS для дозволуWINS

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

Наприклад, якщо DNS-клієнт запитує ім'я ClientZ .contoso .com і найкращий DNS-сервер не може знайти відповідь звичайних джерелах(Кеше, даних локальної зониі за допомогою опитування інших серверів), сервер запитує ім'я CLIENTZ. на WINS-сервері, вказаному в записі WINS . Якщо сервер WINS відповідає на запит, DNS-сервер повертає його відповідь клієнту.

Очищення та видалення застарілих записів

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

Увімкнення очищення

Щоб увімкнути очищення окремої зони, потрібно включити цю функцію на рівні сервера та рівні зони.

Щоб увімкнути очищення на рівні сервера, у дереві консолі DNS (DNS Manager ) клацніть правою кнопкою миші значок сервера і застосуйте команду Встановити властивості очищення для всіх зон (Set Aging /Scavenging For All Zones ). Потім у діалоговому вікні Властивості очищення сервера (Server Aging /Scavenging Properties) встановіть прапорець Видаляти застарілі записи ресурсів (Scavenge Stale Resource Records). Хоча цей параметр включає на рівні сервера штампи часу та очищення всіх нових зон, він не включає штампи часу і очищення існуючих зон, інтегрованих в Active Directory .

Щоб задіяти їх, клацніть ОК, а потім у діалоговому вікні Підтвердження очищення сервера від застарілих ресурсів (Server Aging/ Scavenging Confirmation) установіть прапорець для застосування цих параметрів до існуючих зон, інтегрованих у Active Directory.

Щоб увімкнути штампи часу та очищення на рівні зони, відкрийте Властивості зони, а потім на вкладці Загальні (General) клацніть кнопку Очистка (Aging). У діалоговому вікні Властивості очищення для зони (Zone Aging/Scavenging Properties) встановіть прапорець Видаляти застарілі записи ресурсів (Scavenge Stale Resource Records).

Штампи часу DNS-сервер здійснює очищення за допомогою штампів часу, встановлених для записів ресурсів у зоні. Зони, інтегровані в Active Directory, встановлюють значення штампів часу для записів, що динамічно реєструються, за замовчуванням ще до включення очищення, Однак основні стандартні зони встановлюють штампи часу для динамічно реєстрованих записів в зоні лише після включення очищення. Записам ресурсів, створюваним вручну всім типів зон, призначається штамп часу 0; це означає, що їх вік не визначатиметься.- цей час між останнім оновленнямштампу та його можливим наступним оновленням. Блокування не дозволяє серверу обробляти непотрібні оновлення та знижує обсяг трафіку. За промовчанням призначається інтервал блокування 7 днів.

■ Модифікаціяінтервалуоновлення

Інтервал оновлення — це проміжок між раннім часом оновлення штампу часу і раннім часом початку очищення запису. Після закінчення інтервалів блокування та оновлення запису можуть видалятися із зони. За замовчуванням інтервал дорівнює 7 дням. Тому при включенні штампів часу записи ресурсів, що динамічно реєструються, можуть бути видалені через 14 днів.

Виконання очищення

Очищення виконується автоматично або вручну. Для автоматичного виконанняочищення потрібно дозволити автоматичне видалення застарілих записів ресурсів на вкладці Додатково (Advanced) діалогового вікна властивостей DNS-сервера.

Якщо ця опція не увімкнена, ви можете виконати очищення в зонах вручну, клацнувши правою кнопкою миші значок сервера в дереві консолі Диспетчер DNS (DNS Manager) і застосувавши команду Видалити застарілі записи (Scavenge Stale Resource Records).

Зона GlobalNames

У Windows Server 2008 включений новий компонент, що дозволяє всім DNS-клієнтам у лісі Active Directory використовувати імена з однієї мітки, наприклад Mail, для підключення до ресурсів сервера. Цей компонент зручно використовувати, якщо список перегляду DNS-суфіксів за замовчуванням для DNS-клієнтів не дозволяє користувачам швидко підключатися (або підключатися взагалі) до ресурсу за допомогою такого імені з однієї мітки.

DNS-сервер у Windows Server 2008 дозволяє створювати зону GlobalNames. За промовчанням зона GlobalNames не існує, однак, розгорнувши зону з цим ім'ям, можна забезпечити доступ до вибраних ресурсів за допомогою імен з однієї мітки, не використовуючи WINS. Як правило, імена з однієї мітки призначаються важливим і широко використовуваним серверам, яким вже призначені статичні IP-адреси. GlobalNames на віддаленому сервері замість точки введіть ім'я віддаленого сервера.

■ створеннязони GlobalNames

Наступний крок а розгортанні зони GlobalNames полягає у створенні зони для DNS-сервера, що служить контролером домену Windows Server 2008. Зона GlobalNames є не особливим типом зони, а лише інтегрованою в Active Directory зону прямого перегляду з ім'ям GlobalNames. Під час створення зони виберіть реплікацію даних зони для всіх DNS-серверів у лісі. Ця опція знаходиться на сторінці Область реплікації зони, інтегрованої в Active Directory (забезпечити можливість дозволу імен з однієї мітки, створіть і зоні G lobalNames запис псевдоніма (CNAME ) ресурсу. Ім'я, призначене кожному запису CNAME , представляє ім'я з однієї мітки, за допомогою якого використовується підключатися до ресурсу Відзначимо, що кожен запис CNAME вказує запис вузла ще в одній зоні.

Система доменних імен – основа сучасного інтернету. Люди не бажають ускладнювати себе запам'ятовуванням набору цифр 63.245.217.105, а хочуть, щоб на ім'я mozilla.org комп'ютер з'єднав їх із зазначеним вузлом. Цим і займаються DNS-сервери: переводять запити людей у ​​зрозумілий цифровий формат. Однак у деяких випадках може знадобитися зворотне (reverse) перетворення IP-адреси → DNS-ім'я. Про такі імена й йтиметься нижче.

Навіщо потрібно?

Наявність коректно налаштованої адреси rDNS абсолютно необхідно, щоб відправляти повідомлення з вашого власного сервера корпоративної пошти . Практично всі поштові сервери відкинуто прийом повідомлення ще на стадії початку сесії, якщо IP-адреса вашого сервера відсутня запис у зворотній зоні DNS. Причина відмови віддаленим поштовим сервером буде, швидше за все, зазначена такою:
550-"IP-адреса не має PTR (адреса до електронної пошти) запису в DNS, або якщо PTR повідомлень не має жодного запису A (посилання на адресу) запису. Pls check and correct your DNS record."

або
550-There's не відповідають PTR для вашої IP-адреси (IP-адреси), які є 550 необхідних. Sorry, bye.

або просто
550 Ваш IP не має PTR Record

Число 550 у всіх трьох випадках є стандартним кодомпоштового SMTP сервера, що повідомляє про критичну помилку, яка непереборно перешкоджає подальшій роботі в рамках цієї поштової сесії. Треба сказати, що всі помилки серії 500 є критичними і продовження передачі пошти після їх появи неможливо. Текст пояснює причину відмови більш докладно і повідомляє, що адміністратор поштового сервера-отримувача налаштував його на перевірку наявності у поштового сервера-відправника запису в зворотній зоні DNS (rDNS) і у разі її відсутності сервер-отримувач зобов'язаний відмовляти відправнику в з'єднанні (SMTP- помилки серії 5XX).

Як налаштувати та використовувати?

Правами на налаштування зворотної зони DNS (reverse DNS) має лише власник відповідного блоку IP-адрес, якій ця зона відповідає. Як правило, цим власником виявляється провайдер, який володіє власною автономною системою. Докладніше про реєстрацію своєї автономної системи (AS) та блоку IP-адрес можна прочитати в цій статті. Якщо коротко, то оператору блоку IP-адрес для реєстрації зворотної зони DNS необхідно зареєструвати у своєму особистому кабінетіна сайті RIPE об'єкт типу «domain», вказати адресу DNS-серверів, які підтримуватимуть зону rDNS та налаштуватимуть підтримку зони виду 3.2.1.in-addr.arpa на них. За ресурси у зворотній зоні відповідає покажчик (pointer) – запис типу PTR. До неї і йдуть запити про дозвіл IP-адреси в ім'я хоста.

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

Приклади хороших імен для сервера пошти:

mail.domain.ru
mta.domain.ru
mx.domain.ru

Приклади поганих імен:

host-192-168-0-1.domain.ru
customer192-168-0-1.domain.ru
vpn-dailup-xdsl-clients.domain.ru

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

З успіхом використовувати запити до зворотних зон DNS можна і потрібно одразу після запуску поштового сервера. Для цього необхідно зробити лише невелике налаштування ПЗ. У різних поштових серверах налаштування перевірки rDNS робиться по-різному:

так для поштового сервера Postfix необхідно увімкнути опцію
reject_unknown_client

в іншому популярному поштовому сервері Exim
verify = reverse_host_lookup

MS Exchange Server
У оснащенні Exgange Server перейти до розділу Servers далі вибрати сервер у розгорнутому списку, вибрати Protocols, далі протокол SMTP, у правому вікні виділити SMTP сервер і з кліку правою кнопкою миші вибрати зі списку Properties. Далі закладка Delivery → Perform reverse DNS lookup on incoming messages

Тепер усі повідомлення з IP-адрес не мають зворотного запису в DNS (записів типу PTR) будуть відкидатися, потік спаму значно скоротиться. Мабуть, це найпростіший, дієвий і найменш ресурсомісткий із усіх методів фільтрації спаму: перевіркою reverse DNS відсікається переважна більшість спаму, що розсилається із заражених комп'ютерів звичайних користувачів, складових спамерів ботнети.

При перепублікації статті встановлення активного індексованого гіперпосилання на джерело - сайт сайт обов'язковий!

Основи

Що таке запис зворотної зони DNS?

Звичайні запити DNS визначають невідому IP-адресу для відомого імені хоста. Це необхідно, коли, наприклад, браузеру потрібно встановити TCP-з'єднання з сервером по введеному в адресному полі URL.

Forum.hetzner.de --> 213.133.106.33

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

213.133.106.33 --> dedi33.your-server.de

Як ви бачите, іменам хоста при прямому та зворотному запитах необов'язково збігатися!

Яким є призначення запису зворотної зони DNS?

• traceroute показує не тільки IP-адреси, але і імена вузлів. Це значно полегшує діагностику помилок.
• Велика кількість поштових серверів приймає листи тільки якщо IP-адреса відправника має зворотний DNS-запис.
• Зворотні DNS-записи можуть використовуватися в SPF-записах (Sender Policy Framework; технологія, що запобігає розсилці спаму та вірусів з підроблених email-адрес).

Як технічно працює зворотне перетворення на серверах DNS?

Практика

Як я можу призначити кілька імен на мою IP-адресу, якщо розміщені різні домени на моєму сервері?

Це неможливо. Тільки одне ім'я призначається на кожну IP-адресу.

Більш того, будь-які зворотні зони прописані для сервера. Для звернення до сайту браузеру достатньо провести лише пряме перетворення (Ім'я -> IP). Тут, звичайно, може бути кілька імен, наприклад, кілька записів типу A або кілька записів типу CNAME, які вказують на A-запис.

Для роботи поштових серверів необов'язково мати кілька імен хоста на одну IP-адресу. Зворотний запис DNS повинен відповідати імені хоста SMTP-сервера (зверніться до налаштувань відповідного SMTP-сервера).

Якщо кілька доменів керуються через IP-адресу (досить часто), можна використовувати нейтральне ім'я, не пов'язане з доменами користувачів. Спам-фільтри лише перевіряють чи відповідає зворотний DNS-запис імені у відповіді на команду HELO. Це ніяк не впливає на доменні імена поштові адресиу листах, що передаються.

• Зворотний запис DNS повинен відповідати імені поштового сервера або будуватися на підставі IP-адреси.
• Зворотний DNS-запис повинен також резолвуватися "вперед" - на ту ж IP-адресу.
• Зворотний DNS-запис не повинен бути схожим на автоматично-згенерований, наприклад "162-105-133-213-static.hetzner.de", так часто такі імена негативно оцінюються спам-фільтрами.
• Ім'я, що дається, має існувати. Будь ласка, не використовуйте неіснуючі доменні імена.

Приклад хорошого запису:

Srv01.grossefirma.de --> 213.133.105.162 213.133.105.162 --> srv01.grossefirma.de > telnet 213.133.105.162 25 220 srv01.gros

Я ставлю PTR на моєму DNS-сервері. Чому це не працює?

Ваш DNS-сервер відповідає лише за пряме перетворення.

Власник блоку IP-адрес (наприклад, Hetzner Online GmbH) є відповідальним за підтримку авторитативних DNS-серверів для зворотних записів.

Зворотні записи DNS можна створювати лише за допомогою відповідної функції панелі Robot ( ліве меню-> "Servers" -> клацання по серверу -> "IPs" -> клацання по текстовому полю поряд з IP-адресою).

Зворотній запис мого сервера відрізняється від HELO мого поштового сервера. Чи це проблема?

Приклад: зворотний запис DNS для IP-адреси сервера "www.grossefirma.de". У відповідь команду HELO поштовий сервер відповідає "mail.grossefirma.de".

Деякі спам-фільтри розцінюють листи від таких відправників як спам. Подібні невідповідності мають бути виправлені. Зворотний запис DNS та ім'я поштового сервера повинні бути однаковими. У прикладі вище можуть бути, наприклад, "srv01.grossefirma.de". Ім'я "www.grossefirma.de" може бути без жодних наслідків перенаправлено на srv01.grossefirma.de" за допомогою CNAME-запису.

Детальне тестування DNS-записів можна провести скориставшись