Разрешенные домены. Домен — что это такое и как устроена доменная система имен

Если вы запускаете бизнес и хотите сделать его прибыльным, без качественного продающего веб-ресурса вам просто не обойтись. После того, как вы придумали отличное доменное имя для вашего сайта , и дело дошло до регистрации в доменной зоне, вам необходимо выбрать подходящую из десятков предложенных. В том случае, если вы не знаете, в чем разница между info.kz , com.kz и org.kz , что лучше для вашего веб-ресурса — .ru , .biz или .com , существует ли вообще какое-либо различие между всеми доменными зонами, эта статья будет для вас крайне полезной.

1. Что значит «доменная зона» и «домен первого, второго и третьего уровня»?

Наверняка вы не раз сталкивались с понятием «домен первого (второго, третьего) уровня». Чтобы проще объяснить, что это значит, рассмотрим пример: vashsite.com — это домен второго уровня, где доменом первого уровня (а это и есть доменная зона) является окончание после точки — com . При добавлении еще одного слова (например, vashsite.com.ua ) получается домен третьего уровня (поддомен). По такому же принципу формируются домены четвертого уровня (например, images.vashsite.com.ua ), однако встречаются они крайне редко.

2. Какие существуют доменные зоны?

Доменная зона определяет принадлежность домена второго (третьего, четвертого) уровня к стране или роду деятельности сайта. В связи с этим выделяют:

Международные доменные зоны (.info, .com, .biz и пр.)

• .com — домен общего назначения (common). Изначально был предназначен для коммерческих (commercial) организаций, однако не имел соответствующих ограничений и со временем утратил свое предназначение;
• .net — как правило, его выбирают организации, предоставляющие сетевые услуги;
• .biz — ранее его аналогом была зона.com (до того, как утратила свое предназначение). Сегодня сайты на.biz выбирают любые коммерческие организации;
• .info — подходит для справочных и информационных порталов, блогов и домашних страниц;
• .org — предназначен для сайтов некоммерческих организаций.

Тематические доменные зоны (.tv, .fm и пр.)

Их выбор обусловлен тематической направленностью веб-ресурса:

• .tv — предназначен для сайтов телеканалов, телевизионных трансляций и т.п.;
• .fm — в этой зоне принято регистрировать веб-ресурсы радиостанций;
• .travel — предназначен для компаний, работающих в сфере туризма.

Придерживайтесь простого правила: регистрируйте домен в соответствующей его назначению тематической зоне . Например, если вы создаете информационный портал, выбирайте зону .info , а для сайта коммерческой организации отличным вариантом станет .biz .

Региональные и субрегиональные доменные зоны (.ru, .by, .de и пр. — обозначают принадлежность к стране, .spb.ru, kiev.ua — к региону):

• .ru, .рф — Россия;
• .ua — Украина;
• .by — Беларусь;
• .kz — Казахстан;
• .de — Германия;
• .fr — Франция;
• .su — (Soviet Union) — страны бывшего СССР (сегодня его используют в основном СНГ и Балтия).
• .eu — Евросоюз;
• .msk.ru — Москва;
• .spb.ru — Санкт-Петербург.

Если сайт будут посещать в основном люди из Беларуси или организация ведет деятельность в этой стране, то лучшим вариантом для адреса веб-ресурса будет зона.by. Хотите подчеркнуть принадлежность к конкретному городу, например, Санкт-Петербургу — регистрируйтесь в зоне.spb.ru. Для компании, деятельность которой ориентирована на людей из России, отличным выбором будет и зона.рф. Сомневаетесь, стоит ли регистрироваться в доменной зоне.рф? Обязательно почитайте нашу статью по этой теме .

Регионально-тематические доменные зоны

• .edu.ru — может быть использован при создании сайтов учебных заведений России;
• .pp.ua — («pp» —«private person» или «private page») — отлично подходит для личных страничек и блогов;
• .co.ua — является аналогом украинского домена.com.ua, относится к категории общего назначения и не ограничивается особыми требованиями.

3. Можно ли выбрать любую доменную зону?

