DHCP і DNS: динамічний дует

1. Розробки в області DHCP і динамічної DNS повинні полегшити управління IP-адресами та іменами доменів.
2. ОСНОВИ TCP / IP
3. DHCP: заклинання IP?
4. ХОСТ ПІД БУДЬ-ЯКОГО ІНШОГО ІМЕНЕМ
5. ХТО СТУКАЄ В ДВЕРІ ДО МЕНЕ?
6. Динамічні ПАКЕТИ
7. переконфігурація DHCP

Розробки в області DHCP і динамічної DNS повинні полегшити управління IP-адресами та іменами доменів.

Внаслідок гігантського попиту на доступ в Internet і прагнення великих і малих компаній побудувати ідеальну корпоративну мережу Intranet, адміністратори мереж стикаються з численними труднощами в управлінні IP-адресами та іменами доменів. Останні розробки в області протоколу динамічної конфігурації хоста (Dynamic Host Configuration Protocol, DHCP) і динамічної системи імен доменів (Domain Name Service) відкривають перед ними нову альтернативу.

ОСНОВИ TCP / IP

TCP / IP - це не один протокол, а скоріше сімейство або комплект взаємозалежних протоколів. Протокол TCP пов'язує високорівневі сервіси з IP, а той в свою чергу взаємодіє з протоколом канального рівня. На рисунку 1 зображена ієрархія сімейства протоколів TCP / IP в зіставленні з еталонною моделлю ISO OSI.

Малюнок 1.Стек протоколів TCP / IP показаний в порівнянні з еталонною моделлю OSI. В ієрархії TCP / IP протоколи TCP і IP служать сполучними ланками між високорівневими і низькорівневими протоколами.

Мережеві пристрої, що використовують TCP / IP, такі як комп'ютери, принтери, маршрутизатори та концентратори, потребують способі ідентифікації один одного. Це досягається за допомогою схеми адресації IP, при якій кожен об'єкт, або "хост", отримує числовий ідентифікаційний код у вигляді чотирьох 8-розрядних сегментів (або октетів) з 32-розрядної адресного простору, причому значення кожного сегмента варіюється від 0 до 255. схема ідентифікації IP нагадує чимось принцип освіти телефонних номерів, згідно з яким місце розташування абонента визначається відповідно до ієрархією "код міста-префікс АТС-номер".

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

DHCP: заклинання IP?

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

Дана процедура є досить простий, але що робити, якщо під вашим піклуванням перебуває мережа з більш ніж 10 000 вузлами, причому щодня з'являється кілька десятків або навіть сотень нових систем? До того ж не варто забувати про ці надокучливих портативних комп'ютерах, користувачі яких підключають адаптери PCMCIA до з'єднувачів розділу 5 там, де їм заманеться. З огляду на кількість людино-годин, необхідних для вирішення проблеми дублювання IP-адрес укупі з проведенням нових інсталяцій і діагностикою успадкованих систем, немає нічого дивного в тому, що організації, великі і малі, шукають інші рішення.

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

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

Зокрема, DHCP застосовує той же самий формат пакетів, що і BOOTP, але якщо останній використовує в поле опцій тільки два типи повідомлень (BootRequest і BootReply), то DHCP підтримує сім типів повідомлень (DhcpDiscover, DhcpOffer, DhcpRequest, DhcpAck, DhcpNak, DhcpDecline і DhcpRelease). Завдяки цьому формату DHCP сумісний як з клієнтами BOOTP, так і з транслює агентами BOOTP. Незважаючи на деякі невеликі відмінності в способі придбання нової порівняно з модифікованою конфігурацією, механізм початкової конфігурації вельми показовий для функціонування системи DHCP в цілому.

При запуску клієнт DHCP шукає сервер DHCP, посилаючи широковещательное повідомлення DhcpDiscover. При отриманні дійсного повідомлення сервер DHCP повертає широковещательное пропозицію DhcpOffer, поміщаючи незайнятий IP-адреса в полі YIADDR (дана абревіатура розшифровується як "ваш IP-адреса"). Клієнт записує запропонований IP-адреса в область ідентифікатора обраного ним сервера в повідомленні DhcpRequest (на повідомлення DhcpDiscover може відповісти кілька серверів). При отриманні запиту сервер порівнює міститься там ідентифікатор зі своїм власним. Якщо ID не збігаються, сервер генерує явне повідомлення DhcpDecline; якщо ID збігаються, то сервер перевіряє, вільний чи зайнятий запитуваний IP-адреса; якщо адреса вільна, він відправляє підтвердження DhcpAck, а в іншому випадку - DhcpNak (отримавши DhcpNak, клієнт починає весь процес спочатку).

