За межами США кожна країна використовує свій власний двохбуквенний домен першого порядку (верхній домен) як це описано ISO-3166. Фінляндія, наприклад, використовує домен fi, домен fr використовується Францією, de - Німеччиною, au - Австралією і т.д.. Всі домени нижчих порядків (другого, третього, і т.д.) NIC кожної країни організовує за своїм бажанням. Австралія, для прикладу, має домену другого порядку подібнт до міжнародних доменів першого порядку : com.au, edu.au і т.д.. Інші, як наприклад Німеччина, не використовують цей додатковий рівень, що призводить до використання досить довгих назв доменів які безпосередньо стосуються організацій що керують відповідним доменом. Наприклад можна побачити хости типу ftp.informatik.uni-erlangen.edu. Віднесемо це до німецької ефективності.

Звичайно, ці національні домени не означають що що хост цього домену фактично знаходиться в цій країні; це тільки показує що хост реєструвався в NIC ції країни. Шведський виробник може мати відділення в Австралії, і все одно мати всі хости з доменом першого порядку se.

Тепер, організувавши простір назв в ієрархії доменних назв, легко вирішується проблема унікальності назв; з DNS, назва хоста повинна бути унікальною тільки в межах домена для того щоб бути унікальною для решти світу. Крім того повні доменні назви досить прості для запам'ятовування. І вже це є непоганим резоном для розбиття великого домену на декілька піддоменів.

Але DNS дозволяє вам ще більше: дозволяє вам делегувати повноваження по піддоменах їх адміністраторам. Наприклад основний адміністратор GMU міг би створити піддомени для кожного відділу; ми вже зустрічались з математичним та фізичними піддоменами вище. Коли адміністратор побачив що мережа в відділі Фізики занадто велика і хаотична для управління ззовні (в кінці кінців фізики відомі як група буйних людей), він передав контроль над доменом physucs.groucho.edu адміністраторам цієї мережі. В цьому випадку вони зможуть призначати хостам назви та одреси локальної мережі як їм заманеться, без втручання ззовні.

На закінчення звернемо увагу, що простір назв розділюється на зони, кожна з яких містить домен. Зверніть увагу що зона відрізняється від домену: домен groucho.edu охоплює всі хости в мережі університету, в той час як зона grouch.edu містить лишень ті хости які безпосередньо управляються Комп'ютерним Центром (для прикладу у відділі Математики). Хости у відділі Фізики належать іншій зоні - physics.grouch.edu. На ілюстрації 3.6.2 початок зони відмічено кружком справа від назви домена.

3.6.3 Пошук назв через DNS

На перший погляд здається що всі ці домени та зони роблять знаходження назви надзвичайною складною справою. В кінці кінців, якщо немає централізвоного контролю за призначенням назв хостам, то як якась скромна програма може знати це?

А тепер ми підійшли до дійсно цікавої частини стосовно DNS. Якщо вам потрібно дізнатись IP адресу erdos, то, DNS скаже, піди спитайся в людей що керують цим, і вони дадуть відповідь.

Фактично, DNS це гігантська розподілена база данних.Це досягається за допомогою так званих серверів назв що володіють інформацією стосовно данного домену чи набору доменів. Для кожної зони існує принаймі два, а частіш за все і більше, серверів імен що володіють авторизованою інформацією про хости в цій зоні. Щоб отримати IP адресу erdos, все, що потрібно зробити - з'єднатись з сервером для зони groucho.edu, який і надасть необхідні данні.

Ви можете думати що це легше описується, ніж виконується. Яким ж чином я можу взнати адресу сервера назв для Університету Groucho Marx? Якщо ваш комп'ютер не обладнаний персональним оракулом, то ви можете використати для цього DNS. Якщо ваша прикладна програма дасть запит про erdos, то для початку вона зв'яжеться з локальним сервером назв, який спродукує так званий інтераційний запит. Це буде запит до серера імен кореневого домена про машину erdos.maths.groucho.edu. Кореневий сервер назв розпізнає, що ця назва не належить його зоні повноважень, але належить десь глибоко в зоні edu. Таким чином, він повідомить, що потрібно ввійти в контакт з одним з серверів зони edu, список яких він надішле разом з їхніми адресами. Після цього ваш локальний сервер назв звернеться до одного з цих серверів, наприклад a.isi.edu. Подібним чином a.isi.edu повідомить, що зоною groucho.edu керують люди Університету, і направить вас до їхнього сервера. Локальний сервер назв звернеться з запитом стосовно erdos до одного з відповідальних за зону groucho.edu серверів, який накінець розпізнає назву як таку що належить його зоні і поверне IP адресу хоста erdos.

Це показує, наскільки великий трафік створюється при спробі знайти звичайну IP адресу, але все це ніщо у порівнянні з тією кількістю даних, які передавались би при використанні HOSTS.TXT. Але все ще існують щляхи для вдосконалення цієї схеми.

Щоб покращити час відповіді при наступних зверненнях, сервер назв зберігає отриману інформацію в локальному кеші. Так що коли наступний раз будь-хто з вашої локальної мережі дасть запит на адресу хоста з домену groucho.edu, ваш сервер не потребуватиме повтору вищеописаного процесу, він зразу безпосередньо звернеться до сервера імен зони groucho.edu (4).

Звичайно що сервер назв не буде зберігати цю інформацію постійно, він відмовиться від неї через деякий час. Цей інтервал називається `час життя' (time to live - TTL). Кожен запис в базі данних DNS має присвоєний адміністратором зони TTL.

3.6.4 Domain Name Servers

Сервери назв, які містять всю інформацію стосовно хостів в межах певної зони називаються авторизованими