Існуючі реалізації

Підтримка SNMP - у багатьох значущих системах управління мережами, зокрема:

• HP Network Node Manager;

• IBM Tivoli NetView;

• OpenNMS

Недоліки snmp

Протокол SNMP служить основою багатьох систем управління, хоча має кілька принципових недоліків, які перераховані нижче:

• Відсутність засобів взаємної аутентифікації агентів і менеджерів. Єдиним засобом, який можна було б віднести до засобів аутентифікації, є використання в повідомленнях так званого рядка «community string». Цей рядок передається по мережі у відкритій формі в повідомленні SNMP і служить основою для поділу агентів і менеджерів на «спільноти», так що агент взаємодіє тільки з тими менеджерами, які вказують в поле community string такий же символьний рядок, що й рядок, який зберігається в пам'яті агента. Це, безумовно, не спосіб аутентифікації, а спосіб структурування агентів і менеджерів. Версія SNMP v.2 повинна була ліквідувати цей недолік, але в результаті розбіжностей між розробниками стандарту нові засоби аутентифікації хоча і з'явилися в цій версії, але як необов'язкові.

• Робота через ненадійний протокол UDP (а саме так працює переважна більшість реалізації агентів SNMP) призводить до втрат аварійних повідомлень (повідомлень trap) від агентів до менеджерів, що може призвести до неякісного управління.

Лекція 21 Система доменних імен.

Структура DNS

Функціонування системи доменних імен ґрунтується на використанні ієрархічного простору імен, який має деревоподібну структуру. Весь простір імен DNS складається з множини доменних просторів імен, зв'язаних один із одним деякими ієрархічними відносинами. У залежності від того, яке положення займає домен у цій ієрархії, прийнято говорити про рівень домена. На будь-якому рівні домен може включати у свій склад домени більш низького рівня. Починаючи з другого рівня, домени можуть також містити записи про хости.

Мережений інформаційний центр (Network Information Center, NІС) регламентує процес створення доменів першого і другого рівня. При побудові корпоративної мережі, яка не буде складовою частиною глобальної мережі Інтернет, можна будувати власну ієрархію доменів. Windows 2000 дозволяє використовувати усередині корпоративної мережі власний простір імен, у той час як для інтеграції з Інтернет буде використовуватися зовсім інший простір імен.

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

Домени першого рівня використовуються для групування інших доменів по організаційній чи географічній ознаці. На початковому етапі становлення Інтернет було запропоновано групувати домени по організаційній ознаці. Це дозволяло легко визначити приналежність організації, яка володіє доменом, до певного типу. Для реалізації задуманого запропонований ряд доменів першого рівня, кожний з який утвориться трьома символами: .edu (освітні установи), .com (комерційні організації), .org (некомерційні організації), .gov (урядові організації), .mil (військові установи) і інші. Однак швидкий ріст Інтернету заставив трохи розширити систему іменування доменів першого рівня. Було запропоновано групувати домени по їх приналежності до деякої держави. Для цього використовуються імена, що складаються з двох символів. Наприклад: .ua (Україна), ru (Росія), ie (Ірландія) і т.п.

Крім цього існує ще один домен першого рівня, який використовується для групування зворотних доменів (reverse domains). Зворотні домени застосовуються для здійснення пошуку доменного імені хоста по його IP-адресі. Цей спеціальний домен одержав назву .аrра, Домен містить тільки один домен другого рівня: .in-addr.arpa.

Для того щоб мати можливість звертатись до хоста із будь-якої довільної точки мережі, необхідно використовувати повне доменне ім’я цього хоста (Fully Qualified Domain Name, FQDN). Повне доменне ім'я хоста утвориться з імені хоста й імен усіх доменів, що знаходяться між хостом і кореневим доменом.

Використання служби DNS для розв’язання доменних імен

Існує безліч реалізацій служб DNS, однак усі вони націлені на досягнення однієї мети — розв’язання доменних імен у IP-адреси. Служба DNS являє собою розподілену базу даних, яка містить інформацію про ІР-адреси і відповідні їм доменні імена. При цьому дані, які утворюють простір імен DNS, не концентруються в одному місці, а зберігаються у вигляді окремих фрагментів на окремих серверах, що і утворює розподілену базу даних DNS. Комп'ютер, на якому функціонує служба DNS, прийнято називати DNS-сервером. Усі функції по організації процесу розв’язання доменних імен бере на себе клієнт DNS, який функціонує на рівні програмних інтерфейсів (API). Основна задача клієнта DNS — передати запит на розв’язання доменного імені найближчому DNS серверу. У відповідь клієнт повинен одержати або IP-адресу, або повідомлення про неможливість розв’язання наданого серверу доменного ім'ені. Клієнт DNS передає отриману IP-адресу додатку, що ініціював процес розв’язання імені. Додаток використовує отриману IP-адресу для того, щоб встановити пряме з'єднання з потрібним йому хостом.

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

Припустимо, що комп'ютерmail хоче встановити з’єднання з комп'ютером ccna.networkacad.net (рис. 1). Спочатку комп'ютер намагається знайти відповідність між доменним ім’ям і IP-адресою у власному локальному кеші DNS. Після кожного успішного розв’язання імені в локальний кеш поміщається запис про доменне ім’я і відповідну йому IP-адресу. Такі записи зберігаються в кеші певний час і втрачаються при зупинці служби клієнта DNS. Крім того, існує можливість завантажувати у локальний кеш вміст файлу HOSTS при кожній ініціалізації локального кеша клієнта DNS. На відміну від записів, що поміщаються в кеш після розв’язання доменних імен, інформація, що завантажується з файлу HOSTS, зберігається в кеші постійно, аж до зупинки служби клієнта DNS.

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

Очевидно, що лише DNS-сервер, який обслуговує домен другого рівня networkacad.net і містить базу даних про всі хости даного домена, здатний розв’язати ім'я ccna. Тому основний DNS-сервер клієнта намагається знайти цей сервер. Насамперед, основний DNS-сервер відправляє запит DNS-серверу кореневого домена, щоб одержати IP-адрес DNS-сервера домена першого рівня .net (мал. 8.4). В базі даних цього сервера містяться відомості про IP-адреси всіх DNS-серверів, що обслуговують домени другого рівня, які належать до домену .net (у тому числі і домен networkacad.net). На останньому етапі основний DNS-сервер клієнта відправляє запит DNS-серверу домена networkacad.net на розв’язання імені хоста ccna. У відповідь основний DNS-сервер одержує IP-адрес, який і повертає клієнту, що зробив запит на розв’язання імені.