|
|
| (не показані 4 проміжні версії цього учасника) |
| Рядок 1: |
Рядок 1: |
| − | '''DNS''' (Domain Name System) — система доменних імен) - комп'ютерна розподілена система для отримання інформації про домени. Найчастіше використовується для отримання IP- адреси на ім'я хоста, отримання інформації про маршрутизацію пошти, обслуговуючих вузлах для протоколів в домені(SRV- запис).
| + | == Сторінка [[DNS]] == |
| − | | + | == Сторінка [[DHCP]] == |
| − | == Основи DNS == | + | |
| − | [[Файл:Dns-tree.PNG|450px|thumb|right|Іерархічна організація DNS]] | + | |
| − | Як відомо, для звернення до хостів у мережі Internet використовуються 32-х розрядні IP-адреси, які однозначно ідентифікують будь-який мережевий комп'ютер у глобальній мережі. Однак для користувачів застосування IP-адрес при звернені до хостів не дуже зручне.
| + | |
| − | Тому в Internet прийнято присвоювати імена всіх комп'ютерів в Мережі. Використання імен дає користувачеві можливість краще орієнтуватися в кіберпросторі. В Internet - куди простіше запам'ятати, наприклад, ім'я '''''http://www.ferrari.it/''''', ніж чотирьох ланковий ланцюжок IP-адреси. Застосування в Internet мнемонічних, зрозумілих для користувачів імен породило проблему їх перетворення в IP-адреси. Таке перетворення необхідно, так як на мережному рівні адресація пакетів здійснюється не по іменах, а по IP-адресами, отже, для безпосередньої адресації повідомлень в Internet імена не пригодні. На ранньому етапі розвитку Internet, коли в мережу (тоді вона ще не називалася Мережа) було об'єднано невелику кількість комп'ютерів, Інформаційний центр мережі ('''''Network Information Center''''', '''''NIC''''') для вирішення проблеми перетворення імен в адреси завів спеціальний файл (файл '''hosts'''), в який вносилися імена і відповідні ним IP-адреси всіх хостів у мережі. Даний файл регулярно оновлювався і розповсюджувався по всій мережі. Але в міру розвитку Internet число хостів, об'єднаних в мережу, збільшувалася, і дана схема ставала все менш і менш працездатною. Тому була створена нова '''система перетворення імен''', '''що дозволяє користувачеві''' в разі відсутності у нього інформації щодо відповідності імен і IP-адрес '''отримати необхідні відомості від найближчого інформаційно-пошукового сервера''' ([[DNS сервер]]). Ця система одержала назву системи імен доменів - [[DNS]] ('''''Domain Name System''''').
| + | |
| − | | + | |
| − | Для реалізації системи DNS був створений спеціальний мережевий протокол - DNS. Крім того, в мережі створювалися спеціальні виділені інформаційно-пошукові сервери - DNS-сервери. Пояснимо основне завдання, вирішуване службою DNS. У сучасній Мережі хост при зверненні до віддаленого сервера звичайно обізнаний тільки про його імені і не знає IP-адреси, який необхідний для безпосередньої адресації. Отже, перед хостом виникає стандартна проблема віддаленого пошуку: по імені віддаленого хоста знайти його IP-адресу. Вирішенням цієї проблеми і займається [[служба DNS]] на базі протоколу DNS.
| + | |
| − | | + | |
| − | == Ключові характеристики DNS ==
| + | |
| − | | + | |
| − | DNS має наступні характеристики:
| + | |
| − | * ''Розподіленність адміністрування''. ''Відповідальність'' за різні частини ієрархічної структури несуть різні люди або організації.
| + | |
| − | * ''Розподіленність зберігання інформації''. Кожен вузол мережі в обов'язковому порядку повинен зберігати тільки ті дані, які входять в його ''зону відповідальності'' і(можливо) адреси ''кореневих DNS- серверів''.
| + | |
| − | * ''Кешування інформації''. Вузол ''може'' зберігати деяку кількість даних не зі своєї зони відповідальності для зменшення навантаження на мережу.
| + | |
| − | * ''Ієрархічна структура'', в якій усі вузли об'єднані в дерево, і кожен вузол може або самостійне визначати роботу нижчестоячих вузлів, або ''делегувати'' (передавати) їх іншим вузлам.
| + | |
| − | * ''Резервування''. За зберігання і обслуговування своїх вузлів(зон) відповідають(зазвичай) декілька серверів, розділені як фізично, так і логічно, що забезпечує збереження даних і продовження роботи навіть у разі збою одного з вузлів.
| + | |
| − | | + | |
| − | == Додаткові можливості == | + | |
| − | * підтримка динамічних оновлень
| + | |
| − | * захист даних(DNSSEC) і транзакцій('''TSIG''')
| + | |
| − | * підтримка різних типів інформації
| + | |
| − | | + | |
| − | == Термінологія і принципи роботи ==
| + | |
| − | Ключовими поняттями DNS є:
| + | |
| − | * '''Доменне ім'я''' (|domain - область) - вузол в дереві імен, разом з усіма підлеглими йому вузлами(якщо такі є), тобто іменована ''гілка'' або ''поддерево'' в дереві імен. Структура доменного імені відбиває порядок дотримання вузлів в ієрархії; доменне ім'я читається зліва направо від молодших доменів до доменів вищого рівня(в порядку підвищення значущості), кореневим доменом усієї системи є точка('.'), нижче йдуть домени першого рівня(географічні або тематичні), потім - домени другого рівня, третього і т. д. (наприклад, для адреси <tt>ru.wikipedia.org</tt> домен першого рівня - <tt>org</tt>, другого <tt>wikipedia</tt>, третього <tt>ru</tt>). На практиці точку у кінці імені часто опускають, але вона буває важлива у випадках розділення між відносними доменами і FQDN (Fully Qualifed Domain Name, повне певне ім'я домена).
| + | |
| − | * '''Піддомен''' (subdomain) - підпорядкований домен(наприклад <tt>wikipedia.org</tt> - піддомен домена <tt>org</tt>, а <tt>ru.wikipedia.org</tt> - домена <tt>wikipedia.org</tt>). Теоретично таке ділення може досягати глибини 127 рівнів, а кожна мітка може містити до 63 символів, поки загальна довжина разом з точками не досягне 254 символів. Але на практиці реєстратори доменних імен використовують строгіші обмеження. Наприклад, якщо у вас є домен виду mydomain.ru, ви можете створити для нього різні піддомени виду ''mysite1.mydomain.ru'', ''mysite2.mydomain.ru'' і т. д.
| + | |
| − | * '''Ресурсний запис''' - одиниця зберігання і передачі інформації в DNS. Кожен ресурсний запис має ''ім'я'' (тобто прив'язана до певного '''Доменного імені''', вузлу в дереві імен), ''тип'' і ''поле даних'', формат і зміст якого залежить від ''типу''.
| + | |
| − | * '''Зона''' - частина дерева доменних імен(включаючи '''ресурсні записи'''), що розміщується як єдине ціле на деякому сервері доменних імен('''DNS- сервері''', див. нижче), а частіше - одночасно на декількох серверах(див. нижче). Метою виділення частини дерева в окрему зону є передача '''відповідальності''' (див. нижче) за відповідний '''домен''' іншій особі або організації. Це називається '''делегуванням''' (див. нижче). Як зв'язна частина дерева, '''зона''' усередині теж є деревом. Якщо розглядати простір імен DNS як структуру із зон, а не окремих вузлів/імен, теж виходить дерево; виправдано говорити про батьківські і дочірні зони, про старших і підлеглих. На практиці, більшість зон 0-го і 1-го рівня('.', ru, com .) складаються з єдиного вузла, якому безпосередньо підкоряються дочірні зони. У великих корпоративних доменах(2-го і більше за рівні) іноді зустрічається утворення додаткових підпорядкованих рівнів без виділення їх в дочірні зони.
| + | |
| − | * '''Делегування''' - операція передачі '''відповідальності''' за частину дерева доменних імен іншій особі або організації. За рахунок делегування в DNS забезпечується распределенность адміністрування і зберігання. Технічно '''делегування''' виражається у виділенні цій частині дерева в окрему '''зону''', і розміщенні цієї '''зони''' на '''DNS- сервері''' (див. нижче), керованому цією особою або організацією. При цьому у батьківську зону включаються "склеюючі" '''ресурсні записи''' (NS і А), що утримують покажчики на '''DNS- сервера''' дочірньої зони, а уся інша інформація, що відноситься до дочірньої зони, зберігається вже на '''DNS- серверах''' дочірньої зони.
| + | |
| − | * '''DNS- сервер''' - спеціалізоване ПЗ для обслуговування DNS, а також комп'ютер, на якому це ПЗ виконується. DNS- сервер може бути відповідальним за деякі зони і/або може перенаправляти запити вищестоящим серверам.
| + | |
| − | * '''DNS- клієнт''' - спеціалізована бібліотека(чи програма) для роботи з DNS. У ряді випадків DNS- сервер виступає в ролі DNS- клієнта.
| + | |
| − | * '''Авторитетність''' (authoritative) - ознака розміщення зони на DNS- сервері. Відповіді DNS- сервера можуть бути двох типів: ''авторитетні'' (коли сервер заявляє, що сам відповідає за зону) і ''неавторитетні'' (Non - authoritative), коли сервер обробляє запит, і повертає відповідь інших серверів. В деяких випадках замість передачі запиту далі DNS- сервер може повернути вже відоме йому(по запитах раніше) значення(режим кешування).
| + | |
| − | * '''DNS- запит''' (lang - en|DNS query) - запит від клієнта(чи сервера) серверу. Запит може бути ''рекурсивним'' або ''нерекурсивним''.
| + | |
| − | | + | |
| − | Система DNS містить ієрархію '''DNS- серверів''', що відповідає ієрархії '''зон'''. Кожна '''зона''' підтримується як мінімум одним ''авторитетним сервером DNS'' (authoritative - авторитетний), на якому розташована інформація про домен.
| + | |
| − | | + | |
| − | Ім'я і IP- адреса не тотожні - один IP- адреса може мати безліч імен, що дозволяє підтримувати на одному комп'ютері множину веб-сайтів(це називається віртуальний хостинг). Зворотне теж справедливо - одному імені може бути зіставлена безліч IP- адрес : це дозволяє створювати алансування навантаження.
| + | |
| − | | + | |
| − | Для підвищення стійкості системи використовується безліч серверів, що містять ідентичну інформацію, а в протоколі є засоби, що дозволяють підтримувати синхронність інформації, розташованої на різних серверах. Існує 13 кореневих серверів, їх адреси практично не змінюються.<ref>Поточна версія кореневої зони завжди знаходиться за адресою: ftp://ftp.internic.net/domain/named.root</ref>
| + | |
| − | | + | |
| − | Протокол DNS використовує для роботи TCP- або UDP-Порт(TCP/UDP) 53 для відповідей на запити. Традиційно запити і відповіді вирушають у вигляді однієї UDP датаграми. TCP використовується для AXFR-запросов.
| + | |
| − | | + | |
| − | === Рекурсія ===
| + | |
| − | | + | |
| − | Терміном '''Рекурсія''' в DNS означають алгоритм поведінки '''DNS- сервера''', при якому сервер виконує від імені клієнта повний пошук потрібної інформації в усій системі DNS, при необхідності звертаючись до іншим '''DNS- серверам'''.
| + | |
| − | | + | |
| − | '''DNS- запит''' може бути ''рекурсивним'' - що вимагає повного пошуку, - і ''нерекурсивним'' (чи ''ітеративним'') - що не вимагає повного пошуку.
| + | |
| − | | + | |
| − | Аналогічно, '''DNS- сервер''' може бути ''рекурсивним'' (що уміє виконувати повний пошук) і ''нерекурсивним'' (що не уміє виконувати повний пошук). Деякі програми DNS- серверів, наприклад, BIND, можна конфігурувати так, щоб запити одних клієнтів виконувалися ''рекурсивно'', а запити інших - ''нерекурсивний''.
| + | |
| − | | + | |
| − | При відповіді на ''нерекурсивний'' запит, а також - при невмінні або забороні виконувати ''рекурсивні'' запити, - DNS- сервер або повертає дані про зону, за яку він '''ответствен''', або повертає адреси серверів, які мають великий об'єм інформації про запрошену зону, чим сервер, що відповідає, найчастіше - адреси кореневих серверів.
| + | |
| − | | + | |
| − | У разі ''рекурсивного'' запиту '''DNS- сервер''' опитує сервери(в порядку убування рівня зон в імені), поки не знайде відповідь або не виявить, що домен не існує. (На практиці пошук розпочинається з найбільш близьких до шуканого DNS- серверів, якщо інформація про них є в кеші і не застаріла, сервер може не просити інші DNS- сервери.)
| + | |
| − | | + | |
| − | Розглянемо на прикладі роботу усієї системи.
| + | |
| − | | + | |
| − | Припустимо, ми набрали в браузері адресу <tt>ru.wikipedia.org</tt>. Браузер запитує у сервера DNS : "яка IP- адреса у <tt>ru.wikipedia.org</tt>"?
| + | |
| − | Проте, сервер DNS може нічого не знати не лише про запрошене ім'я, але навіть про увесь домен <tt>wikipedia.org</tt>.
| + | |
| − | В цьому випадку сервер звертається до ''кореневого серверу'' - наприклад, 198.41.0.4. Цей сервер повідомляє - "У мене немає інформації про цю адресу, але я знаю, що 204.74.112.1 є відповідальним за зону <tt>org</tt>". Тоді сервер DNS направляє свій запит до 204.74.112.1, але той відповідає "У мене немає інформації про цей сервер, але я знаю, що 207.142.131.234 є відповідальним за зону <tt>wikipedia.org</tt>". Нарешті, той же запит вирушає до третього DNS- сервера і отримує відповідь - IP- адреса, яка і передається клієнтові - браузеру.
| + | |
| − | | + | |
| − | В даному випадку при дозволі імені, тобто в процесі пошуку IP по імені:
| + | |
| − | * браузер відправив відомому йому DNS- серверу ''рекурсивний'' запит - у відповідь на такий тип запиту сервер зобов'язаний повернути "готовий результат", тобто IP- адреса, або порожня відповідь і код помилки NXDOMAIN;
| + | |
| − | * DNS- сервер, що отримав запит від браузеру, послідовно відправляв ''нерекурсивні'' запити, на які отримував від інших DNS- серверів відповіді, поки не отримав відповідь від сервера, відповідального за запрошену зону;
| + | |
| − | * інші згадувані DNS- сервери обробляли запити ''нерекурсивний'' (і, швидше за все, не стали б обробляти запити рекурсивно, навіть якщо б така вимога стояла в запиті).
| + | |
| − | | + | |
| − | Іноді допускається, щоб запрошений сервер передавав ''рекурсивний'' запит "вищестоящому" DNS- серверу і чекав готової відповіді.
| + | |
| − | | + | |
| − | При ''рекурсивній'' обробці запитів усі відповіді проходять через DNS- сервер, і він дістає можливість ''кешуровати'' їх. Повторний запит на ті ж імена зазвичай не йде далі ''за кеш'' сервера, звернення до інших серверів не відбувається взагалі. Допустимий час зберігання відповідей в ''кеші'' приходить разом з відповідями(поле ''TTL'' '''ресурсного запису''').
| + | |
| − | | + | |
| − | Рекурсивні запити вимагають більше ресурсів від сервера(і створюють більше трафіку), так що зазвичай приймаються від "відомих" власникові сервера вузлів(наприклад, провайдер надає можливість робити рекурсивні запити тільки своїм клієнтам, в корпоративній мережі рекурсивні запити приймаються тільки з локального сегменту). Нерекурсивні запити зазвичай приймаються від усіх вузлів мережі(і змістовна відповідь дається тільки на запити про зону, яка розміщена на вузлі, на DNS- запит про інші зони зазвичай повертаються адреси інших серверів).
| + | |
| − | | + | |
| − | === Зворотний DNS- запит ===
| + | |
| − | DNS використовується в першу чергу для перетворення символьних імен в IP- адреси, але він також може виконувати зворотний процес. Для цього використовуються вже наявні засоби DNS. Річ у тому, що із записом DNS можуть бути зіставлені різні дані, у тому числі і яке-небудь символьне ім'я. Існує спеціальний домен <tt>in - addr.arpa</tt>, записи в якому використовуються для перетворення IP- адрес в символьні імена. Наприклад, для отримання DNS- імені для адреси <tt>11.22.33.44</tt> можна запросити у DNS- сервера запис <tt>44.33.22.11.in - addr.arpa</tt>, і той поверне відповідне символьне ім'я. Зворотний порядок запису частин IP- адреси пояснюється тим, що в IP- адресах старші біти розташовані на початку, а в символьних DNS- іменах старші(що знаходяться ближче до кореня) частини розташовані у кінці.
| + | |
| − | | + | |
| − | == Записи DNS ==
| + | |
| − | Ресурсні записи DNS
| + | |
| − | | + | |
| − | '''Записи DNS''', або '''Ресурсні записи''' (''англ.'' Resource Records, RR) - одиниці зберігання і передачі інформації в DNS. Кожен ресурсний запис складається з наступних полів:
| + | |
| − | * ''ім'я'' (NAME) - доменне ім'я, до якого прив'язана або якому "належить" цей ресурсний запис
| + | |
| − | * ''TTL'' (Time To Live) - допустимий час зберігання цього ресурсного запису в кеші ''невідповідального'' '''DNS- сервера''',
| + | |
| − | * ''тип'' (TYPE) ресурсного запису - визначає формат і призначення цього ресурсного запису
| + | |
| − | * ''клас'' (CLASS) ресурсного запису; '''''теоретично''''' вважається, що DNS може використовуватися не лише з [[TCP/IP]], але і з іншими типами мереж, код в полі ''клас'' визначає тип мережі. Деталі по можливих значеннях поля : http://tools.ietf.org/html/rfc5395#section - 3.2,
| + | |
| − | * довжина поля даних(RDLEN)
| + | |
| − | * ''поле даних'' (RDATA), формат і зміст якого залежить від ''типу'' запису.
| + | |
| − | | + | |
| − | Найбільш важливі типи DNS- записів :
| + | |
| − | * '''Запис A''' (''address record'') або '''запис адреси''' зв'язує ім'я хоста з адресою IP. Наприклад, запит A- запису на ім'я <tt>referrals.icann.org</tt> поверне його IP адреса - <tt>192.0.34.164</tt>
| + | |
| − | * '''Запис AAAA''' (''IPv6 address record'') зв'язує ім'я хоста з адресою протоколу IPv6. Наприклад, запит AAAA- запису на ім'я <tt>K.ROOT - SERVERS.NET</tt> поверне його IPv6 адреса - <tt>2001: 7fd::1</tt>
| + | |
| − | * '''Запис CNAME''' (''canonical name record'') або '''канонічний запис імені''' (псевдонім) використовується для перенаправлення на інше ім'я
| + | |
| − | * '''[[Запис MX]]''' (''mail exchange'') або '''поштовий обмінник''' вказує сервер(и) обміну поштою для цього домена.
| + | |
| − | * '''Запис NS''' (''name server'') вказує на DNS- сервер для цього домена.
| + | |
| − | * '''Запис PTR''' (''pointer'') або '''запис покажчика''' зв'язує IP хоста з його канонічним ім'ям. Запит в домені <tt>in - addr.arpa</tt> на IP хоста в reverse формі поверне ім'я(FQDN) цього хоста. Наприклад,(на момент написання), для IP адреси <tt>192.0.34.164</tt>: запит запису PTR <tt>164.34.0.192.in - addr.arpa</tt> поверне його канонічне ім'я <tt>referrals.icann.org</tt>. В цілях зменшення об'єму небажаної кореспонденції(спаму) багато серверів-одержувачів електронної пошти можуть перевіряти наявність PTR запису для хоста, з якого відбувається відправка. В цьому випадку PTR запис для IP адреси повинен відповідати імені відправляючого поштового сервера, яким він представляється в процесі SMTP сесії.
| + | |
| − | * '''Запис SOA''' (''Start of Authority'') або '''початковий запис зони''' вказує, на якому сервері зберігається еталонна інформація про цей домен, містить контактну інформацію особи, відповідальної за цю зону, ''тайминги'' (параметри часу) кеширования зонної інформації і взаємодії DNS- серверів.
| + | |
| − | * '''SRV- запис''' (''server selection'') вказує на сервери для сервісів, використовується, зокрема, для Jabber]] і Active Directory.
| + | |
| − | | + | |
| − | == Зарезервовані доменні імена ==
| + | |
| − | | + | |
| − | Документ RFC 2606(Reserved Top Level DNS Names - Зарезервовані імена доменів верхнього рівня) визначає назви доменів, які слід використати в якості прикладів(наприклад, в документації), а також для тестування. Окрім [[Домени другого рівня example.org, example.net і example.com|<code>example.com</code>, <code>example.org</code> і <code>example.net</code>]], до цієї групи також входять <code>test</code>, <code>invalid</code> та ін.
| + | |
| − | | + | |
| − | Простір імен DNS має структуру, зовні схожу на файлову систему Unix.
| + | |
| − | | + | |
| − | {|class="wikitable" width=300px align=right
| + | |
| − | ! Домен
| + | |
| − | ! Опис
| + | |
| − | |-
| + | |
| − | | '''''com'''''
| + | |
| − | | Комерційні організації
| + | |
| − | |-
| + | |
| − | | '''''edu'''''
| + | |
| − | | Учбові організації
| + | |
| − | |-
| + | |
| − | | '''''gov'''''
| + | |
| − | | Урядові організації США
| + | |
| − | |-
| + | |
| − | | '''''int'''''
| + | |
| − | | Міжнародні організації
| + | |
| − | |-
| + | |
| − | | '''''mil'''''
| + | |
| − | | Військові організації США
| + | |
| − | |-
| + | |
| − | | '''''net'''''
| + | |
| − | | Мережі
| + | |
| − | |-
| + | |
| − | | '''''org'''''
| + | |
| − | | Інші організації
| + | |
| − | |}
| + | |
| − | | + | |
| − | Кожен вузол має позначку довжиною до 63 символів. Корінь дерева це спеціальний вузол без позначки. Мітки можуть містити великі літери або маленькі. Ім'я домену ('''''domain name''''') для будь-якого вузла в дереві - це послідовність міток, яка починається з вузла виступає в ролі кореня, при цьому мітки розділяються крапками. Кожен вузол дерева повинен мати унікальне ім'я домену, проте однакові мітки можуть бути використані в різних точках дерева.
| + | |
| − | | + | |
| − | Ім'я домену, яке закінчується крапкою, називається абсолютним ім'ям домену ('''''absolute domain name''''') або повним ім'ям домену. Якщо ім'я домену не закінчується на крапку, мається на увазі, що ім'я має бути завершено. Як буде закінчено ім'я, залежить від використовуваного програмного забезпечення '''DNS'''. Якщо незакінчену ім'я складається з двох або більше позначок, його можна сприймати як закінчену чи повне; інакше праворуч від імені повинен бути доданий локальний суфікс.
| + | |
| − | | + | |
| − | Домени верхнього рівня поділені на три зони:
| + | |
| − | *'''''"''arpa''"''''' це спеціальний домен, використовуваний для зіставлення '''''адреса - ім'я'''''
| + | |
| − | *Сім 3-символьних доменів називаються загальними ('''''generic''''') доменами. У деяких публікаціях вони називаються організаційними ('''''organizational''''') доменами.
| + | |
| − | *Усі 2-символьні домени, засновані на кодах країн, можна знайти в '''''ISO 3166'''''. Вони називаються доменами країн ('''''country'''''), або географічними ('''''geographical''''') доменами.
| + | |
| − | | + | |
| − | | + | |
| − | ==DHCP==
| + | |
| − | | + | |
| − | '''DHCP''' (Dynamic Host Configuration Protocol — протокол динамічної конфігурації вузла) — це мережний протокол, що дозволяє комп'ютерам автоматично одержувати IP-адресу й інші параметри, необхідні для роботи в комп'ютерна мережа|мережі TCP/IP. Для цього комп'ютер звертається до спеціального серверу, під назвою сервер DHCP. Мережевий адміністратор може задати діапазон адрес, що розподіляють серед комп'ютерів. Це дозволяє уникнути ручного настроювання комп'ютерів мережі й зменшує кількість помилок. Протокол DHCP використовується в більшості великих мереж TCP/IP.
| + | |
| − | | + | |
| − | DHCP є розширенням протоколу BOOTP, що використовувався раніше для забезпечення бездискова робоча станція|бездискових робочих станцій IP-адресами при їхньому завантаженні. DHCP зберігає зворотну сумісність з BOOTP.
| + | |
| − | | + | |
| − | Стандарт протоколу DHCP був прийнятий у жовтні 1993 року. Остання версія протоколу березень 1997 року. Нова версія DHCP, призначена для використання в середовищі IPv6, зветься DHCPv6.
| + | |
| − | | + | |
| − | | + | |
| − | '''Способи розподілу IP-адрес'''
| + | |
| − | | + | |
| − | ----
| + | |
| − | '''''Ручний розподіл'''''.
| + | |
| − | При цьому способі мережевий адміністратор зіставляє апаратну адресу (для Ethernet мереж це MAC-адреса) кожного клієнтського комп'ютера певні IP-адресі. Фактично, даний спосіб розподілу адрес відрізняється від ручної настройки кожного комп'ютера лише тим, що відомості про адреси зберігаються централізовано (на сервері DHCP), і тому їх простіше змінювати при необхідності.
| + | |
| − | | + | |
| − | '''''Автоматичний розподіл'''''.
| + | |
| − | При даному способі кожного комп'ютера на постійне використання виділяється довільний вільний IP-адреса з визначеного адміністратором діапазону.
| + | |
| − | | + | |
| − | '''''Динамічний розподіл'''''.
| + | |
| − | Цей спосіб аналогічний автоматичного розподілу, за винятком того, що адреса видається комп'ютера не на постійне користування, а на певний термін. Це називається орендою адреси. Після закінчення терміну оренди IP-адреса знову вважається вільною, і клієнт зобов'язаний запитати нову (вона, втім, може виявитися тією же самою). Крім того, клієнт сам може відмовитися від отриманого адреси.
| + | |
| − | | + | |
| − | | + | |
| − | | + | |
| − | | + | |
| − | '''Етапи процесу отримання IP-адреси від DHCP-сервера'''
| + | |
| − | ----
| + | |
| − | 1. '''Виявлення DHCP'''
| + | |
| − | | + | |
| − | Спочатку клієнт виконує широкомовний запит по всій фізичної мережі з метою виявити доступні DHCP-сервери. Він відправляє повідомлення типу DHCPDISCOVER, при цьому в якості IP-адреси джерела вказується 0.0.0.0 (так як комп'ютер ще не має власного IP-адреси), а в якості адреси призначення - широкомовна адресу 255.255.255.255.
| + | |
| − | Клієнт заповнює кілька полів повідомлення початковими значеннями:
| + | |
| − | У полі xid поміщається унікальний ідентифікатор транзакції, який дозволяє відрізняти цей процес отримання IP-адреси від інших, що протікають в той же час.
| + | |
| − | У полі chaddr поміщається апаратна адреса (MAC-адресу) клієнта.
| + | |
| − | У поле опцій вказується останній відомий клієнту IP-адресу. У даному прикладі це 192.168.1.100. Це необов'язково і може бути проігноровано сервером.
| + | |
| − | Повідомлення DHCPDISCOVER може бути поширене за межі локальної фізичної мережі за допомогою спеціально налаштованих агентів ретрансляції DHCP, що перенаправляє надходять від клієнтів повідомлення DHCP серверів в інших підмережах.
| + | |
| − | | + | |
| − | 2. '''Пропозиція DHCP'''
| + | |
| − | | + | |
| − | Отримавши повідомлення від клієнта, сервер визначає необхідну конфігурацію клієнта згідно із зазначеними мережевим адміністратором настройками. В даному випадку DHCP-сервер згоден з замовленим клієнтом адресою 192.168.1.100. Сервер відправляє йому відповідь (DHCPOFFER), в якому пропонує конфігурацію. Пропонований клієнту IP-адреса вказується в полі yiaddr. Інші параметри (такі, як адреси маршрутизаторів і DNS-серверів) вказуються у вигляді опцій у відповідному полі.
| + | |
| − | Це повідомлення DHCP-сервер відправляє хосту, що відправив DHCPDISCOVER, на його MAC, за певних обставин повідомлення може поширюватися як широкомовна розсилка. Клієнт може отримати кілька різних пропозицій DHCP від різних серверів; з них він повинен вибрати те, що його «влаштовує».
| + | |
| − | | + | |
| − | 3. '''Запит DHCP'''
| + | |
| − | | + | |
| − | Вибравши одну з конфигурацій, запропонованих DHCP-серверами, клієнт відправляє запит DHCP (DHCPREQUEST). Він розсилається широкомовно; при цьому до опцій, вказаних клієнтом в повідомленні DHCPDISCOVER, додається спеціальна опція — ідентифікатор сервера — що вказує адресу DHCP-сервера, обраного клієнтом (в даному випадку — 192.168.1.1).
| + | |
| − | | + | |
| − | 4. '''Підтвердження DHCP'''
| + | |
| − | | + | |
| − | Нарешті, сервер підтверджує запит і відправляє це підтвердження (DHCPACK) клієнту. Після цього клінєт має налаштувати свій мережевий інтерфейс, використовуючи отримані опції.
| + | |
| − | | + | |
| − | | + | |
| − | === Структура повідомлень DHCP ===
| + | |
| − | ----
| + | |
| − | {| class="wide"
| + | |
| − | !Поле
| + | |
| − | !Опис
| + | |
| − | !Довжина (в [[байт]]ах)
| + | |
| − | |-
| + | |
| − | |'''op'''
| + | |
| − | |Тип повідомлення. Наприклад може приймати значення: BOOTREQUEST (1, запит від клєнта до сервера) и BOOTREPLY (2, відповідь від сервера клієнту).
| + | |
| − | |1
| + | |
| − | |-
| + | |
| − | |'''htype'''
| + | |
| − | |ти апаратної адреси. Допутстимі значення описані в [[RFC]] «Assigned Numbers». Наприклад, для [[MAC-адрес]]а [[Ethernet]] 10 Мбит/с це поле приймає значення 1.
| + | |
| − | |1
| + | |
| − | |-
| + | |
| − | |'''hlen'''
| + | |
| − | |Довжина апаратної адреси в байтах. Для [[MAC-адрес]]а [[Ethernet]] — 6.
| + | |
| − | |1
| + | |
| − | |-
| + | |
| − | |'''hops'''
| + | |
| − | |Кількість проміжних [[маршрутизатор]]ів (так званих ''агентів ретрансляції DHCP''), через які пройшло повідомлення. Клієнт встановлює це значення в 0.
| + | |
| − | |1
| + | |
| − | |-
| + | |
| − | |'''xid'''
| + | |
| − | |Унікальний ідентифікатор транзакцїх, генерований клєнтом на початку процесу отримання адреси.
| + | |
| − | |4
| + | |
| − | |-
| + | |
| − | |'''secs'''
| + | |
| − | |Час в секундах з початку процеса отримання адреси.
| + | |
| − | |2
| + | |
| − | |-
| + | |
| − | |'''flags'''
| + | |
| − | |Поле для прапорців — спецільних параметрів протокола DHCP.
| + | |
| − | |2
| + | |
| − | |-
| + | |
| − | |'''ciaddr'''
| + | |
| − | |IP-адреса клієнта. Заповнюється тільки в тому випадку, якщо клієнт вже має особисту IP-адресу і здатний відповідати на запити ARP.
| + | |
| − | |4
| + | |
| − | |-
| + | |
| − | |'''yiaddr'''
| + | |
| − | |Нова IP-адреса клієнта, запропонований сервером.
| + | |
| − | |4
| + | |
| − | |-
| + | |
| − | |'''siaddr'''
| + | |
| − | |IP-адреса сервера. Повертається в пропозиції DHCP (див. нижче).
| + | |
| − | |4
| + | |
| − | |-
| + | |
| − | |'''giaddr'''
| + | |
| − | |IP-адреса агента ретрансляції, якщо він приймав участь в процесі доставки повідомлення DHCP до сервера.
| + | |
| − | |4
| + | |
| − | |-
| + | |
| − | |'''chaddr'''
| + | |
| − | |Аппарата адреса (як правило, [[MAC-адрес]]) клієнта.
| + | |
| − | |16
| + | |
| − | |-
| + | |
| − | |'''sname'''
| + | |
| − | |Необов"язкове і"мя сервера у вигляді [[нуль-терминированная строка|нуль-терминированной строки]].
| + | |
| − | |64
| + | |
| − | |-
| + | |
| − | |'''file'''
| + | |
| − | |Необов"язкове ім"я файла на сервері, яке використовується при дистанційному завантаженні. Як і '''sname''', представлено у вигляді нуль-термінованого рядка.
| + | |
| − | |128
| + | |
| − | |-
| + | |
| − | |'''options'''
| + | |
| − | |Поле ''опції DHCP''. Тут вказуються різноманітні додаткові параметри конфігурації. На початку цього поля вказуються чотири особливих байта зі значеннями 99, 130, 83, 99, що дозволяють серверу визначити наявність цього поля. Поле мати змінну довжину, проте DHCP-клієнт повинен бути готовий прийняти повідомлення розміром 576 байт.
| + | |
| − | |змінна
| + | |
| − | |}
| + | |
| − | === Строк оренди IP-адреси === | + | |
| − | ----
| + | |
| − | DHCP присвоює IP-адреси на певний термін, "здає в оренду". По закінчення половини цього строку клієнт відправляє DHCP-серверу пряме сполучення із запитом про відновлення оренди. Якщо сервер доступний, він її продовжує. В іншому випадку клієнт знову посилає запит по витікання половини залишку інтервалу, і так далі. Якщо термін оренди 3 дні (72 години), то клієнт намагається відновити його через 36 год, 54 год і 63 ч. Нарешті, клієнт відправляє широкомовний запит до всіх DHCP-серверів. Якщо до закінчення терміну оренди клієнт не знаходить сервер, комп'ютер втрачає з'єднання з TCP / IP-мережею.
| + | |
| − | | + | |
| − | ===Переваги DHCP===
| + | |
| − | DHCP-сервер дає адміністратору ряд переваг. Головне - економія часу, що виникає за рахунок відмови від ручного конфігурування кожної машини. Нові комп'ютери часто поставляються з попередньо встановленою ОС. Якщо такий комп'ютер вже налаштований в якості DHCP-клієнта, ви можете підключити його до мережі, і йому відразу ж буде автоматично присвоєно IP-адресу. Якщо ні, то програма інсталяції NT при отриманні позитивної відповіді на відповідне питання сама сконфігурує систему, як DHCP-клієнт. Якщо ви привласнюєте IP-адреси вручну, вам необхідно зберігати список вже виданих адрес. Адміністратори нерідко носять такі списки з собою, тому що вони можуть знадобитися їм при конфігуруванні нових комп'ютерів. Якщо на підприємстві кілька адміністраторів, їм доводиться ще й координувати один з одним присвоєння адрес. DHCP знає, яким комп'ютерам які адреси привласнені. Адміністраторам більше не доведеться побоюватися друкарських помилок при введенні адрес і випадкового призначення одного й того ж адреси декількох комп'ютерів.
| + | |
| − | | + | |
| − | Первинне привласнення IP-адреси - не єдине, на чому економиться час. DHCP спрощує і інші адміністративні завдання. Зокрема, ви з легкістю зможете переміщати комп'ютер з однієї підмережі в іншу. При необхідності передати кому-небудь комп'ютер з нього можна буде попередньо скопіювати конфігураційні файли на інший. Якщо не користуватися DHCP, то обидва комп'ютери мали б в результаті один і той же IP-адресу. DHCP усуває цю проблему і скорочує кількість звернень в службу підтримки.
| + | |
| − | | + | |
| − | Є у DHCP переваги і для користувачів. Користувачі ноутбуків, наприклад, не зможуть підключитися до мережі, якщо адреси видаються вручну. Однак клієнти, які підтримують DHCP, по підключенні одразу ж отримують нові дійсні IP-адреси.
| + | |
| − | | + | |
| − | Крім того, DHCP дозволяє здійснювати спільне використання IP-адрес. Припустимо, у вас є 50 вільних адрес і відділ збуту зі штатом у 100 чоловік. Співробітники відділу проводять в офісі всього 1-2 дні на тиждень; таким чином, одночасно до мережі завжди підключені тільки 30-40 комп'ютерів. Кожного разу при підключенні до мережі співробітник отримує IP-адресу. Після відключення система відновлює адресу, щоб видати його наступному користувачеві.
| + | |
| − | | + | |
| − | Якщо ряд мобільних користувачів ділять між собою кілька IP-адрес, деяке їх кількість можна зарезервувати для тих, кому вони найбільше потрібні. Відкрийте діалог DHCP Manager, виберіть Scope, Add Reservations. Таким чином ви зможете зарезервувати адресу для комп'ютера з певним мережним адаптером. Це може створити труднощі, якщо користувачі поміняються адаптерами. Резервування має свої відмінності від присвоєння фіксованого IP-адреси. Резервування так само дає користувачеві можливість підключатися до мережі в різних відділах, але адреса в залежності від місця розташування може змінюватись.
| + | |
| − | | + | |
| − | | + | |
| | == [[Сторінка питань з DNS/DHCP]] == | | == [[Сторінка питань з DNS/DHCP]] == |
| | | | |
| | [[category:Комп'ютерні мережі]] | | [[category:Комп'ютерні мережі]] |