В целом — да. Однако при выборе стоит учитывать, что одни домены первого уровня требуют для регистрации соответствия заявленной тематике, другие — доступны для всех желающих. Поэтому зарегистрировать сайт лучше в зоне, которая поможет пользователям понять, о чем ресурс.

4. Международный или региональный домен первого уровня?

Для решения этого вопроса следуйте простому правилу: если аудитория или деятельность вашей компании не ограничиваются одной страной, вы можете зарегистрировать домен в международной зоне, например, .biz. В том случае, если вы хотите представить проект населению своего государства, то лучше использовать зону вашей страны, например.kz или.org.kz.

5. Как выбрать домен для сайта узконаправленной тематики?

При создании сайта узконаправленной тематики, например, по садоводству, вы можете поискать подходящую доменную зону в интернете. Сделать это очень просто. Наберите в поисковике ключевые слова («садоводство») и посмотрите, какие домены первого уровня имеют сайты на первых двух страницах.

Надеемся, что в данной статье вы нашли все ответы на ваши вопросы по данной теме. Если вы являетесь владельцем бесплатного сайта на сайт и он имеет вид vashsite.сайт , рекомендуем вам купить домен второго уровня, который сделает ваш ресурс в глазах потенциальных клиентов более представительным.

Создайте сайт на сайт за 5 минут, выберите подходящий домен и продвигайте ваш бизнес в сети!

Решив открыть свой сайт, многие люди сталкиваются с вполне очевидной проблемой: доменные имена, которые они с таким трудом придумали, оказываются заняты другими, более расторопными пользователями. Запрет на использование одинаковых адресов в одной доменной зоне, разумеется, весомый, однако далеко не единственный. Поэтому давайте разберемся, с какими еще трудностями можно столкнуться при регистрации домена, и можно ли их как-то избежать.

Ограничение 1: техническое

Если вы когда-нибудь пытались создать в Windows папку с «/» (или рядом других символов) в названии, то должны знать, что система не позволяет этого сделать из-за прописанных в ней алгоритмов. Аналогичная ситуация и с доменными зонами. В них нельзя регистрировать адреса:

Длиною меньше 2 символов и больше 255 символов. При этом длина части между двумя разделительными точками не должна превышать 63 знака.

С запрещенными символами, которые не относятся к буквам и цифрам, за исключением знака «-».

Противоречащие индивидуальным правилам конкретно взятой зоны. Например, в зонах BIZ, DE, INFO, SU и ряде других допустимый минимум символов – 3, а не 2.

Ограничение 2: коммерческое

Если вы зарегистрируете доменное имя, которое будет отличаться от адреса какой-нибудь крупной корпорации лишь зоной или одним символом, будьте готовы потерять его. Ведь для этого вашему оппоненту достаточно будет просто подать на вас в суд. О подобной практике мы уже подробно рассказывали , поэтому подробно на том вопросе останавливаться не будем.

Ограничение 3: законодательное

Государственные законодательные акты содержат запреты, касающихся отдельных социальных аспектов. И если ранее домен использовался для преступных целей, он вполне может оказаться в стоп-листе постоянного ограничения доступа, согласно ФЗ №149 от 27.07.2006 г.Также, если в названии вашего ресурса будет содержаться призыв к экстремизму, пропаганда гомосексуализма или другие запрещенные в РФ темы, роскомнадзору для блокировки этого будет достаточно (даже если сам ресурс посвящен разведению котят или выращиванию ромашек). А в Великобритании при выборе домена второго уровня вам придется учитывать специфику своего дела (.co.uk разрешен для коммерческих организаций, .me.uk – для физических лиц и т.п). Потому при выборе доменного имени необходимо учитывать еще и его смысловой вес, о чем более подробно упомянуто будет ниже.

Ограничение 4: финансовое

Цены на доменные имена существенно разнятся не только в разных доменных зонах (безусловными лидерами среди которых выступают com, .net и.org) , но и в рамках одной зоны. Связано это, как правило:

С популярностью домена. Легкие для запоминания (созвучные словам) адреса всегда стоят дороже случайного набора букв.

Длины адреса. Короткие домены проще для восприятия и запоминания, а потому дороже.

Со смыслом. Если доменное имя является «говорящим» (не простым словом, а охватывающее какую-то большую отрасль), цена его априори будет выше.