При отриманні підтвердження (DhcpAck) клієнт перевіряє повідомлення, зокрема правильність адреси мережі. Припустимо, що адреса неправильний, тоді клієнт відправляє повідомлення DhcpDecline. Якщо ж все добре, клієнт переходить в так зване зв'язаний стан (сервер фіксує дані про адресу клієнта в базі даних DHCP) і починає користуватися тільки що отриманим адресою. Залежно від режиму (автоматичне повторне використання адреси можливо тільки при динамічному призначення) інформація про оренду передається у вигляді ідентифікаційної записи про умови оренди в повідомленні DhcpAck. Клієнтські системи можуть відмовитися від оренди до закінчення терміну за допомогою відправки сервера повідомлення DhcpRelease. DHCP підтримує опції продовження терміну оренди, так що клієнт може запросити надав йому адресу сервер DHCP про продовження оренди, завдяки чому відпадає необхідність повторювати процес запиту адреси з нуля.

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

Як зазначено в документі RFC 1 541, опублікованому IETF, сервери DHCP, на відміну, наприклад, від системи імен доменів, не можуть обмінюватися інформацією для узгодження бази даних про адреси. Ось чому адміністраторам, які мають кілька серверів DHCP, необхідно задати своє діапазон адрес для кожного сервера, в іншому випадку різні клієнти можуть автоматично отримати однакові IP-адреси - що за гігантський крок назад! Сумно про це говорить, але розглядаються IETF пропозиції щодо DHCPv6 ніяк не зачіпають питання про взаємодію серверів, залишаючи вирішення цієї проблеми на майбутнє.

ХОСТ ПІД БУДЬ-ЯКОГО ІНШОГО ІМЕНЕМ

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

Цю функцію можна побачити в дії, якщо у вас є вихід в Internet. Після встановлення з'єднання з місцевим оператором відкрийте вікно запрошення на введення команди і запустіть утиліту ping для пошуку даного хоста по імені або номеру. Наприклад, ввівши ping network-mag.com, ви отримаєте відповідь, де вказано, що IP-адреса даного хоста 198.71.19.34, а його справжнє ім'я - whiz.mfi.com.

Даний запит обробляється агентом хоста, відомого як resolver. Цей агент зв'язується потім з серверами імен, що обслуговують різні піддерева в ієрархії доменів. При реєстрації нового домену первинні сервери імен генерують відповідний запис, після чого вона поширюється між іншими серверами імен в Internet. У ping IP-адресу можна вказати безпосередньо, так що звернення до DNS не буде потрібно (див. Технічні деталі в www.ds.internic.net/rfc/rfc1035.txt ).

ХТО СТУКАЄ В ДВЕРІ ДО МЕНЕ?

Тепер, коли сервери DHCP можуть динамічно призначати IP-адреси, якими DNS повинна управляти, ми хотіли б мати і динамічну службу DNS, щоб вона автоматично модифікувала таблицю відповідності імен доменів відповідно до нових призначень DHCP. Сучасний стандарт не забезпечує бази для динамічної модифікації таблиці імен доменів згідно призначень DHCP; однак проект стандарту, що розглядається IETF, укупі з ринковим пресингом, посилився в результаті появи розробок декількох виробників, повинен врешті-решт призвести до появи нового стандарту в найближчі кілька років.

Взагалі-то, термін "динамічна DNS" відноситься до систем, в яких посилання таблиці DNS на динамічно призначаються IP-адреси хостів оновлюються автоматично. Класичний приклад додатків цього типу можна знайти в мобільній обчислювальному середовищі, де користувач портативного комп'ютера переходить з однієї підмережі в іншу в межах одного і того ж будівлі, або користувачі сервера віддаленого доступу повинні зв'язуватися з декількома різними серверами DHCP або PPP. При переході хоста laptop.network.com з одного з'єднання на інше, він запитує новий IP-адреса у доступного сервера DHCP, а той в свою чергу просить сервер імен модифікувати таблицю відповідності адрес. Ця функція автоматичного оновлення дозволяє іншим комп'ютерам знаходити laptop.network.com по імені, а додатків і ресурсів, що розділяються, що використовують ідентифікацію по імені, нормально працювати незалежно від IP-адреси хоста на даний момент.

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

