Система имен областей (Domain Name System)

Поиск по имени (Hostname Resolution)

Как описано выше, адресация в TCP/IP сети крутится вокруг 32 разрядных номеров. Однако, Вам будет трудно запомнить даже некоторые из них. Поэтому, хосты чаще известны под "обычными", имена типа gauss или strange. Поэтому требуются программы для получения IP адреса по имени машины Этот процесс назван Hostname resolution.

Приложение, которое хочет найти IP адрес по данному имени хоста, не должен пытаться сделать это собственными силами Вместо этого, оно обращается к библиотечным функциям, которые для этого и написаны, они называются gethostbyname (3) и gethostbyaddr (3). Традиционно, эти и ряд других процедур были сгруппированы в отдельной библиотеке названной resolver; в Linux, это часть стандартной libc.

На маленькой сети, подобной Ethernet, или даже на нескольких, не очень трудно поддерживать таблицу, сопоставляющую имена хоста к IP адресам. Эта информация обычно хранится в файле /etc/hosts. При добавлении или перемещении хоста, или при переназначении адресов, все что Вы должны сделать -- это изменить файл hosts на всех хостах. Очевидно, что это будет достаточно трудно в сетях с большим количеством машин.

Одно из решений этой проблемы -- NIS, Сетевая Информационная Система разработанная Sun Microsystems, названное YP, или Желтыми Страницами. NIS хранит hosts файл (и другую информацию) в базе данных на главном хосте, от которого клиенты могут восстановить свои файлы если это необходимо. Все еще, Этот способ подходит только для сетей среднего размера, потому что он требует поддерживать полную базу данных как на центральной машине, так и на всех остальных.

В Internet, первоначально информация об адресах хранилась в единственном файле HOSTS.TXT. Этот файл поддерживался в NIC, и должен был загружаться всеми участвующими участками. Когда сеть выросла, возникло несколько проблем. Постоянное обновление и постоянная перекачка файла HOSTS.TXT регулярно требовали все больше ресурсов, нагрузка на сервер, который этим занимался стала слишком высока. Но еще большей проблемой стало придумывание новых (не совпадающих с преждними) имен. Вот почему, в 1984 г, введена новая схема -- DNS, разработанная Paul Mockapetris и решившая обе проблемы одновременно.

DNS

DNS организовывает имена хостов по областям(domain). Область -- набор как-то связанных участков, это могут быть машины одной сети (на пример все машины в университетском городке, или всех хосты в BITNET), все они могут принадлежать определенной организации (типа американского правительства), или они просто географически близки. Например, университеты сгруппированы в edu области, с каждым Университетом или Коледжом, использующим отдельную подобласть, в которой и находятся все его хосты. Groucho Marx Университету можно давать groucho.edu область, Отделу математики -- maths.groucho.edu. Хост на данной сети к имени области добавляет свое имя и таким образом получает свое полное имя в Internet erdos был бы известен как erdos.maths.groucho.edu.

Картинка изображает пространство имен. Запись в корне этого дерева, которая обозначена единственной точкой, весьма точно названа областью корня, и она связана со всеми другими областями. Чтобы показать что в данном месте пишется полное имя хоста, а не имя относительно локальной области, иногда после имени ставят точку. Это значит, что последний компонент имени принадлежит области корня.

В зависимости от местоположения в иерархии имени, область может быть названа top-level, second-level, или third-level (верхнеуровневой, второго уровня, или третьего уровня). Больше количество уровней встречается редко. Вот несколько верхних областей, которые Вы можете часто увидеть:

  • edu ( Главным образом США ) образовательные учреждения подобно университетам, и т.д..
  • com Коммерческие организации, компании.
  • org некоммерческие организации. Часто частные UUCP сети находятся в этой области.
  • net Gateways и другие административные хосты в сети.
  • mil американские военные учреждения.
  • gov американские правительственные учреждения.
  • uucp Официально, все имена участков прежде используемые как UUCP имена без областей, были перемещены в эту область.

Технически, первый четыре из них принадлежат американской части Internet, но там встречаются и не американские участки. Это особенно верно для net области. Однако, mil и gov используются исключительно в США.

