Протокольний стек TCP/IP

6.1. Структура мережі протоколу TCP/IP
6.2. Адресація в мережах протоколу TCP/IP
6.3. Структура протокольного стека TCP/IP
6.4. Формат ІР-пакета
Поняття протокольного стека. Протокольний стек TCP/IP, його загальна характеристика. Структура мережі TCP/IP. Адресація. Головні протоколи стека. Формат IP-пакета. Маршрутизація в мережах TCP/IP.
У попередніх розділах ми розглянули функції та призначення протоколів усіх рівнів згідно з еталонною моделлю взаємодії відкритих систем. У реальних мережах часто застосовують цілі набори протоколів, які підтримують усі рівні взаємодії.
Конкретне застосування набору протоколів називають протокольним стеком.
Найбільшого поширення сьогодні набув протокольний стек TCP/IP, який використовують у мережах ОС UNIX та Internet.
Набір протоколів TCP/IP застосовують у мережах на базі ОС UNIX, а також у популярній глобальній мережі Internet. Розробку та супровід цих протоколів виконує ІАВ (Internet ActiviBoard) з двома підкомітетами: дослідницьким (Internet Research Task Force (IRTF)) та інже-нерним (Internet Engineering Task Force (IETF)). Інженерний підкомітет також розробляє стандарти мережі TCP/IP - RFC (Request For Comments). Крім того, Internet має структуру, що відповідає за розподіл адрес - ICANN (Internet Corporation for Assigned Names and Numbers). Ця організація координує роботу регіональних організацій з аналогічними функціями - ARIN - Америка, RIPE — Європа, APNIC - Азія. Детальніше про стандартизацію Internet див. Д. 10.2.
6.1. Структура мережі протоколу TCP/IP;
Структура мережі TCP/IP - це об'єднання локальних мереж (звідси назва Internet, що дослівно означає міжмережеву мережу) (рис. 10.1). Окремі локальні мережі сполучені через маршрутизатори. Кожна мережа має унікальну адресу. Комп'ютери в локальній мережі називають гостами (host). Вони також мають унікальні адреси.
Оскільки мережа протоколу TCP/IP об'єднує кілька локальних мереж, то в англійській термінології з називають internet. (Hа відміну від всесвітньовідомої глобальної мережі Internet, яка використовує протоколи TCP/IP і є сукупністю інформаційних ресурсів). Велику корпоративну мережу, побудовану за принципами та на програмному забезпеченні internet, називають intranet, а таку ж корпоративну мережу, однак з великим ступенем взаємодії з зовнішніми мережами, - extranet.
6.2. Адресація в мережах протоколу TCP/IP
У кожній мережі на кожному рівні протоколу є свій механізм адресації. Наприклад, у мережі Ethernet на канальному рівні адресу задають унікальним шестибайтовим числовим значенням (наприклад 08-00014-57-69-69). IP-адреса (тобто адреса IP-протоколу мережевого рівня) вузла також є унікальною логічною адресою і не залежить від апаратури та конфігурації мережі, її довжина становить 4 байти. Для зручності та наочності цю адресу розділяють на чотири частини, відокремлені крапками, наприклад, 102.54.94.97. Адресою транспортного рівня є номер порту, що відповідає застосуванню, якому адресовано IP-пакет. Номер порту задають цілим числом (див. Д. 10.11). Інколи IP-адресу поєднують з номером порту. Таку адресу, наприклад 102.54.94.97:8080, називають сокетом (socket).
Кожна IP-адреса складається з двох компонентів: адреси локальної мережі та адреси госта. Межа між адресами локальної мережі та госта рухома. Адреса мережі може займати З, 6, 9 розрядів. Решта - це адреса госта в мережі.
Отже, адреси всіх гостів в одній локальній мережі відрізняються тільки в частині 'адреса госта'.
Для зручності адресації мереж різних розмірів їх розділено на класи (табл. 10.1, рис. 10.2).
Адреси з номером мережі 127 зарезервовані для тестової перевірки наявності зв'язку з собою (loopback) та перевірки функціювання міжпроцесних зв'язків. Адреси мереж з номерами 224 і більше призначені для спеціальних протоколів, їх не можна використовувати для адрес станцій. Адреси з усіма нулями часто інтерпретовані як адреси мережі та госта, на консолі якого виводяться ці адреси. Адреси ж з усіма одиницями адресують усі гости мережі одночасно.
Схемою адресації TCP/IP передбачено передавання групових та циркулярних повідомлень. Групові повідомлення (Multicast Messages) передають згідно з адресою класу D всім
гостам певної групи за допомогою протоколу IGMP (Internet Group Management Protocol) (див. Д. 10.1). Інформація про станції-члени груп є в таблицях маршрутизаторів. Циркулярні пові-домлення (Broadcast Messages) надходять до всіх станцій локальної мережі.
Для зручності користувачів кожна станція мережі, крім IP-адреси, має і своє унікальне в межах конкретної мережі символьне ім'я (DNS-ім'я), яке складається з імен комп'ютера та домену (ширшої зони, яка відповідає організації, країні або типу організації, до якої належить мережа). Наприклад, ім'я х.acme.com визначає комп'ютер з назвою х у локальній мережі фірми acme, що є комерційною організацією.
Для взаємно-однозначного відображення між числовим форматом IP-адреси та його символьним зображенням у мережі TCP/IP може діяти служба імен DNS (Domain Name System). Про DNS та інші служби імен див. Д.10.2, Д. JO.3.
Довжина IP-адреси (4 байти) та пов'язане з цим обмеження кількості мереж сьогодні не дають змоги мережі Internet зростати. Тому розроблено декілька пропозицій щодо зменшення дефіциту IP-адрес (див. Д.10.4, Д.10.5).
Для зручності визначення адреси локальної мережі за IP-адресою ввели поняття маски мережі. Маска мережі - це чотирибайтове число, за формою запису подібне до ІР-адреси. Розрядам, що описують мережу, відповідають біти ‘1’ маски, а розрядам адреси госта – ‘0’. Наприклад, для адреси 192.168.45.1 маска мережі могла б бути 255.255.255.0. Іншим застосуванням масок мереж є поділ великих мереж на менші підмережі з метою ефективнішого використання адресного простору.
Останнім часом для підвищення ефективності маніпулювання мережевими адресами у структурі мережевої IP-адреси виділяють дві частини: розширеного мережевого префікса та номера госта. Замість традиційного позначення маски підмережі просто зазначають довжину мережевого префікса, наприклад: 192.20.130.1/24, де довжина префікса - 24 біти. Це означає.
що адреса мережі займає перші 24 біти, а решта - це адреса госта. Адреси мереж рекомендують будувати так, щоб найшвидше збільшувалися крайні ліві розряди, а адреси пристроїв - щоб зростали крайні праві розряди.
RFC 1009 дає змогу використовувати маски підмереж змінної довжини у великій корпоративній мережі, де є багато різних підмереж. Таку маску підтримують протоколи маршрутизації OSPF та IS-IS.
У RFC 1517, 1518, 1519, 1520 відображена концепція безкласової міждоменної маршрутизації (Classless Inter-Domain Routing (CIDR)), що полягає у відмові від адрес класів мереж. Адресу розглядають як поєднання IP-адреси та розширеного мережевого префікса. Це дало змогу зменшити дефіцит адрес та кількість записів про маршрути. CIDR дає змогу об'єднувати маршрути - одним записом задавати багато адрес.
6.3. Структура протокольного стека TCP/IP
Розглянемо структуру протокольного стека TCP/IP (рис. 10.3) та коротко схарактеризуємо
На канальному рівні використовують протоколи відомих мережевих архітектур (Ethernet, FDDI, ATM, Token Ring та ін.). Особливе місце посідають протоколи SLIP (Serial Line IP) та PPP (Point-to-Point Protocol). їх застосовують для передавання даних низькочастотними послідовними каналами, найчастіше через послідовний порт комп'ютера та модем призначеною або комутованою телефонною лінією (див. Д.10.6).
IP (Internet Protocol) - це міжмережевий данограмний протокол мережевого рівня, що забезпечує сервіс передавання пакетів між вузлами мережі. Він не підтримує функції послідовного передавання пакетів та не гарантує надійності їхнього передавання. IP є головним протоколом мережевого рівня стека TCP/IP. Його використовують усі інші протоколи.
ІСМР (Internet Control Message Protocol) — це головний діагностичний протокол для передавання інформації між вузлами мережі про помилки та збої, а також для діагностування мережі. Крім того, протоколи вищих рівнів використовують його для адміністрування та діагностування мережі (див. Д. 10.7).
ARP (Address Resolution Protocol) трансформує IP-адресу в МАС-адресу станції (див. Д. 10.8), а протокол RARP (Reverse Address Resolution Protocol) виконує зворотну функцію - за МАС-адресами визначає логічні IP-адреси (Д.10.9).
TCP (Tramsmission Control Protocol) є протоколом транспортного рівня з попереднім налагодженням сполучення. Він гарантує надійне передавання пакетів та забезпечує їхню пра-вильну послідовність, під час передавання використовує сервіс протоколу IP (див. Д.10.10).
UDP (User Datagram Protocol) - данограмний протокол транспортного рівня, який вико-ристовують замість протоколу TCP, якщо немає потреби в додаткових заходах з забезпечення надійного передавання. Протокол не гарантує передавання пакета, а також послідовності пере-давання (див. Д. 10.11).
Серед протоколів прикладного рівня та рівня відображення можна виділити Telnet -протокол емуляції термінала, FTP (File Transfer Protocol) - протокол передавання файлів, SMTP (Simple Mail Transfer Protocol) - протокол електронної пошти (див. Розділ 26), SNMP (Simple Network Management Protocol) - протокол керування мережею (див. Розділ 18), HTTP -(HyperText Transport Protocol) - протокол для передавання гіпертекстової інформації в internet (Д.10.12).
Протоколи стека TCP/IP не пристосовані для передавання ізохронних інформаційних потоків, які широко використовують сучасні застосування мультимедіа. Вчені запропонували декілька протоколів, призначених для опрацювання ізохронних потоків (Д. 10.13).
6.4. Формат ІР-пакета
IP-пакет складається з заголовка, який переносить службову інформацію, та блока даних. Його формат (RFC-791) показано на рис. 10.4.
Формат заголовка зображено на рис. 10.5. Як бачимо, заголовок складається з окремих полів. Розшифруємо їхнє призначення детальніше.
VERS - номер версії протоколу IP. Його використовують для вирішення конфліктів у випадках, якщо станції працюють з різними версіями протоколу IP. Це єдине незмінне поле у форматі пакета.
SERVICE TYPE- байт, який визначає параметри обслуговування пакета. Біти 0—2 у ньому задають пріоритет пакета, біти 3-6 - бажаний тип якості транспортування (Delay, Throughput, Reliability, Cost). Значення пріоритету змінюються від 0 (найнижчий, звичайні повідомлення) до 7 (найвищий, мережеве керування). Тип якості транспортування враховують багато маршру-тизаторів. У цьому випадку вони намагаються мінімізувати (максимізувати) відповідний пара-метр. Одночасно можна задати тільки один з бітів якості. Значення за замовчуванням - усі нулі. Кожна з програм рівня застосувань може ставити свої вимоги до якості передавання. Наприклад, для програми емулятора термінала telnet важливим є час відповіді, а для протоколу мережевого керування SNMP - надійність доставляння.
TOTAL LENGTH — загальна довжина пакета в байтах. Максимальне значення цього поля - 65 535 байт.
IDENTIFICATION - ідентифікатор "великого" пакета, один для всіх його фрагментів. Окремий фрагмент визначають унікально за адресами відправника та одержувача, протоколом вищого рівня та ідентифікатором.
Під час передавання по internet IP-пакет проходить через багато коми 'ютерних систем, колена з яких має обмеження — максимальний розмір кадру (Maximum Transfer Unit (MTU)). Тому, щоб передати інформацію у систему з меншим розміром кадру, великі , h пакети доводиться розділяти на менші, а потім знову об 'єднувати їх. Оскільки деякі апаратні пристрої не можуть правильно фрагментувати та дефрагментувати пакети, то у мережі TCP/IP виникають збої. Стандарти передбачають, щоби всі маршрутизатори працювали з пакетом довжини не менше 576 байт. Є технологія MTU Discovery, яка дає змогу перед передаванням виявити всі обмеження MTU. В цьому випадку відправник може заборонити фрагментацію (у полі Flags перший біт дозволяє фрагментацію (0) або забороняє її (1). Останній біт =7 означає останній фрагмент пакета). Зазначимо, що маршрутизатори тільки фрагментують пакети, а не збирають їх. Збирання виконує одержувач.
FLAGS - ознака того, що пакет фрагментовано.
FRAGMENT OFFSET - зміщення від початку фрагментованого пакета.
TIME TO LIVE— час перебування пакета в мережі. Введення такого параметра дає змогу уникнути необмеженого в часі перебування пакета в мережі. Для цього під час формування пакета йому присвоюють конкретний час. Пізніше під час кожного опрацювання пакета в марш-рутизаторі час зменшується. Коли значення поля досягне 0, пакет буде знищено. На практиці замість часу перебування часто використовують ціле число - максимальну кількість транзитних маршрутизаторів і в разі кожного опрацювання пакета зменшують його на 1.
PROTOCOL - протокол транспортного рівня, до якого спрямований пакет (TCP, UDP, ІСМР, IGMP).
HEADER CHECKSUM - контрольна сума (КС), яка захищає заголовок пакета. Оскільки деякі поля змінює кожен маршрутизатор, то КС доводиться щоразу переобчислювати. Це, та ще заповнення поля опцій є суттєвим джерелом затримки.
SOURCE IP ADRESS - адреса джерела інформації.
DESTINATION IP ADDRESS- адреса призначення.
ID OPTIONS - необов'язкові параметри, пов'язані з режимами безпеки та маршрутизацією (детальніше див. Д. 10.14).
PADDING -заповнення пропусками до цілого числа 32-бітових слів.
10.5. Маршрутизація в мережах TCP/IP
Як уже зазначено, мережа TCP/IP складається з локальних мереж, сполучених маршрутизаторами (рис. 10.6). У маршрутизаторах є інформація про локальні мережі, приєднані до internet.
Кожен гост мережі може підтримувати статичну маршрутизацію. Для цього він має спеціальний файл, у якому зазначено маршрут передавання пакета для конкретних адрес призна-чення. Під час підготовки пакета до передавання в його заголовок записують адреси джерела та призначення. Якщо адреси локальних мереж у них збігаються, то передавання пакета відбувається в межах цієї ЛМ, в іншому випадку виконується перевіряння файлу статичної маршру-тизації на гості. Якщо ж і тут маршруту з'ясувати не вдалося, то пакет переходить на розташовану у тій же ЛМ станцію, адреса якої в параметрах конфігурації госта записана як шлюз за замовчуванням (Default gateway). Таким шлюзом (фактично маршрутизатором) є комп'ютер, де зберігаються таблиці, за допомогою яких, якщо відома адреса призначення пакета, визнача-ють адресу наступного маршрутизатора або локальної мережі. Шлюз спрямовує отриманий пакет на визначену таким чином адресу.
У файлі конфігурації станції можна задати декілька адрес маршрутизаторів за замовчуванням. Якщо один з них не працює, то станція звертається до іншого.
Важливим у маршрутизації є поняття автономної системи. Автономна система (АС) -це комплекс з однієї або кількох мереж, сполучених маршрутизаторами, у якому підтримується
єдиний тип маршрутизації. Маршрутизацію всередині АС називають внутрішньою, а з виходом назовні — зовнішньою. Маршрутизатори АС мають повні маршрутні таблиці для внутрішньої маршрутизації. Якщо ж пакет потрібно передати у зовнішню систему, то його надсилають так званому граничному маршрутизатору (Border Gateway). Звичайно він розташований на межі автономної системи, і його таблиці містять інформацію як про мережі АС, так і про зовнішні мережі. Використання граничних маршрутизаторов дає змогу зменшити розміри таблиць внутрішніх маршрутизаторів і підвищити ефективність їхньої роботи. Складні АС можна поділяти на області, сполучені граничними маршрутизаторами. Використання АС дає змогу застосо-вувати принцип обмеження потоку, реалізований у ЛМ для їхнього об'єднання.
Протоколи маршрутизації бувають статичними та динамічними. У статичних протоколах зміни робить адміністратор мережі, у динамічних це відбувається автоматично.
Детальніше проблеми маршрутизації в мережах TCP/IP, а також протоколи внутрішньої (RIP, OSPF) та зовнішньої (BGP) маршрутизації описано в Д.10.15—Д.10.18.
Підтримка роботи груп (протокол IGMP)
У мережах протокольного стека TCP/IP у деяких випадках потрібно реалізувати груповий (multicast) режим передавання. Цю проблему вирішують за допомогою протоколу IGMP (базового, на рівні локальної мережі) та протоколів DVMRP, MOSPF, РІМ для міжмережевих передавань. .
Передумови реалізації режиму групового передавання:
певна кількість IP-адрес (від 224.0.0.0 до 239.255.255.255) виділена спеціально для адресування груп; групова адреса складається з префікса 1110 та ідентифікатора групи; виділяє групові мережеві адреси ЙБНБ (Internet Assigned Numbers Authority);
групову адресацію можна реалізувати і на канальному рівні (наприклад, Ethernet та FDDI її підтримують); для підтримки групового передавання IANA має блок Ethernet-адрес, який починається з 01-00-5Е. Під час передавання протокольних блоків між рівнями відбувається копіювання молодших 23 бітів IP-адреси у хвіст Ethernet-адреси.
У випадку передавання в межах однієї локальної мережі адаптер трансформує групову IP-адресу у групову Ethernet-адресу.
Протокол IGMP регламентує обмін між гостом та маршрутизатором локальної мережі. Якщо до мережі приєднано кілька маршрутизаторів, то один з них (що має менший номер -IGMP v2 ) стає головним.
IGMP має кілька версій. Базовою є RFC-1112. Згідно з нею маршрутизатор періодично генерує циркулярні повідомлення HMQ (Host Membership Query) з адресою призначення 224.0.0.1 і полем TTL=1. (Отже, цей пакет не може вийти за межі ЛМ). Якщо гост отримав HMQ, він відповідає пакетом HMR (Host Membership Report) для кожної групи, членом якої він є. У цьому разі гост аналізує появу аналогічних повідомлень від інших гостів його групи та відкладає передавання. Таким способом відбувається регулювання потоків. Пакети IGMP передаються всередині IP-пакета. Формат IGMP-пакета показано на рис. Д. 10.1.
Для підтримки діяльності групи маршрутизатор повинен отримати повідомлення тільки одного госта групи. Маршрутизатор не підтримує списку гостів груп. Якщо відповіді на декілька запитів HMQ немає, то група буде вилучена зі списку маршрутизатора. Якщо ж гост хоче стати членом якоїсь групи, то він надсилає HMR зі своєї ініціативи. Таким способом відбувається реєстрування групи, якщо гост перший у ній. Якщо групове передавання треба реалізувати в межах internet-мережі, то використовують протоколи DVMRP, MOSPF, РІМ. У цьому разі може бути реалізоване радіальне розсилання або алгоритми побудови залишкових дерев (подібно до тих, що реалізовані в роботі комутаторів, див. Розділ 16).
Служба імен DNS
Адресу госта мережі internet, як уже зазначено, можна записати за допомогою цифр, а також і літерами, що надає їй змістовності, поліпшує запам'ятовування та опрацювання людьми.
У системі DNS реалізовано дві ідеї: ієрархію імен гостів та розподілення відповідальності щодо адміністрування. Ця система описана у стандартах RFC 882, 883, 1034, 1035,1101, 1183. Першу версію DNS створено 1983 p., роботи з удосконалення DNS тривають.
Системи іменування мережевих об'єктів поділяють на пласкі та ієрархічні. У пласких системах кожен комп'ютер має текстовий файл (наприклад, /etc/hosts), у якому символьні імена відповідають цифровим IP-адресам. Ідентичні копії такого файлу повинні бути на всіх гостах локальної мережі. Однак зі збільшенням мереж узгоджувати текстові файли стало важче.
DNS є ієрархічною системою іменування. Складові її частини такі:
деревоподібна ієрархія найменуваньгостів; ·
розподілена база даних з інформацією про комп'ютери;
бібліотечні процедури роботи з цією інформацією;
протокол обміну інформацією з базою даних;*
програми та файли налаштувань. Головною структурною одиницею у DNS є домен. Домени побудовані у вигляді ієрархічного дерева (рис. Д.10.2), у вершині якого є кореневий домен '.'. Домени першого рівня відповідають типам організацій або країнам, наприклад, com - комерційні, int - міжнародні, mil -військові, net-мережеві агентства та постачальники послуг (провайдери), de -Німеччина, иа - Україна.
Довільний домен або гост характеризований повним доменним ім'ям (Fully Qualified Domain Name (FQDN)). Окремі частини імені відділені крапкою. Наприклад, для госта host! ім'я буде таке:
host1.firm1.kyiv.ua.
Ознакою повного доменного імені (та наявності кореневого домена) є остання крапка.
Адресація за повним доменним ім'ям є абсолютною доменною адресацією. Крім абсолютної, використовують і відносну доменну адресацію, зокрема, якщо звертаються до комп'ютера в межах одного "старшого" домену. Наприклад, hostl може звертатися до host2 за адресою host2. У відносній доменній адресі немає кінцевої крапки і вона автоматично доповнюється до абсолютної адреси додаванням адреси "старшого" домену. В деяких реалізаціях протоколу TCP/IP вважають: якщо в адресі більше одної позначки доменів, то це абсолютна адреса.
В іменах доменів не враховано регістру. Домени верхнього рівня - edu, gov, mil, net, org. Імена доменів другого рівня видають спеціалізовані організації, вони ж гарантують їхню уні-кальність. За домени нижчих рівнів відповідають їхні адміністратори. Обмеження: імена доменів повинні бути унікальними в межах старшого домену, їхня довжина не перевищує 12 символів, недопустиме повторення частини імені домену. У заявці зазначають відповідального спеціаліста, імена та адреси двох комп'ютерів, на яких буде зберігатися БД домену.
DNS - це розподілена база даних, окремі частини якої зберігаються на комп'ютерах -серверах імен. У кожному сервері є інформація тільки про частину загального дерева DNS, a також обов'язково посилання на сервери імен, що зберігають інформацію про суміжні частини цього дерева. Сервер імен, як звичайно, відповідає не за один домен, а за декілька суміжних, або їхні частини - так звану зону відповідальності (zone of authority). Зона - це домен без піддоменів.
Програму, яка відповідає на запити DNS, називають сервером імен, а клієнта - визнач-ником. Сервери імен бувають
головними,
допоміжними,
кешування.
Сервери імен обслуговують зону. В кожній зоні є один головний сервер імен. Він зберігає головний варіант БД цього домену. Відповідь головного сервера імен є "авторитетною", тобто точною. У кожному домені обов'язково повинен бути хоч би один допоміжний сервер, який періодично копіює свої дані з головного сервера, узгоджує та актуалізує свої таблиці. Для узгодження даних використовують так звані зонні пересилання. Сервер кешування отримує адреси деяких серверів DNS вищого рівня у своєму файлі конфігурації. Свою БД цей сервер формує за результатами поточних запитів, зберігаючи їх у кеші.
Головним сервером звичайно роблять надійну, не дуже перевантажену машину, приєднану через UPS. Головний та допоміжні сервери часто розміщують у різних доменах і різних мережах електричного живлення з метою зменшити ймовірність їхнього одночасного виходу з ладу.
У кожній зоні може бути визначено декілька типів серверів DNS:
первинний сервер імен (Primary Name Server) є центральним сховищем інформації про домен;
вторинний сервер імен (Secondary Name Server) зберігає копію інформації з первинного сервера, розвантажуючи його. Копії періодично узгоджуються;*
сервери для кешування (Cache only Server) зберігають кешовану інформацію, щоб зменшити навантаження на сервери.
У кожному домені для гарантування надійності повинно бути принаймні два сервери (первинний та вторинний).
Інформація, в тому числі й отримана від інших серверів DNS, зберігається у кеш-пам'яті. Визначено максимальний час зберігання інформації у кеші і, отже, періоди оновлення інформації з первинного сервера. Всі зміни спочатку відбуваються на первинному сервері. На інших сер-верах нова інформація буде врахована внаслідок нового читання після її вилучення з кешу.
Залежно від порядку обслуговування запитів клієнтів сервери DNS бувають рекурсивними або нерекурсивними. Нерекурсивний сервер шукає відповідь у своєму кеші або своїй БД. Якщо відповідь не знайдено, то відбувається відсилання адреси авторитетному серверу іншого домену, який повинен знати відповідь.
Під час роботи рекурсивного сервера в його кеші накопичуються результати проміжних запитів, які можуть бути використані для опрацювання наступних запитів. Сервери нижчих рівнів звичайно рекурсивні, а сервери першого і частково другого - нерекурсивні (щоб не перевантажувати їх запитами, а їхній кеш - інформацією). Відсилання генеровані за ієрархічним принципом. Наприклад, якщо сервер не знає адреси dom.isc.arizona.edu, то він послідовно буде звертатися до доменів isc.arizona.edu, arizona.edu, edu, кореневого. Як звичайно, сервер знає щонайменше адресу сервера кореневого домену зі своїх файлів конфігурування.
Приклад. Визначити адресу госта lion.cf.iton.edu. Нехай адреса вашого сервера імен dn.isc.arizona.edu.
Запит надходить на локальний сервер імен dn.isc.arizona.edu. Він не знаходить потрібної адреси і з огляду на рекурсивність звертається до серверів доменів arizona.edu та edu. Ці сервери нерекурсивні, і сервер edu надсилає на сервер адресу домену iton.edu. Це дає змогу нашому серверу звернутися до нього. Сервер iton.edu. також рекурсивний; він звертається до відомого йому сервера домену cf.iton.edu та отримує адресу госта lion. Ця адреса повертається до клієнта.
Після виконання описаних операцій *
у кеші dn.isc.arizona.edu буде адреса госта ІІОП;
у кеші dn.isc.arizona.edu буде адреса сервера iton.edu;
сервер iton.edu збереже адресу cepBepaCf.iton.edu.
Якщо наявний файл конфігурування DNS, то шукання імен спочатку відбувається на серверах DNS, а якщо їх там не знайдено, то у файлі hosts. Для збільшення швидкості роботи ліпше звертатися до абонента безпосередньо за ІР-адресою.
Програму, яка виконує функції DNS на ПК клієнта, називають клієнтом DNS. Клієнт також може взаємодіяти з сервером DNS у нерекурсивному або рекурсивному режимах.
Нехай клієнт звертається з запитом до сервера DNS щодо визначення IP-адреси. Якщо сервер відшукає потрібну інформацію у власній зоні або в кешованих даних, переданих іншими серверами, то він надсилає відшукану адресу. Якщо адреси не виявлено, то сервер надсилає адресу сервера DNS, що розміщений ближче до домену, стосовно якого сформовано запит. Клієнт DNS сам зробить запит до цього домену. Такий порядок роботи називають нерекур-сивним. У рекурсивному режимі запит до іншого сервера DNS виконує не клієнт, а сервер DNS, який одержав запит клієнта.
Найчастіше використовують нерекурсивний режим, оскільки в цьому разі менше завантажений сервер DNS, а також можна ліпше простежити за проходженням запитів.
Налаштування DNS зберігаються у файлах/etc/resolv.conf (UNIX), etc\resolv.cfg (DOS), sys:etc\resolv.cfg (Netware), ay WNTTaW95, 98-уреєстрі.
Формат файлу resolv.conf:
domain firm1.kyiv.ua
name_s1 143.150.180.1
name_s2 143.150.180.4
Кількість рядків - не більше трьох. Звичайно першим зазначають вторинний сервер, потім первинний (для розвантаження).
База даних DNS — це набір текстових файлів, які створює та супроводжує адміністратор. Ця база даних складається з записів різних типів (RFC 882, 1035, 1183). Формат запису:
[назва] [час] [клас] тип дані,
де назва - ім'я комп'ютера або домену, для якого визначено цей запис. Якщо група записів має однакові імена, то всі імена, починаючи з другого, можна пропустити. Можна використовувати як повністю, так і неповністю визначені імена. До неповністю визначених імен додають ім'я локального домену;
час — час, протягом якого запис можна тримати у кеші;
клас - тип мережі, де діє служба. За замовчуванням приймають IN (Internet);
тип — тип запису, що характеризує його призначення;
дані - список параметрів, формат яких окремий для кожного типу запису.
Усі записи умовно розділяють на три групи:
зонні записи. Визначають домени, їхні сервери, а також межі дії наступних записів;
головні записи. Ці записи зіставляють імена та адреси, а також перемаршрутизовують
додаткові записи. Містять додаткову інформацію.
У файлі БД, як звичайно, спочатку записують зонні записи, а потім інші. У цьому разі їхній порядок можє бути довільним.
Зонні записи
Запис SOA визначає параметри зони. Зонний запис діє доти, доки у файлі не виявлено запису для іншої зони. Параметри запису найліпше розглянути на такому прикладі:
@ IN SOA ns.cs.colorado.edu admin.cs.colorado.edu
1001 ;Serial
21600 ;Refresh, 6 hours
1800 ;Retry, 30 min
1209600 ;Expire, 2 weeks
432000 ;Minimum 5 days
Символ @ використовують для скороченого позначення поточної зони. Поле ns.cs.colorado.edu визначає ім'я головного сервера імен зони. Поле admin.cs.colorado.edu - це адреса електронної пошти у форматі користувач.ім'я домену. Поле Serial ідентифікує номер версії файлу БД. З кожним оновленням файлу це число повинно збільшуватися. Часто як таке число використовують дату модифікації. Цей номер керує оновленням інформації на допоміжних серверах. Поле Refresh - це інтервал оновлення даних допоміжними серверами. Поле Retry задає період поновного звертання допоміжного сервера до головного, якщо попередня спроба не була успішною. Поле Expire визначає час, протягом якого допоміжні сервери будуть обслуговувати домен у разі недоступності головного сервера. Поле Minimum визначає час чинності записів. Зі збільшенням цього часу зменшується навантаження на систему DNS, однак збільшується час опрацювання змін у конфігурації.
Запис NS. Ці записи визначають головні та допоміжні сервери зони. Як звичайно, вони йдуть після записів SOA. Формат запису:
[Зона] [час] [клас] NS ім'я_госта
Поле Зона є необов'язковим і може бути відчитане з попереднього запису SOA.
Приклад:
cf.iton.edu. IN NS ns1.cf.iton.edu.
cf.iton.edu. IN NS ns2. cf.iton.edu.
cf.iton.edu. IN NS add_s. cf.iton.edu.
У записах зазначають тільки головні та допоміжні (авторитетні) сервери. Водночас тип сервера не специфікований. Записи типу NS фактично не використовують у межах локальної зони. Однак вони визначають сервери імен для зовнішніх користувачів. Зовнішні користувачі можуть бачити тільки сервери імен, специфіковані в NS. Бувають також внутрішні сервери, приховані від зовнішнього світу.
Головні записи
Запис А використовують для перетворення імені (доменної адреси) машини в ІР-адресу.
Наприклад:
Lion IN A 196.168.2.1
Неповне ім'я доповнюють іменем локального домену.
Запис PTR призначено для перетворення IP-адреси в доменне ім'я госта. Щодо цього запис PTR виконує протилежну до запису А функцію.
Значна кількість програм користується сервісом PTR. Як звичайно, вони отримують з мережі деяку IP-адресу і повинні знайти відповідне їй ім'я для порівняння зі списками імен у своїх файлах конфігурації. До таких програм належать netstat, sendmail, syslog, XWindow, ftp, finger, rlogind та ін.
Формат запису:
адреса [час] [клас] PTR ім'я_госта
Форма наведення адреси госта в цьому запису неординарна. Адресу записують справа наліво. У кінці адреси не ставлять крапки. Наприклад, адресу 192.168.2.1 буде записано так: 1.2.168.192
Це роблять з метою використання як для прямого, так і для зворотного перетворень одного програмного модуля. У разі прямого перетворення доменне ім'я починається з найменш значущої частини. Тому і для зворотного перетворення потрібно починати адресу з найменш значущої частини.
Такий підхід зумовлює додаткові ускладнення. Відомо таке: якщо доменне ім'я наведене у скороченому вигляді, то перед звертанням до DNS воно буде доповнене ім'ям локального домену. Адреса у записі PTR з формального погляду також неповна і повинна бути доповнена. Для цього ввели позначення спеціального фіктивного домену NNN.IN-ADDR.ARPA, де ННН - перший байт IP-адреси. Отже, у нашому прикладі повне доменне ім'я буде виглядати 1.2.168.192.IN-ADDR.ARPA. Як звичайно, інформація про ім'я поточної зони єдина на кожну зону. Тому для заведення записів PTR потрібно вводити додаткову зону NNN.IN-ADDR.ARPA, створювати для неї весь набір записів (SOA, NS, PTR). Ще один набір записів доводиться створювати для зони локального госта 127.IN-ADDR.ARPA.
Між записами А та PTR повинна бути повна однозначна відповідність.
Запис MX призначено для переадресування електронної пошти. Формат запису:
ім'я_адресата [час] [клас] MX пріоритет ім'я_переспрямування
Пріоритет записують цілим числом від 0 до 65535. Повідомлення спрямовують у першу чергу відповідно до записів з меншим пріоритетом.
Приклад використання записів формату MX:
NWC.COM MX 10 NTAS
MX 21 SPARCI
NTAS MX 10 NTAS
MX 20 SPARCI
SPARCI MX 10 SPARCI
MX 20 NTAS
Тут наведено три машини nwc.com, ntas, sparci. Записи з вищим пріоритетом 10 задають поштовий сервер за замовчуванням. Якщо цей сервер недоступний, то пошта надходить на сервер з меншим пріоритетом.
Додаткові записи
Запис CNAME дає змогу визначати для гостів мнемонічні імена, використовувати декілька варіантів імен для одного госта.
Запис HINFO відображає виробника та модель комп'ютера. Запис WKS визначає сервісні програми, які пропонує гост. Запис ТХТ. Довільний текст.
Головне призначення служби імен DNS - це надання IP-адрес на підставі символьного доменного імені госта. Для невеликих мереж це завдання вирішують з використанням текстового файлу hosts або Imhosts на кожній робочій станції.
Фактично DNS має значно більші можливості, ніж просте відображення адрес. DNS -це база даних про стан госта, яка є прообразом служби каталогів мережі, хоч і не містить усіх потрібних у службі каталогів функцій.
Програмна реалізація. Систему DNS називають ще й BIND (Berkeley Internet Name Domain). Ця назва склалася історично та відображає місце створення системи.
Сервер імен. Демон сервера імен називають named. Для виконання перетворення імен звертаються до бібліотечних функцій gethostbyname та gethostbyaddr. Крім програми-демона, сервер імен може мати низку конфігураційних текстових файлів. Це такі файли:
файл початкового завантаження;
кеш-файл;
файл даних зони (для головного сервера);
додаткові файли (файл кореневих серверів).
Найважливішим є файл початкового завантаження. Демон named під час початкового завантаження системи читає його. Формат файлу etc/named.boot:
Directory ім'я_каталогу
cache. ім'я_файлу
primary зона ім'я_файлу
secondary зона IP-адреса ім'я_файлу
forwarders список ІР-адрес
xfrnets список IP-адрес
bogusns список ІР-адрес
Розглянемо окремі директиви цього файлу.
directory визначає каталог, у якому містяться всі файли, зазначені у наступних командах.
cache визначає назву кореневого домену (.) та назву файлу (/etc/named.ca), який містить адреси серверів кореневого домену. Адреси кореневих серверів зазначені явно та використову-ються для отримання інформації тоді, коли база даних та кеш порожні.
primary визначає, що це є головний сервер для зазначеної зони, а також ім'я файлу, у якому містяться дані цієї зони.
secondary визначає, що цей сервер використовують як допоміжний для зазначеної зони, IP-адресу головного сервера, ім'я кеш-файлу, у якому зберігаються дані допоміжного сервера. На відміну від файлу головного сервера, ці дані формуються не вручну, а автоматично демоном named шляхом їхнього узгодження з головним сервером. В одному файлі конфігурування може бути декілька команд primary та secondary, оскільки сервер може бути одночасно пер-винним для однієї зони, а вторинним - для іншої.
forwarders визначає список так званих пересильників. Пересильники - це сервери імен, які кешують запити. Вони можуть бути зовнішніми щодо конкретної мережі. У цьому випадку сервер імен, отримавши запит, переглядає свою базу та кеш. Якщо відповіді не знайдено, то він звертається до пересильників. Отже, пересильники - це сервери імен для серверів імен. Як звичайно, завдяки обслуговуванню багатьох запитів серверів вони мають багато інформації в кеші. Тому їхнє використання розвантажує мережу. Якщо відповіді від пересильника не отримано, то сервер виконує зовнішній запит сам.
xfrnets перераховує у списку адреси мереж та гостів, яким дозволено через зонні пере-силання отримувати інформацію з вашої БД DNS.
bogusns визначає список адрес серверів імен, інформацію з яких треба ігнорувати.
Клієнт (визначник). Головним файлом конфігурування клієнта є /etc/resolv.conf. Він визначає назву доменів, у яких відбуватиметься шукання, а також адреси серверів імен.
У директиві search зазначено перелік назв доменів, якими доповнюють неповністю визначене ім'я перед звертанням до сервера імен.
Спочатку звертаються до першого сервера у списку. Якщо через визначений час тайм-ауту відповіді не отримано, то звертаються до наступного і т. д. Кожен сервер опитують чотири рази. З кожним новим опитуванням значення тайм-ауту збільшується. Отже, процедура опи-тування у разі недосяжності серверів може тривати довго.
Звичайно кожен з серверів, до яких звертається визначник, є рекурсивним, оскільки визначник не опрацьовує відсилань.
Налагодження і тестування. Демон named може бути запущений у декількох режимах налагодження. Рівні налагодження - від 0 до 11. Рівень 0 означає без налагодження, рівні 1 та 2 можна використати для перевірки коректності налаштування, файлів бази даних; рівень 4 і далі використовують системні програмісти для налагодження самого коду демона. Під час роботи демона у режимі налагодження всі службові повідомлення розміщуються у файлах реєстрації системи syslog. Надсилаючи демону системні сигнали, можна змінювати рівень налагодження у процесі його роботи.
Роботу та параметри DNS з консолі оператора можна аналізувати, якщо використовувати утиліти nslookup та dig, можна також переходити між серверами імен, читати записи з їхніх баз даних, зазначаючи їхній тип.
Нові версії DNS
Найпоширенішою на практиці версією DNS є BIND v. 4.9. Консорціум з програмних засобів Internet (Internet Software Consortium) припинив розробку версії 4 та рекомендує пере-ходити до версії BIND 8. Порівняно з попередньою ця версія забезпечує:
динамічне оновлення БД DNS;
повідомлення прозміну змісту БД (Notify, RFC 1996);
підтримку IPv6;
більшу продуктивність
поліпшені засоби безпеки
BIND 8 не поділяє сервери DNS на первинні, вторинні, кешування, а переходить до нової моделі головний—підлеглий (master-slave). Головні сервери містять оригінал БД, а підлеглі — її копії.
Суттєво змінилися механізми оновлення БД підлеглих серверів. У попередній версії параметр конфігурації підлеглого сервера задавав інтервал оновлення. Тому деякий час інформація на вторинному сервері могла бути неактуальною. Нова версія використовує повідомлення NOTIFY (RFC 1996). Після зміни даних у БД головного сервера він надсилає підлеглим повідомлення NOTIFY. Підлеглі в разі потреби ініціюють оновлення своєї БД.
Змінено і порядок передавання записів БД. У попередніх версіях їх передавали окремими повідомленнями. Тепер в одному повідомленні намагаються об'єднати багато записів. Дина-мічне оновлення БД DNS дає змогу клієнтам самостійно оновлювати БД без втручання адміністратора. Завдяки цьому DNS може співпрацювати зі службами DHCP. Сервер DHCP від імені своїх клієнтів оновлює БД, тимчасово записуючи туди їхні імена Netbios та виділені ІР-адреси. Після закінчення терміну дії IP-адреси відповідний запис буде знищено.
Механізми захисту:
у версії BIND 8, як і в попередній, є змога обмежити пересилання інформації (команда allow-transfer, xfrnets);
команда allow-query визначає обмеження щодо обслуговування DNS-запитів для кожного сервера або зони. Це дає змогу захистити "внутрішні" сервери DNS від зовнішніх запитів;
тривають роботи з реалізації цифрових підписів (згідно з RFC 2137) для безпечного динамічного оновлення БД;
IETF працює і над механізмом електронного підписування (трансакційні підписи Transactional Signature (TSIG) відповідей на запити клієнтів. Кожна відповідь буде підписана повноважним сервером, що унеможливить підміну DNS-повідомлень (DNSspoofing).

Внимание, отключите Adblock

Вы посетили наш сайт со включенным блокировщиком рекламы!
Ссылка для скачивания станет доступной сразу после отключения Adblock!

Скачать