DNS организует имена хостов по областям или доменам ( domain). Домен, это набор как-то связанных участков, это могут быть машины одной сети (например, все машины в университетском городке, или все хосты в BITNET), все они могут принадлежать определенной организации (типа американского правительства) или они просто географически близки. Например, университеты сгруппированы в домен edu, каждый университет или колледж использует отдельную подобласть, субдомен (subdomain), в которой и находятся все его хосты. Университету Groucho Marx принадлежит домен groucho.edu, его отделу математики maths.groucho.edu. Хост в сети добавляет свое имя к имени домена и таким образом получает свое полное имя в Internet: erdos был бы известен как erdos.maths.groucho.edu. Это называется полным доменным именем, fully qualified domain name (FQDN).
Так возникает древовидная структура. Запись в корне этого дерева, которая обозначена единственной точкой, весьма точно названа корневым доменом (root domain), и она связана со всеми другими доменами. Чтобы показать, что в данном месте пишется полное имя хоста, а не имя относительно локальной области, иногда после имени ставят точку. Это значит, что последний компонент имени принадлежит корневому домену.
В зависимости от местоположения в иерархии имени, домен может быть назван top-level, second-level или third-level (верхнего уровня, второго уровня или третьего уровня). Большее количество уровней встречается относительно редко. Вот несколько верхних областей, которые вы можете часто увидеть:
| Домне | Описание |
|---|---|
| edu | Образовательные учреждения, подобные университетам (главным образом США, хотя регистрироваться в этом домене могут ВУЗы любой страны). |
| com | Коммерческие организации, компании. В Москве много таких доменов. |
| org | Некоммерческие организации. Часто частные UUCP-сети находятся в этом домене. К конкретной стране не привязан. |
| net | Шлюзы и другие административные хосты в сети. Часто сетевые сервисы, справочники и т.п. Например, автор данной работы в свое время хотел зарегистрировать домен RussianLDP.net и отказался от этого лишь из-за оплаты домена. Но в последнее время в нем стало можно регистрировать имена за рекламу, так что, может, еще и соберусь... |
| mil | Американские военные учреждения. |
| gov | Американские правительственные учреждения (хотя в последнее время наметились сдвиги в плане того, чтобы сделать этот домен международным правительственным). |
| uucp | Официально, все имена сайтов, прежде используемые как UUCP-имена без доменов, были перемещены в этот домен. |
| ru | Российский национальный домен. Все машины с этим доменом находятся в России. |
Технически первые четыре из них принадлежат американской части Internet, но там встречаются и не американские сайты. Это особенно верно для доменов .net и .org. Однако, .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-адреса в пределах подсети без всякого вмешательства сверху.
Таким образом, пространство имен раздроблено на зоны ( zones), каждая из которых управляется своим доменом. Обратите внимание на различие между зоной (zone) и доменом (domain): домен groucho.edu затрагивает все машины в университете Groucho Marx, в то время как зона groucho.edu включает только хосты, которые работают в непосредственно компьютерном центре, например в отделе математики. Хост в отделе физики принадлежат другой зоне, а именно physics.groucho.edu.
На первый взгляд, вся эта суета с областями и зонами кажется делает поиск адреса ужасно сложным делом. В конце концов, если нет центрального органа, контролирующего, какие имена с каким адресом связаны, тогда как скромное приложение должно его узнавать?!
Фактически, DNS гигантская распределенная база данных. Это осуществлено посредством так называемых серверов имен (name server), которые снабжают всех информацией о данном домене или нескольких доменах сразу. Для каждой зоны имеются по крайней мере два сервера имен, которые содержат всю информацию относительно хостов в этой зоне. Чтобы получить IP-адрес erdos, все что вы должны сделать, это обратится к серверу имен зоны groucho.edu, который и передаст вам требуемые данные.
Легко сказать, а как это сделать? Как найти сервер имен в Groucho Marx? В случае если ваш компьютер не оборудован программой преобразования адресов, DNS также обеспечивает это. Когда ваше приложение хочет найти информацию относительно erdos, оно входит в контакт с местным сервером имен, который проводит так называемый итерационный опрос. Сначала он посылает запрос серверу имен корневого домена, спрашивая об адресе erdos.maths.groucho.edu. Сервер имен корня сообщает, что это имя не принадлежит зоне его полномочий, но вместо этого отсылает к домену edu. Таким образом, он предлагает вам войти в контакт с сервером имен edu для получения большего количества информации и прилагает список всех серверов имен edu вместе с их адресами. Ваш местный сервер имен пошлет запрос одному из них, например, a.isi.edu. Также как серверу имен корня, a.isi.edu знает, что люди groucho.edu управляют своей зоной сами, и направит вас на их сервера. Местный сервер имен запросит один из них, который, наконец, распознает имя, как принадлежащее к его зоне, и вернет IP-адрес.
Кажется, что для поиска одного IP-адреса тратится слишком много ресурсов, но это несравнимо меньше, чем при прежней схеме с файлом HOSTS.TXT. Но все еще имеются места для усовершенствования этой схемы.
Чтобы уменьшить время ответа для будущих запросов, сервер имен хранит полученную раньше информацию в кэше (cache). Так что в следующий раз, когда любой другой компьютер из вашей локальной сети захочет найти адрес хоста в домене groucho.edu, ваш сервер имен не проведет все снова, а будет сразу обращаться к серверу имен groucho.edu.
Конечно, сервер имен не будет хранить эту информацию всегда, а отбросит ее через некоторое время. Этот интервал времени назван time to live, (временем жизни) или TTL. TTL задается администратором каждой конкретной зоны.
Сервера имен, которые содержат всю информацию относительно хостов в пределах данной зоны, названы авторитетными для этой зоны и иногда упоминаются как authoritative или master name servers. Любой запрос относительно хоста в пределах этой зоны будет в конце концов передан одному из этих серверов.
Чтобы обеспечить адекватную картину зоны, эти сервера должны быть хорошо синхронизированы. Это достигается с помощью создания одного главного (первичного, primary) сервера, который загружает зональную информацию из файлов данных, а другие (вторичные, secondary) сервера через равные интервалы времени качают эти данные с главного сервера.
Одна из причин наличия нескольких серверов имен состoит в том, чтобы распределить груз работы, другая в надежности. Когда одна машина с сервером имен ломается, все запросы будут посылаться другим серверам. Конечно, эта схема не защищает Вас от сбоев сервера, при которых он отсылает неправильные ответы на все запросы DNS, например, от ошибок в программе сервера.
Конечно, вы можете также создать сервер имени, который не будет авторитетным для любого домена. Этот тип серверов используется, чтобы проверять запросы от местных приложений и кэшировать ответы. Поэтому его называют caching-only сервером.
Мы видели, что DNS имеет дело не только с IP-адресами хостов, но также обменивается информацией относительно серверов имен. В базе данных DNS фактически имеется целая куча различных типов записей.
Единица информации в базе данных DNS названа записью ресурса (resource record) или RR. Каждая запись имеет свой тип, описывающий тип данных, которые в ней записаны, и определяющий тип сети, к которой она применяется. Последний используется при определении схемы адресации, вроде IP-адресов (IN класс), или адресов в Hesiod-сетях (используемые в MIT). Основной записью ресурсов является запись, которая связывает полное имя домена с IP-адресом.
Конечно, хост может иметь больше, чем одно имя. Например, сервер предоставляющий сервисы FTP и World Wide Web может иметь имена ftp.machine.org и www.machine.org. Однако, одно из этих имен должно быть определено как официальное или каноническое (canonical) имя хоста в то время, как остальные просто псевдонимы. Различие между ними в том, что каноническое имя хоста связано с А-записью в то время, как другие только с записью типа CNAME, которая указывает на каноническое имя хоста.
Я не буду приводить здесь все типы записей, а сделаю это позже, в другой главе, здесь же ограничусь кратким примером. Пример 6-4 показывает часть базы данных домена, которая загружена на сервере имен для зоны physics.groucho.edu.
Пример 6-4. Выдержка из файла named.hosts для отдела физики
; Authoritative Information on physics.groucho.edu.
@ IN SOA niels.physics.groucho.edu. janet.niels.physics.groucho.edu. {
1999090200 ; serial no
360000 ; refresh
3600 ; retry
3600000 ; expire
3600 ; default ttl
}
;
; 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
name server 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
...
|
Кроме записей A и CNAME, Вы можете видеть специальную, занимающую несколько строк запись вверху файла. Это SOA-запись ресурса расшифровывается как Start of Authority (начало авторитета), которая содержит общую информацию относительно зоны, для которой этот сервер является авторитетным. Она включает, например, время жизни для всех записей.
Обратите внимание, что все имена в файле с примером, которые не заканчиваются точкой, интерпретируются относительно physics.groucho.edu. Специальное имя (@ ), используемое в записи SOA при обращении к имени данного домена.
Мы видели, что сервера имен для groucho.edu так или иначе должны знать хоть что-то относительно зоны физиков так, чтобы направлять запросы серверам имен. Это обычно достигается парой записей: NS-запись дает FQDN, и А-запись, ассоциирующая его имя с IP-адресом. Так как эти записи появляются вместе, они часто называются склеенными записями (glue records). Это фактически единственный случаи записи, в которой родительская зона держит информацию относительно хостов в зоне подчиненного. Склеенные записи, указывающие на сервера имен для physics.groucho.edu, показаны в примере 6-5.
Пример 6-5. Выдержка из файла named.hosts для GMU
; Zone data for the groucho.edu zone.
@ IN SOA vax12.gcc.groucho.edu. joe.vax12.gcc.groucho.edu. {
1999070100 ; 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
...
|
После обнаружения IP-адреса, принадлежащего хосту, иногда желательно выяснить каноническое имя хоста, соответствующее данному адресу. Это называется reverse mapping (обратное отображение) и используется несколькими сервисами, чтобы проверить идентичность клиента. При использовании файла hosts, обратный поиск заключается просто в проверке этого файла. В DNS, конечно, не проводится просмотр всего адресного пространсва. Вместо этого создана специальная область in-addr.arpa, она содержит IP-адреса всех хостов в перевернутой записи. Например, IP-адрес 149.76.12.4 соответствует имени 4.12.76.149.in-addr.arpa. Тип записи ресурса, связывающий это имя с каноническим именем, называется PTR.
Создание зоны полномочий обычно означает, что ее администраторам дают полный контроль над тем, как назначать адреса и имена хостов. Так как они обычно управляют одной или более 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 показана в примере 6-6. Соответствующие склеенные записи в базе данных зоны родителя показаны в примере 6-7.
Пример 6-6. Выдержка из файла named.rev для подсети 12
; the 12.76.149.in-addr.arpa domain.
@ IN SOA niels.physics.groucho.edu. janet.niels.physics.groucho.edu. {
1999090200 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.
|
Пример 6-7. Выдержка из файла named.rev для сети 149.76
; the 76.149.in-addr.arpa domain.
@ IN SOA vax12.gcc.groucho.edu. joe.vax12.gcc.groucho.edu. {
1999070100 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
...
|
Одно важное следствие этого то, что зоны могут создаваться только как наборы IP-сетей и даже более того, количество нулевых битов в маске подсети должно быть кратно 8. Все подсети в университете Groucho Marx имеют сетевую маску 255.255.255.0, так что зона in-addr.arpa может быть создана для каждой подсети. Однако, если сетевая маска будет 255.255.255.128, создание зон для подсети 149.76.12.128 будет невозможно, потому что нет никакого способа сообщить DNS, что область 12.76.149.in-addr.arpa была раздроблена на две зоны с именами хостов от 1 до 127 и от 128 до 255 соответственно.
| Назад | Глобальное оглавление | Вперед |
| Name Service and Resolver Configuration | Локальное оглавление | Running named |