У певному сенсі і DHCP і DNS не вистачає того, що є в іншого: DHCP не володіє такою функцією DNS, як поширення таблиць DNS між серверами, а DNS - функцією динамічного оновлення інформації DHCP. Еволюція обох систем привела до своєрідної модифікації проблеми курки і яйця. Будучи спадкоємцем BOOTP, DHCP не має механізму для звернення до записів DNS про ресурсах для встановлення відповідності між повним доменним ім'ям (Fully Qualified Domain Name, FQDN) і IP-адресою. В результаті сервер DHCP робить невірні припущення щодо записів клієнта DNS про ресурсах A і PTR.

У відсутності стандарту компанії IBM, Quadritek Systems і Isotro Network Management розробили програмне забезпечення серверів DHCP і динамічної DNS для вирішення цієї проблеми в такий спосіб: спочатку воно виконує функцію сервера DHCP по динамічному призначенням IP-адреси для даного клієнта, а потім функцію динамічного сервера DNS по розміщення оновленої інформації про відповідність імен. Такі системи знаходяться поки в дитячому стані і не відрізняються підтримкою різноманітних клієнтських платформ.

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

Уявіть собі на мить, що зловмисник посилає IP-адресу своєї машини в якості оновлення відкритого сервера DNS і, таким чином, займає місце справжнього хоста. Насправді ця проблема складається з двох: перевірка клієнта і авторизація поновлення DNS. Нещодавно прийнятий документ RFC 2065 пропонує розширити структуру записів DNS для підтримки використання криптографічних цифрових сертифікатів поряд з оснащеними функціями захисту агентами (resolver) і додатками для закладення наявних "дірок" в системі захисту DNS.

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

OS / 2 Warp Server 4.0 компанії IBM представив на загальний огляд "істинно" динамічну DNS (Warp DNS автоматично оновлюється відповідно до даних DHCP), причому він вирішує і проблему безпеки за допомогою реалізації двох рівнів цифрових підписів на основі механізму відкритих ключів RSA для ідентифікації транзакцій (за допомогою захищеного, що генерується клієнтом ключа або за допомогою захищеного, що генерується сервером ключа, якого призначає клієнту).

За словами Глена Стампа, експерта по динамічному IP в IBM-Raleigh, компанія зайняла вичікувальну позицію, поки статус Secured DNS (DNSSEC) RFC 2065 не буде остаточно визначено; однак він дав ясно зрозуміти, що IBM розглядає питання захисту як питання надзвичайної важливості. Відповідно до твердження Стампа, наступна версія OS / 2 Warp Server матиме додаткові функції захисту разом з поліпшеними функціями DHCP і динамічної DNS корпоративного рівня.

Хоча динамічна DNS в Warp Server 4.0 є певним кроком вперед, клієнтська підтримка обмежена Warp Connect і AIX. Однак бета-версію клієнта для Windows 95 можна знайти на вузлі Web компанії IBM, і вона повинна з'явитися в остаточному вигляді, коли ця стаття вийде в світ. Конфігурація DHCP здійснюється за допомогою графічного інтерфейсу в дві колонки, а він в свою чергу генерує конфігураційний файл ASCII, редагування якого можна виробляти і вручну. Правда, функції сервера запускаються за допомогою команд. Хоча графічний інтерфейс динамічної DNS в версії 4.0 відсутня, конфігураційний GUI на базі Java знаходиться в стадії розробки для наступної версії, поява якої заплановано на осінь. Також робота ведеться і над взаємодією з функціями DHCP ОС Windows NT 4.0, однак підтримка Windows NT 3.51 в даний час не планується.

Windows NT Server 4.0 компанії Microsoft має поліпшені в порівнянні з версією 3.51 функції DHCP і DNS, але повноцінних функцій динамічної DNS у нього немає, так як оновлення інформації про імена можливо тільки для клієнтів WINS (Windows Internet Naming Service). В результаті DNS в Windows NT 4.0 не має зв'язку з DHCP. Хоча онлайнові технічні характеристики по NT 4.0 стверджується, що NT підтримує стандартний DHCP, система проте не підтримує BOOTP, а це в разі мереж, де є застаріле обладнання, може привести до проблем взаємодії.

NetWare / IP компании Novell, что поставляється разом з IntranetWare, надає користувач NetWare підтрімку сервера DHCP, причому конфігурація здійснюється за помощью утіліті DHCP Configuration Utility (DHCPCFG) зі Стандартним інтерфейсом "а ля" NLM. DHCPCFG автоматично віявляє підмережі, до якіх сервер DHCP підключеній, створюючі Профіль підмережі для кожної, причому пізніше Профіль может буті відредагованій. Утиліта допускає створення профілів для підмереж вручну, якщо сервер не має з ними прямого з'єднання. Реально сервер виконує свої функції за допомогою dhcpsrvr.nlm.