Вне США, каждая страна вообще использует собственную область, названую по имени страны и состоящая из двух букв определенных в ISO-3166. Финляндия, например, использует fi область, fr используется Францией, de Германией, au Австралией и т.д.. Ниже этой высокопоставленной области, NIC каждой страны может свободно раздавать имена хостам. Австралия, например, имеет области второго уровня подобные международным высшим областям, названным com.au, edu.au, и так далее. Другие, подобно Германии, не используйте этот дополнительный уровень, но используют слегка длинные имена, которые непосредственно относятся к организациям управляющих специфической областью. Например, на пример ftp.informatik.uni-erlangen.de.чонечно, эти национальные области не подразумевают что хост расположенный ниже фактически расположен в той же стране; это только сигнализирует что хост регистрировался в NIC этой страны . Шведский изготовитель мог бы иметь отделение в Австралии, и все же регистрировать все хосты в se области.

Теперь, организация пространства имен в иерархии имен областей приятно решает проблему уникальности имен; с DNS, имя хоста должно быть уникально только в пределах одной области Кроме того, полностью квалифицированные имена весьма легко запомнить. Но DNS делает не только это: он позволяет Вам передать работу с подобластями местным администраторам. Например, администратор в Groucho Вычислительном Центре мог бы создать подобласть для каждого отдела; мы уже столкнулись с подобластями физиков и математиков. Когда он решит, что сеть в Отделе Физики слишком большая и хаотичная, чтобы справиться с ней из вне , он может просто передать контроль над physics.groucho.edu областью администраторам этой сети. Тогда они свободны использовать, любые имена хостов и назначать их IP адреса в пределах подсети без вмешательства сверху.

Так, пространство имени раздроблено на зоны, которая управляется своей областью. Обратите Внимание На различие между зоной и областью: область groucho.edu затрагивает все машины в Groucho Marx Университете, в то время как зона groucho.edu включает только хостов которые работают в компьютерном центре непосредственно, например в отделе математики. Хост в отделе физики принадлежат другой зоне, а именно physics.groucho.edu. На картинке 3.6.2, начало зоны отмечено маленьким кружочком справа от имени области.

Поиск имени с помощью DNS

На первый взгляд, все эти суета с областями и зонами кажется делает поиск адреса ужасно сложным делом. В конце концов, если нет центрального органа контролируещего какие имена связаны с каким адресом, тогда как - скромное приложение должно его узнавать?!

Теперь начинается действительно техническая часть описания DNS. Если Вы хотите выяснять IP адрес erdos, тогда, DNS говорит, иди и спроси людей, которые управляют им, и они ответят Вам.

Фактически, DNS - гигантская распределенная база данных. Это осуществлено посредством так называемых серверов имен(name server), которые снабжают всех информацией о данной области или нескольких областях сразу. Для каждой зоны имеются по крайней мере два сервера имен, которые содержат всю информацию относительно хостов в этой зоне. Чтобы получить IP адрес erdos, все что Вы должны сделать -- обратится к серверу имен зоны groucho.edu, который и передаст Вам требуемые данные.

Легко сказать, а как это сделать, подумали вы. Так как найти сервер имен в Groucho Marx Университет? В случае если ваш компьютер не оборудован address-resolving oracle, DNS также обеспечивает это. Когда ваше приложение хочет найти информацию относительно erdos, оно входит в контакт с местным сервером имен, который проводит так называемый итерационный опрос. Сначала он посылает запрос серверу имен об области корня, спрашивая о адресе erdos.maths.groucho.edu. Сервер имен корня сообщает, что это имя не принадлежит зоне его полномочий, но вместо этого отсылает к edu области. Таким образом, он предлагает Вам войти в контакт с сервером имен зоны edu для получения большего количества информации, и прилагает список всех серверов имен edu вместе с их адресами. Ваш местный сервер имен пошлет запрос одному из них, например a.isi.edu. Также как серверу имен корня, a.isi.edu знает что люди groucho.edu управляют свей зоной сами, и направит Вас на их сервера. Местный сервер имен запросит одного из них, который наконец распознает имя, как принадлежащее к его зоне, и вернет IP адрес.

Кажется, что для поиска одного IP адреса тратится слишком много ресурсов. но это не сравнимо меньше, чем при преждней схеме с HOSTS.TXT. Но все еще имеются места для усовершенствования этой схемой.