Ограничение 5: социальное

Данный пункт не так распространен, как вышеупомянутые, однако также имеет место быть. При выборе доменного имени (особенно короткого) приходится учитывать его смысловой вес. Так, сократив в адресной строке для удобства название своего Большого Демократического Сообщества Мастеров до «БДСМ», вы рискуете вызвать у пользователей невольные ассоциации с одноименной психосексуальной субкультурой.

Еще один негативный вариант – аббревиатура с сокращенным названием компании, которая в английском языке является каким-то словом. Благодаря ему в сети встречаются сокращения вроде WC, которое авторы расшифровывают, как World Company, однако люди ассоциируют с обозначением туалетных кабинок. Как итог – упущенная прибыль, ведь доверять свои деньги «туалетным» фирмам решаются далеко не все.

Как видите, ограничений при выборе доменного имени достаточно много. А потому, если не хотите проблем в дальнейшем, уделите этому вопросу как можно больше внимания. Проверьте значение будущего адреса в поисковых системах, его «чистоту» с помощью сервиса . И только когда убедитесь, что выбранный вами адрес не противоречит ни одному из описанных выше пунктов, регистрируйте его.

Приветствую, дорогие читатели! В этой статье я постараюсь простыми словами вам рассказать, что такое домен и зачем он нужен. А также, для тех, кто собирается запускать свой сайт в интернете, дам несколько дополнительных инструкций, которые нужно знать обязательно.

Если вы сейчас перейдёте на главную страницу блога и посмотрите в браузерную строку, то увидите следующее.

Этот адрес и называется полным доменным именем сайта. В браузере, который вы используете, данный адрес может выглядеть иначе.

• . Многие современные браузеры его скрывают.

Префиксы http , https и www к доменам никак не относятся.

Доменное имя можно сравнить с адресом любого дома в мире. Зная адрес, вы сможете найти нужный дом.

В принципе, обычному пользователю большего и знать не нужно. Надеюсь, я ответил на ваш вопрос.

Теперь давайте разберёмся на более продвинутом техническом уровне.

Определение не для чайников

Начну с аналогии. У каждого места на нашем земном шаре есть свои координаты, по которым оно расположено. Вот, например, мы пару дней назад проезжали Волгоград и посетили там знаменитое место Мамаев курган с высочайшим памятником России и Европы “Родина-мать зовёт!”, который расположен по координатам 48°44′32″N, 44°32′14″E48.742286, 44.537112.

Естественно, мы не искали это место по его координатам, а искали по названию.

Точно также происходит в глобальной сети интернет, каждое место (пространство), где хранятся данные сайтов, имеет свой IP-адрес (уникальный сетевой адрес). Таким образом, вы можете попасть на сайт не только по домену, но и по его IP-адресу.

Например, если вы введёте в адресной строке браузера следующий IP-адрес 93.158.134.3, то откроется главная страница Яндекса. Но иногда на одном таком адресе могут храниться несколько сайтов, и, чтобы пользователь смог попасть на нужный ему ресурс, используются уникальные доменные имена в удобной человеческой форме.

Это как квартиры в доме по одному адресу.

Структура доменного имени

Все доменные имена состоят из областей — доменов (с англ. domain переводится, как область, территория).

Каждое имя включает в себя домен верхнего (первого) уровня, по нему принято определять зону. В моём случае это — “ru”. Далее идёт мой уникальный домен второго уровня “iklife”..сайт.

Получается, что в этой доменной зоне уже никто, кроме меня, не может расположить свой сайт, он принадлежит только мне.

Опять же, по аналогии они имеют подобную структуру: страна, район, город, улица и т. д.

Согласно руководящим материалам (RFC-1034, RFC-1035) система доменных имен состоит из трех основных частей:

• Всего множества доменных имен (domain name space)
• Серверов доменных имен (domain name servers)
• Клиенты DNS (Resolver-ы)

Множество доменных имен было подробно рассмотрено в материале "Доменная адресация. Немного истории и принципы построения", поэтому сосредоточимся на двух оставшихся компонентах серверах и resolver-ах.