Хоча NetWare / IP дозволяє задавати кілька діапазонів IP-адрес в пулі, система не підтримує виключені адреси безпосередньо; проте адміністратор може ввести MAC-адреси вузлів, які DHCP не повинен обслуговувати (т. е. призначати їм IP-адреси), за допомогою їх прямої вказівки в списку виключених вузлів. Добре хоча б те, що виключення адрес може проводитися з використанням символу підстановки замість поля вузла в MAC-адресу. DNS компанії Novell повністю статична, і вона взагалі не має ніяких динамічних функцій.

Динамічні ПАКЕТИ

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

Утиліти управління IP пропонують кілька постачальників, але серед них ми б хотіли виділити: Quadritek Systems і Isotro Network Management. Продукти обох компаній мають широкий діапазон функцій управління і дозволяють здійснювати міграцію до IP в масштабах підприємства. Таким чином, в питаннях DHCP і динамічної DNS ці компанії знають, що робити.

Коли цей номер вийде друком, Quadritek повинна вже випустити версію 3.1 своєї системи QIP для управління IP. Дана версія буде підтримувати оновлення сервера DHCP не тільки на HP-UX, SunOS, Sun Solaris і AIX 4.1.2, але і на Windows NT. QIP вже має клієнтів управління для Windows 3.1, Windows 95 і Windows NT, а також Unix і Motif / X11R5.

Система Quadritek реалізує унікальний підхід до управління IP: і наявні, і плановані сегменти враховуються таким чином, що нові призначення IP-адрес в підмережі робляться системою активними автоматично. Система являє єдину точку управління всіма серверами DNS і DHCP, в тому числі великі можливості управління орендою, адресами і оновленням конфігурації. QIP імпортує існуючі таблиці DHCP і DNS в центральну базу даних, замінюючи оригінальні функції системи хоста на свої власні, після чого база даних вихідної системи оновлюється з цієї центральної системи управління. Адміністратор NT повинен буде спочатку імпортувати дані IP в QIP, а потім відключити повністю сервіс DHCP, після чого QIP бере на себе виконання всіх функцій IP і DNS. "При розгортанні будь-ким сервера управління QIP він отримує одну базу даних, що відповідає за всю корпорацію, і ця база даних бере на себе турботу про оновлення численних віддалених баз даних незалежно від того, на якій платформі вони знаходяться", - говорить Малкольм Хейвуд , віце-президент Quadritek.

Isotro пропонує свою систему NetID в версіях для Unix і Windows. NetID має сервери DHCP і динамічної DNS, Web Gateway для доступу до Internet і великий комплект інструментів для управління IP. Корпоративне видання має ліцензію на трьох користувачів, підтримує бази даних Sybase і Oracle в якості центрального сховища всієї ідентифікаційної інформації про хостах, а також включає Admin Tool, Export Tool, Import Tool і Scheduler.

За допомогою NetID Admin Tool адміністратор може переглядати всю інформацію про ідентифікацію, управляти доступом користувачів і конфігурувати систему за допомогою визначених полів, записів про ресурси, опцій BOOTP, шаблонів, системних моделей і многооконного інтерфейсу. Адміністратор може безпосередньо ініціювати функції імпорту та експорту з Admin Tool або, при бажанні, з Export Tool і Import Tool. За допомогою останнього інструменту ідентифікаційну інформацію можна завантажити з існуючих файлів з даними про зони DNS, хост-файлів Unix, табличних файлів BOOTP або призначених для користувача текстових файлів, створених з електронних таблиць або баз даних. Система має опції для управління опціями DHCP і BOOTP на рівні всієї мережі, підмережі та хоста.

переконфігурація DHCP

Наступний рік стане, ймовірно, досить бурхливим періодом в еволюції DHCP і динамічної DNS, але для цього IETF і інші групи повинні зупинити свій вибір на якомусь одному стандарті. Якщо ви читали нашу статтю уважно, то, мабуть, помітили, що стандарт DHCP не описує повідомлення DhcpReconfigure. Ви абсолютно праві, це справа DHCPv6, пропонованої структури для передачі інформації DHCP вузлів IPv6. Залишайтеся з нами, гонки повинні бути цікавими ...

ТАБЛИЦЯ 1 - АНАТОМІЯ ЗАПИСІВ DNS Про РЕСУРСАХ ЗГІДНО RFC 1034