Чтобы уменьшить время ответа для будущих запросов, сервер имени хранит полученную раньше информацию в кэше. Так что в следующий раз, когда любой другой из вашей локальной сети захочет найти адрес хоста в groucho.edu области, ваш сервер имен не проведет все снова, а будет сразу обращаться к серверу имен groucho.edu.

Конечно, сервер имен не будет хранить эту информацию всегда, а отбросит ее через некоторое время. Этот интервал времени назван time to live(временем жизни), или TTL. TTL задается администратором данной зоны.

Областные сервера имен (Domain Name Servers)

Сервера имен, которые содержат всю информацию относительно хостов в пределах данной зоны названы авторитарными для этой зоны и иногда упоминаются как master name servers. Любой запрос относительно хоста в пределах этой зоны будет в конце концов передан одному из этих серверов. Чтобы обеспечить адекватную картину зоны, эти сервера должны быть хорошо синхронизированы. Это достигается с помощью создания одного главного сервера, который загружает зональную информацию из файлов данных, а другие вторичные сервера через равные интервалы времени качают эти данные с главного сервера.

Одна из причин иметь несколько серверов имен состoит в том, чтобы распределять груз работы, другая -- надежность. Когда одна машина с сервером имен ломается, все запросы будут посылаться другим серверам. Конечно, эта схема не защищает Вас от сбоев сервера, при которых он отсылает неправильные ответы на все запросы DNS, например от ошибок в программе сервера.

Конечно, Вы можете также создать сервер имени, который не будет авторитарным для любой области. Этот тип серверов используется чтобы проверять запросы от местных приложений и кэшировать ответы. Поэтому его называют caching-only сервером. 3.6.5 База данных DNS

Мы видели, что DNS имеет дело не только с IP адресами хостов, но также обменивается информацией относительно серверов имен. В DNS базе данных фактически имеется целая куча различных типов записей.

Единица информации в DNS базе данных названа resource record (записью ресурса), или RR. Каждая запись имеет определенный тип, описывающий тип данных, которые в ней записаны, и определяющий тип сети, к которой она применяется. Последний используется при определении схемы адресования, типа IP адресов (IN класс), или адресов в Hesiod сетях (используемые в MIT), и др. Основной записью ресурсов является запись, которая связывает полное имя области с IP адресом.

Конечно, хост может иметь больше чем одно имя. Однако, одно из этих имен должно быть определенно как официальное, или каноническое имя хоста, в то время как остальные просто псевдонимы. Различие между ними в том, что каноническое имя хоста связано с А записью, в то время как другие только с записью типа CNAME, которая указывает на каноническое имя хоста.

Мы не будем приводить здесь все типы записей, а сделаем это позже, в другой главе, здесь же ограничимся кратким примером. Картинка 3.6.5 показывает часть базы данных области которая загружена на сервере имен для зоны physics.groucho.edu. Кроме A и CNAME записи, Вы можете видеть специальную, занимающую несколько строк, запись сверху файла. Это - SOA запись ресурса, расшифровывается Start of Authority (Начало Власти), которая содержит общую информацию относительно зоны, для которой этот сервер является авторитарным. Она включает, например, время жизни для всех записей.

Обратите Внимание что все имена в файле с примером, которые не заканчиваются точкой интерпретируются относительно groucho.edu области. Специальное имя "@", используемое в SOA записи при обращении к имени данной области.

Мы видели, что сервера имен для groucho.edu области так или иначе должен знать хоть что-то относительно зоны физиков так, чтобы направлять запросы серверам имен. Это обычно достигается парой записей: NS запись дается FQDN, и А запись, ассоциирующая его имя с IP адресом. Так как эти записи появляются вместе, они часто называются склеенными записями. Это -- фактически единственный случаи записи, в которой родительская зона держит информацию относительно хостов в зоне подчиненного. Склеенные записи указывающие на сервера имен для physics.groucho.edu показаны на рисунке

Authoritative Information on physics.groucho.edu

@ IN SOA { niels.physics.groucho.edu. hostmaster.niels.physics.groucho.edu. 1034 ;

serial no 360000 ;

refresh 3600 ;

retry 3600000 ;

expire 3600 ;

default ttl - 51 - } ;

Name servers IN NS niels IN NS gauss.maths.groucho.edu. gauss.maths.groucho.edu. IN A 149.76.4.23;