Сервис системы доменных имен строится по схеме "клиент-сервер". В качестве клиентской части выступает прикладной процесс, который запрашивает информацию о соответствии имени адресу (или наоборот адреса имени). Это программное обеспечение и называют resolver. В качестве сервера выступает прикладная программа-сервер.

Чаще всего, Resolver не является какой-либо программой или системной компонентой. Это набор процедур из библиотеки прикладного программного обеспечения (например, из библиотеки libc), которые позволяют программе, отредактированной с ними, выполнять запросы к системе доменных имен и получать ответы на них. Эти процедуры обращаются к серверу доменных имен и, таким образом, обслуживает запросы прикладных программ пользователя.

Ряд производителей операционных систем, например, Sun или SGI, предлагали решения, в которых resolver являлся отдельным процессом, и прикладные программы через него реализовывали взаимодействие с DNS.

Другой пример реализации resolver-а - это браузеры Nescape некоторых версий, где для ускорения процесса получения ответов на запросы к DNS запускался отдельный процесс resolver-a.

Самостоятельный resolver может быть собран и в BIND версии 9. Это так называемый lightweight resolver. Он состоит из rosolver-демона и библиотеки взаимодействия с этим демоном, процедуры которой линкуются с прикладным ПО. Данный resolver позволяет не только посылать запросы к серверу доменных имен, но кэшировать соответствия между доменным именем и IP-адресом.

В качестве серверов доменных имен чаще всего используются различные версии BIND (Berkeley Internet Name Domain). Если сервер реализован на платформе Windows, то тогда используют решение от Microsoft, хотя для этой платформы также существуют версии BIND.

Общую схему взаимодействия различных компонентов системы доменных имен можно изобразить так, как это представлено на следующем рисунке:

Рис1. Рекурсивный запрос resolver и нерекурсивная (итеративная) процедура на разрешение доменного имени сервером доменных имен.

Данная схема разрешения имени (установки соответствия между именем и IP-адресом) называют нерекурсивной (итеративной). Чем она отличается от рекурсивной мы обсудим позже.

Поясним приведенную схему нерекурсивной процедуры разрешения запроса:

1. Прикладная программа через resolver запрашивает IP-адрес по доменному имени у местного сервера (запрос resolver рекурсивный, т.е. resolver просит server найти ему адрес).
2. Местный сервер сообщает прикладной программе IP-адрес запрошенного имени, выполняя при этом нерекурсивный опрос серверов доменных имен. При этом:
   1. если адрес находится в зоне его (местного сервера) ответственности, сразу сообщает его resolver-у,
   2. если адрес находится в зоне ответственности другого сервера доменных имен, то обращается к корневому серверу системы доменных имен за адресом TLD-сервера (top-level domain server),
   3. обращается к TLD-серверу за адресом,
   4. получает от него адрес удаленного сервера,
   5. обращается к удаленному серверу за адресом,
   6. получает от удаленного сервера адрес,

В данном случае мы рассмотрели вложенность доменного имени второго порядка., т.е. хост имел имя похожее на quest.kuku.ru или даже kuku.ru.

Последнее важно понять, т.к. корпоративные почтовые адреса типа [email protected] как раз и требуют от прикладного программного обеспечения обращения за IP-адресом хоста kuku.ru. TLD-сервер домена ru не обладает информацией о том, какому IP-адресу данное имя соответствует, но при этом он знает какой сервер отвечает за домен kuku.ru.

Если вложенность доменного имени будет большей, скажем третьего уровня (host.department.corp.ru), и этот уровень будет поддерживаться другим сервером доменных имен, отличным от того, который поддерживает второй уровень вложенности, то тогда нашему локальному серверу удаленный сервер доменных имен передаст не адрес хоста, а адрес нового сервера доменных имен, в зоне ответственности которого находится запрашиваемое имя.

Как видно из приведенной схемы, получение информации из системы доменных имен - это многоходовой процесс, который не реализуется мгновенно. В следующем примере показано как на практике ощущается работа DNS.

При входе в режиме удаленного терминала на компьютер polyn.net.kiae.su по команде:

/usr/paul>telnet polyn.net.kiae.su

Мы получаем в ответ:

/usr/paul>telnet polyn.net.kiae.su trying 144.206.130.137 ... login: .....

