імена влаштовані досить примітивно. До існуючою схемою прийшли не від хорошого життя. Коли комп'ютерів стало дуже багато, то:
по-перше, виявилося, що адміністратори мереж чомусь хочуть самі іменувати свої комп'ютери;
-друге - адміністратори всіх комп'ютерів на світі чомусь не хочуть скачувати постійно/etc/hosts з центрального сховища, вважаючи за краще писати/etc/hosts власноруч, і він, природно, не збігається у всіх комп'ютерів в інтернеті.
У якийсь момент стало очевидним те, що файлом/etc/hosts справу обмежитися не може і що треба створити якусь систему, яка сама перетворювала строкове ім'я в числову адресу і назад. Але якщо загального файлу не існує, то треба використовувати якусь програму з цими функціями. А тоді з'явилася ідея: оскільки адміністратори самі пишуть/etc/hosts, то нехай вони і далі самі роздають імена комп'ютерів у своїй галузі володіння, тобто: ти адміністріруешь якісь комп'ютери - значить, роздати їм імена - теж твій обов'язок. Таким чином, вирішується завдання - перетворення доменних імен в адреси і назад. p align="justify"> Рішення завдання полягає в тому, що у кожного системного адміністратора є свій файл перетворення хостів та IP-адрес. Точніше не файл, а спеціальна таблиця (її вигляд залежить від використовуваного DNS-сервера), розподілена по вищевикладеної схемою. br/>
Організація системи доменних імен
Світова система доменних імен організована таким чином: існує кілька кореневих серверів, які ні в якому разі не знають усі імена всіх комп'ютерів в мережі (і, більше того, не зобов'язані цього знати). Замість цього вони містять інформацію про так званих зонах DNS, що складаються з одного імені. Наприклад, існують зони ru, com, info, de і так далі. По-перше, вони знають про те, які імена першого рівня існують в принципі, оскільки їх відносно небагато. Недавно їх було зовсім мало - в старих довідниках по інтернету вказувалися тільки com, net, org, edu, gov і ще кілька зон, пов'язаних з державами, по двобуквеного кодами. У якийсь момент було прийнято рішення сильно розширити діапазон, а нещодавно прийняли рішення, що для запису імен зон буде використовуватися кодування юнікод, що дасть змогу створити імена зон на національних алфавітах. p align="justify"> Отже, кореневі DNS-сервера знають про всіх існуючих зонах, тобто про те, які взагалі бувають закінчення біля доменних імен. Крім цього, вони також знають адреси серверів, що володіють інформацією про вміст цих зон - тобто про комп'ютери, імена яких закінчуються на закінчення зони. Зазначені сервера називаються серверами імен або NS-серверами (nameservers). Кореневі сервери видають відповідь на питання досить простого властивості - по-перше, чи існує в принципі таке ім'я (перевіряючи закінчення), і, якщо воно існує, то де знаходиться сервер (точніше, сервери) імен, які знають про імена з такими закінченнями.
Якщо подивитися в словнику слово домен, ми дізнаємося, що воно з'явилося дуже давно, і означає воно область володінь феодального васала. Феодальна структура була влаштована пірамідально і найголовніше - за принципом (дотримання і в DNS) "васал мого васала - не мій васал". Тобто сервер відповідає за своїх безпосередніх підлеглих, і не відповідає за прямих підлеглих, які не є безпосередніми.
Розглянемо доменне ім'я cs.msu.ru. Сервер, який відповідає за зону ru, відповідає тільки за сервера імен тих хостів, які мають двоскладові імена, що закінчуються на "ru" (ru, msu.ru і т.д). А якщо в імені більше складових, то сервер імен зони ". Ru" не зобов'язаний знати ip-адреса сервера імен хоста, хоча він може і зберігати його в силу різних причин. p align="justify"> Але він зобов'язаний знати адресу сервера імен хоста msu.ru. Далі запитується сервер імен msu.ru, а він уже зобов'язаний відповісти, хто такий cmc.msu.ru або повідомити його сервер імен, та так далі. У результаті ми отримаємо у відповідь або ip-адреса, або повідомлення про те, що такого домену немає. p align="justify"> По суті, ми описали ієрархічну розподілену базу даних. p align="justify"> Продуктивність і надійність системи доменних імен
В описаному процесі перетворення доменного імені в IP-адресу є одна проблема: невже, кожен раз, коли нам знадобиться, перебуваючи в якомусь іншому домені, зайти на факультетський поштового сервер, буде потрібно запитувати кореневий сервер? Тоді навіщо це все було придумано, адже число запитів на кореневі сервери буде як і раніше величезно? p align="justify"> Тому для того, щоб цю процедуру зробити ефективнішою, є три ідеї, які сильно полегшують навантаження.
. Кожна таблиця із записом відповідності IP-адреси доменному імені містить в собі інформацію про те, протягом якого часу ця таблиця, по-перше, дійсна, а по-дру...