Theoretical Physics (subnet 12) niels IN A 149.76.12.1 IN A 149.76.1.12 nameserver IN CNAME niels otto IN A 149.76.12.2 quark IN A 149.76.12.4 down IN A 149.76.12.5 strange IN A 149.76.12.6 ... ;

Collider Lab. (subnet 14) boson IN A 149.76.14.1 muon IN A 149.76.14.7 bogon IN A 149.76.14.12 ...

Фрагмент файла amed.hosts для Отдела Физики.

Обратный поиск.

После обнаружения IP адреса, принадлежащего хосту, иногда желательно выяснять каноническое имя хоста, соответствующее данному адресу. Это называется reverse mapping(обратное отображение) и используется несколькими сервесами, чтобы проверить идентичность клиента. При использовании единственного hosts файла, обратный поиск заключается просто в проверке этого файла. В DNS, конечно не проводится просмотр всего адресного пространсва. Вместо этого, создана специальная область, inaddr.arpa, она содержит IP адреса всех хостов. в перевернутой dotted-quad записи Например, IP адрес 149.76.12.4 соответствует имени 4.12.76.149.in-addr.arpa. Тип записи ресурса, связывающий это имя с именем, называется PTR. Zone data for the groucho.edu zone.

@ IN SOA { vax12.gcc.groucho.edu. hostmaster.vax12.gcc.groucho.edu. 233 ;

serial no 360000 ;

refresh 3600 ;

retry 3600000 ;

expire 3600 ;

default ttl } .... ;

Glue records for the physics.groucho.edu zone physics IN NS niels.physics.groucho.edu. IN NS gauss.maths.groucho.edu. niels.physics IN A 149.76.12.1 gauss.maths IN A 149.76.4.23 ...

Фрагмент файла named.hosts для GMU.

Создание зоны полномочий обычно означает что ее администраторам дают полный контроль над тем как назначать адреса и имена хостов. Так как они обычно управляют одной или более IP сетями или подсетями, одна DNS зона может охватывать несколько IP сетей. Отдел Физики, например, включает подсети 149.76.8.0, 149.76.12.0, и 149.76.14.0.

Как следствие, новые зоны должны быть записаны в in-addr.arpa области:

8.76.149.in-addr.arpa, 12.76.149.in-addr.arpa, и 14.76.149.in-addr.arpa.

Иначе, установка нового хоста в Collider лаборатории требовала бы обращения к родительской области чтобы отметится в ее in-addr.arpa файле. Зональная база данных для подсети

12.76.149.in-addr.arpa domain. @ IN SOA { niels.physics.groucho.edu. hostmaster.niels.physics.groucho.edu. 233 360000 3600 3600000 3600 }

2 IN PTR otto.physics.groucho.edu.

4 IN PTR quark.physics.groucho.edu.

5 IN PTR down.physics.groucho.edu.

6 IN PTR strange.physics.groucho.edu.

Фрагмент файла named.rev для подсети

76.149.in-addr.arpa domain. @ IN SOA { vax12.gcc.groucho.edu. hostmaster.vax12.gcc.groucho.edu. 233 360000 3600 3600000 3600 } ... ;

subnet 4: Mathematics Dept.

1.4 IN PTR sophus.maths.groucho.edu.

17.4 IN PTR erdos.maths.groucho.edu.

23.4 IN PTR gauss.maths.groucho.edu. ... ;

subnet 12:

Physics Dept, separate zone

12 IN NS niels.physics.groucho.edu.

IN NS gauss.maths.groucho.edu. niels.physics.groucho.edu.

IN A 149.76.12.1 gauss.maths.groucho.edu.

IN A 149.76.4.23 ...

Фрагмент файла named.rev для сети

Одно важное следствие этого то, что зоны могут создаваться только как наборы IP сетей, и, даже круче, количество нулевых битов в netmasks должно выть кратно 8.

Все подсети в Groucho Marx Университете имеют netmask 255.255.255.0, так что in-addr.arpa зона может быть создана для каждой подсети. Однако, если netmask 255.255.255.128, создание зон для подсети 149.76.12.128 будет невозможно, потому что нет никакой возможности сообщить DNS, что 12.76.149.in-addr.arpa область была раздроблена на две зоны, с именами хостов располагающимися от 1 до 127, и 128 до 255, соответственно.