Строчка, в которой указан IP-адрес компьютера polyn.net.kiae.su, показывает, что к этому времени доменное имя было успешно разрешено сервером доменных имен и прикладная программа, в данном случае telnet получила на свой запрос IP-адрес. Таким образом, после ввода команды с консоли, и до появления IP-адреса на экране монитора прикладная программа осуществила запрос к серверу доменных имен и получила ответ на него.

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

Другой пример того же сорта - это программа traceroute. Здесь задержка на запросы к серверу доменных имен проявляется в том, что время ответов со шлюзов, на которых "умирают" ICMP пакеты, указанное в отчете, маленькое, а задержки с отображением каждой строчки отчета довольно большие.

Любопытно, что в системе Windows 3.1 некоторые программы трассировки, показывали сначала IP-адрес шлюза, а только потом, после разрешения "обратного" запроса, заменяли его на доменное имя шлюза. Если сервис доменных имен работал быстро, то эта подмена была практически незаметна, но если сервис работал медленно, то промежутки бывали довольно значительными.

Проверить на сколько "чувствительны" запросы traceroute c точки зрения отображения трассы к использованию сервера доменных имен можно задав поиск трассы с использованием сервера:

и без использования сервера:

Если в примере с telnet и ftp мы рассматривали, только "прямые" (forward) запросы к серверу доменных имен, то в примере с traceroute мы впервые упомянули "обратные"(reverse) запросы. В "прямом" запросе прикладная программа запрашивает у сервера доменных имен IP-адрес, сообщая ему доменное имя. При "обратном" запросе прикладная программа запрашивает доменное имя, сообщая серверу доменных имен IP-адрес.

Следует заметить, что скорость разрешения "прямых" и "обратных" запросов в общем случае будет разная. Все зависит от того, где описаны "прямые"(forward) и "обратные"(reverse) зоны в базах данных серверов доменных имен, обслуживающих соответствующие домены (прямой и обратный).

Более подробно этого вопроса мы коснемся при обсуждении файлов конфигурации программы named.

Однако вернемся к обсуждению схемы работы системы доменных имен. Собственно нерекурсивным рассмотренный выше запрос является только с точки зрения сервера. С точки зрения resolver-а процедура разрешения запроса является рекурсивной, так как resolver перепоручил локальному серверу доменных имен заниматься поиском необходимой информации. Согласно RFC-1035, resolver и сам может опрашивать удаленные серверы доменных имен и получать от них ответы на свои запросы.

В этом случае resolver обращается к локальному серверу доменных имен, если не получает от него адреса, то опрашивает сервер корневого домена, получает от него адрес удаленного сервера TLD, опрашивает этот сервер, получает адрес удаленного сервера, опрашивает удаленный сервер и получает IP-адрес, если он посылал, так называемый "прямой" запрос.

Рис.2. Нерекурсивный запрос resolver-а.

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

Локальный сервер и resolver не все запросы выполняют по указанной процедуре. Дело в том, что существует кэш, который используется для хранения в нем полученной от удаленного сервера информации.

Самые умные resolver-ы, такие, например, как resolver Windows 2000 Server и BIND 9 умеют поддерживать кэш, в котором сохранияют не только удачно установленные соответствия имени и адреса (positive response), но и так называемые "негативные" отклики (negative response results) на запросы. Кроме того, эти resolver-ы упорядочивают отклики об адресах серверов в соответствии с принятыми в них (resolver-ах) алгоритмами выставления предпочтений, которые базируются на времени отклика сервера.

Рис.3. Схема разрешения запросов с кэшированием ответов.

Если пользователь обращается в течение короткого времени к одному и тому же ресурсу сети, то запрос на удаленный сервер не отправляется, а информация ищется в кэше.

Вообще говоря, прядок обработки запросов можно описать следующим образом:

1. поиск ответа в локальном кэше
2. поиск ответа на локальном сервере
3. поиск информации в сети.

При этом кэш может быть как у resolver-а, так и у сервера.

