машині sophus, може виявитись, що вона неповна (містити маршрути до математичної мережі, до FDDI бекбону та маршрут по замовчуванню на шлюз в Комп'ютерному Центрі Grouncho - gcc1). Тому всі пакети для quark надсилались на gcc1, а не напряму через niels (шлюз у відділі Фізики). При отриманні таких данних, gcc1 побачить що це не найкращий маршрут, він передасть данні niels і в той же час поверне на sophus повідамлення ICMP Redirect про цей кращий маршрут.
Цей метод здається дуже розумним шляхом уникати потреби встановлювати "руками" будь-які маршрути крім основних. Однак попереджуємо, що використання динамічної схеми маршрутизації (будь то RIP або ICMP повідомлення Redirect) є не завжди хорошою ідеєю. Повідомлення ICMP Redirect та RIP мають невеликі можливості або взагалі не пропонують механізму підтвердження достовірності деякої інформації стосовно маршрутизації. Це дозволяє людям з поганими намірами порушити нормальну роботу вашої мережі, або зробити ще щось гірше. В зв'язку з цим існує кілька версій мережевого коду ядра Linux які опрацьовують повідомлення Redirect тільки для маршрутів хостів, а повідомлення про маршрути мереж ігноруються.
3.6 Система доменних назв (Domain Names System)
3.6.1 Знаходження назви хоста
<> Як описано вище, адресація в TCP/IP базується на 32-ох бітних числах. Але навряд чи ви зможете запам'ятати більше ніж кілька адресів. Тому хости мають ще `звичайну' назву - наприклад gauss чи strange. Для того того щоб мати можливість працювати з такими іменами потрібно найти IP адресу що відповідає певній назві. Цей процес і називається host name resulution.
Программа, якій потрібно знайти IP адресу данного хоста за назвою, не повинні використовувати своїх власних процедур знаходження хоста і його IP адреси. Замість цбого потрібно покладатись на бібліотечні функції gethostbyname(3) та gethostbyaddr(3), які забезпечують прозорість та сумісність. Традиціно ці та ще кілька подібних функцій згруповуються в окрему бібліотеку - бібліотеку resolver; в Linux ці функції частина стандартної бібліотеки libc.
На невеличкій Ethernet мережі, чи навіть на кластері Ethernet мереж не тяжко обслуговувати таблиці відповідності між назвами хостів та їх адресами. Ця інформація частіш за все зберігається в файлі /etc/hosts. При заведені нового хоста, знищенні чи при переназначенні адресів вам необхідно привести у відповідність файли hosts на всіх хостах. Очевидно, що це буде обтяжливо в мережах які містять більше ніж кілька машин.
Одним з вирішень цієї проблеми є NIS, Network Information System, що розроблена фірмою Sun Microsystems (в розмовній мові відома як YP, Yellow Pages -- Жовті Сторінки). NIS зберігає файл hosts (та іншу інформацію) в базі данних на основному хості, з якого клієнти можуть взяти потрібну їм інформацію. Цей підхід підходить лишень для мереж середніх розмірів типу LAN, так як необхідно зберігати повну базу hosts централізовано, і роздавати її всім серверам.
На початку, в Internet адресна інформація зберігалась в єдиній базі данних HOSTS.TXT. Цей файл знаходився в Network Information Center (або NIC), і повинен був зкачуватись та встаноновлюватись на всі підключені сайти. Коли мережа виросла то почали з'являтись деякі проблеми. Так як базу HOSTS.TXT потрібно було ругулярно обновлювати, то навантаження на центральний сервер стало занадто великим. Ще більш серйозною проблемою було те, що кожна назва повинна була реєструватись в NIC, який перевіряв чи ця назва вже не використовується.
Тому в 1984 році була прийнята нова схема вирішення назв - Domain Name System. DNS було розроблено Paul Mockapetris і він вирішує обидві проблеми одночасно.
3.6.2 Введення в DNS
DNS організовує назви хостів в ієрархію доменів. Домен (область) - набір сайтів що пов'язані певним чином --- наприклад формують якусь певну мережу (наприклад всі машини університетського містечка, або всі машини мережі BITNET), або належать певній організації (наприклад урядові США) або вони просто знаходяться географічно близько. Наприклад всі університети згруповані в домен edu, кожен Коледж чи Університет використовує окремий піддомен в який входять всі його хости. Університет Groucho Marx може мати домен groucho.edu, локальна мережа Математичного відділу - maths.groucho.edu. До назв хостів мережі відділу додавався би цей домен - відповідно машину erdos можна назвати erdos.maths.groucho.edu. Такий запис називається повною доменною назвою (або FQDN) і є унікальним ідентифікатором цього хоста для решти світу.
На ілюстрації 3.6.2 показано простір назв. Входження в корені цього дерева (позначене одною точкою) відповідно називається кореневим доменом і стосується всіх інших доменів. Для вказування на те, що назва хоста це повна доменна назва, і що вона не залежить відносно деякого (неявного) домену, використовується крапка в кінці назви. Якщо точки немає, то це означає, що останнім компонентом назви є кореневий домен.
Відповідно до місцезнаходження в ієрархії назви, домен може бути названим доменом першого рівня, другого рівня, третього рівня. Домени нижчих порядків зустрічаються досить рідко. Існує кілька доменів першого порядку які ви можете часто зустрінути :
Ілюстрація 4. Частина назв доменів першого порядку
edu | (головним чином США) освітні заклади типу університетів, то що.
com | Комерційні організації, компанії.
org | Некомерційні організації. Часто приватні UUCP мережі знаходяться під цим доменом.
net | Шлюзи та інші адміністративні хости в мережі.
mil | Американські військові заклади.
gov | Американські урядові заклади.
uucp | Офіційно, всі назви сайтів що раніше використовували UUCP назви без домена були перенесені в цей домен.
Технічно, перші чотири домена належать американській (США) частині Internet, але ви також можете побачити неамериканські сайти в цих доменах. Особливо це