Между доменом и зоной существует разница, которую бывает трудно найти, но всегда нужно иметь в виду. Домен - это все множество машин, которые относятся к одному и тому же доменному имени. Например, все машины, которые в своем имени имеют постфикс kiae.su относятся к домену kiae.su. Зона - это "зона ответственности" конкретного сервера доменных имен, т.е. понятие домена шире, чем понятие зоны. Если домен разбивается на поддомены, то у каждого из них может появиться свой сервер. При этом зоной ответственности сервера более высокого уровня будет только та часть описания домена, которая не делегирована другим серверам. Разбиение домена на поддомены и организация сервера для каждого из них называется делегирование прав управления зоной соответствующему серверу доменных имен, или просто делегированием зоны.

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

Существует еще и другой вариант работы сервера, когда он не запрашивает корневой сервер на предмет адреса удаленного сервера доменных имен. Это происходит тогда, когда незадолго до этого сервер уже разрешал задачу получения IP-адреса из того же домена. Если требуется получить IP-адрес удаленного сервера доменных имен, отвечающего за домен, то он будет просто извлечен из буфера сервера (кеша), т.к. в течение определенного времени, заданного в конфигурации описания зоны (Time To Live - TTL), этот адрес будет храниться в кэше сервера. А попал он туда как результат выполнения предыдущего запроса.

Кроме нерекурсивной процедуры разрешения имен возможна еще и рекурсивная процедура разрешения имен. Ее отличие от описанной выше нерекурсивной процедуры состоит в том, что удаленный сервер сам опрашивает свои серверы зон, а не сообщает их адреса местному серверу доменных имен. Рассмотрим этот случай более подробно.

На рисунке 4 продемонстрирована нерекурсивная процедура разрешения IP-адреса по доменном имени. Основная нагрузка в этом случае ложится на местный сервер доменных имен, который осуществляет опрос всех остальных серверов. Для того, чтобы сократить число таких обменов, если позволяет объем оперативной памяти, можно разрешить буферизацию (кэширование) адресов. В этом случае число обменов с удаленными серверами сократится.

На рисунке 5 удаленный сервер домена сам разрешает запрос на получение IP-адреса хоста своего домена по рекурсивному запросу, используя при этом нерекурсивный опрос своих серверов поддоменов.

Рис 4. Нерекурсивная обработка запроса местным сервером доменных имен на получение IP-адреса по доменному имени.

Рис. 5. Рекурсивная (для местного сервера) и нерекурсивная (для удаленного сервера) процедуры разрешения адреса по IP-имени.

При этом локальный сервер сразу получает от удаленного адрес хоста, а не адреса серверов поддоменов. Удаленному серверу при этом должно быть разрешено обслуживание рекурсивных запрос с соответствующего IP-адреса, местный сервер должен обратиться к удаленному с рекурсивным запросом.

Представленные здесь варианты работы системы доменных имен не являются исчерпывающими. За более подробной информацией следует обращаться к RFC-1034 и RFC-1035.

1. P. Mockapetris. RFC-1034. DOMAIN NAMES - CONCEPTS AND FACILITIES. ISI, 1987. (http://www.ietf.org/rfc/rfc1034.txt?number=1034)
2. P. Mockapetris. RFC-1035. DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION. ISI, 1987. (http://www.ietf.org/rfc/rfc1035.txt?number=1035)
3. Альбитц П., Ли К.. DNS и BIND. - Пер. с англ. - СПб: Символ-Плюс, 2002. - 696 с.

1. http://www.microsoft.com/windows2000/en/server/help/sag_DNS_und_HowDnsWorks.htm?id=1945 - Документация Microsoft по Windows 2000 Server. Раздел посвящен принципам работы системы доменных имен. Описывает общие принципы построения DNS и взаимодействия resolver и серверов.
2. http://www.microsoft.com/windows2000/en/server/help/sag_DNS_ovr_ClientFeatures.htm?id=1942 - Документация Microsoft по Windows 2000 Server. Раздел посвящен принципам работы resolver.
3. - Документация по BIND 9. Справочное руководство системного администратора. Нужно ознакомиться с разделом, посвященном lightweight resolver.
4. http://www.igc.ru/cgi-bin/man-cgi?traceroute - описание команды traceroute, раз уж ее здесь упомянули.
5. http://www.menandmice.com/online_docs_and_faq/glossary/glossarytoc.htm - глоссарий терминов DNS.