Доменное имя состоит, по меньшей мере, из двух частей (меток), разделенных точками. Нумерация меток ведется справа налево.. Все последующие метки - поддомены, т.е. hosting - поддомен домена web-3, а web-3 - домена ru.

Условно подобное деление может растянуться на 127 уровней. Любая метка может состоять (максимально) из 63 символов, но длина доменного имени не может быть больше 254 знаков, включая точки. Впрочем, действительность и теория, как известно, - разные вещи, посему регистраторы доменов часто устанавливают собственные лимиты.

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

Для передачи данных посредством стека протоколов TCP/IP необходимо знать IP-адрес указанного сервера, но тот, как правило, имеет лишь сведения об адресе сервера DNS (обычно интернет-провайдер предоставляет адрес одного основного и одного резервного DNS-сервера).. Тот, в свою очередь, запрашивает информацию у центрального сервера, например 195.42.0.3 (все IP-адреса приведены в качестве примера и могут отличаться от действительных). Сервер отвечает, что не обладает информацией о требуемом адресе, однако, знает, что доменной зоной.ru занимается сервер 214.74.142.1 (прим. ред. Это так называемый авторитетный сервер). В этом случае сервер DNS запрашивает информацию у 214.74.142.1. Ответом может быть: «web-3.ru занимается сервер 247.142.130.234». Этот третий по счету сервер возвращает браузеру IP-адрес нужного сайта (прим. ред. Очень часто рекурсивный подход заменяется запросами к буферу сервера. Если неавторитетный сервер недавно получал запрос на IP адрес сайт, то вместо обращения к следующему DNS серверу он выдаст результат из буфера. ).

Для реагирования на запрашиваемую информацию DNS-протокол применяет UDP- или TCP-порт 53. Обычно запросы и готовая информация по ним посылаются в форме UDP-датаграммы. А TCP остается для AXFR-запросов или ответов весом более 512 байт. Для того чтобы узнать IP-адрес интересующего вас сайта, необходимо воспользоваться командой ping. Если вы пользуетесь операционной системой Windows XP, нажмите «Пуск»- «Выполнить» (прим. ред. Сочетание клавиш win+r) и наберите в строке команду cmd . Появится окошко командной строки. В ней наберите команду ping и имя сайта, например, ping сайт. В строчках, которые появятся после нажатия Enter увидите группу чисел 87.242.76..

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

С целью увеличения стабильности системы в работу вводят определенное число серверов, которые вмещают в себя одинаковые сведения. Так, в мире насчитывается 13 подобных серверов. Каждый имеет отношение к какой-либо территории. Данные о них имеются во всякой операционной системе, поскольку такие серверы не изменяют первоначального адреса. Эти сервер называют корневыми, потому что на них держится вся сеть Интернет.

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

Известно доменное имя in-addr.arpa, данные которого служат для реконструирования IP-адреса в имя из символов. Приведем пример: чтобы выяснить имя известного адреса (предположим, 12.13.14.15) допустимо сделать запрос в следующем виде: 15.14.13.12.in-addr.arpa. Результатом окажется должное символьное имя. Чем можно это объяснить? Тем, что в IP-адресах биты, расположенные у корня, стоят в начале, а в DNS-именах – в конце.

Что касается записей DNS, то выделяют несколько категорий:

1. Address record (запись А) служит для связи адреса IP и хоста.
2. Canonical name record (сокращенно CNAME, каноническая запись имени) – инструмент переадресации на альтернативное имя.
3. Mail exchange (МХ, почтовый обменник) ссылается на сервер обмена почтой для представленного домена.
4. PTR (pointer, или запись указателя) соединяет имя хоста с его установленным (каноническим) именем.
5. NS (name server) называет DNS-сервер представленного доменного имени.
6. SOA (start of authority record) – запись, ссылающаяся на тот сервер, который содержит стандартные сведения о представленном домене.

Необходимо сказать о зарезервированных доменах (Reserved Top Level DNS Names). Документ RFC 2606 указывает на те имена доменов, которые нужно применять в роли модели (что особенно важно в документации) и при тестировании. В качестве примера можно привести test.com, test.org, test.net, а также invalid, example и т.д.

В разговоре о доменных именах стоит упомянуть о том, что они могут состоять из небольшой комплектации ASCII символов. Это делает возможным набор доменного адреса вне зависимости от того языка, на котором говорит пользователь. Потому такие имена – интернациональные. ICANN ратифицировал систему IDNA, базирующуюся на Punycode. Она способна конвертировать всякую фразу в кодировке Unicode в тот набор знаков, который будет возможен для корректной работы DNS.

Некоторые способы действия приложения DNS применяются в BIND (Berkeley Internet Name Domain), MaraDNS NSD (Name Server Daemon), DJBDNS (Daniel J. Bernstein"s DNS), PowerDNS Microsoft DNS Server (в серверных вариантах операционных систем Windows NT).

Чтобы узнать, кто владеет каким-либо доменом или IP-адресом достаточно использовать возможности сетевого протокола whois (от англ. who is - «кто?»). Первоначальной идеей, положившей начало созданию данной системы, было стремление не позволять системным администраторам находить данные иных администраторов IP-адресов и доменов. Ныне доменное имя признается незарегистрированным на определенное имя, пока нельзя найти общедоступные сведения о нем в этом сервисе.

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

DNS (Domain Name System - система доменных имен) представляет собой распределенную систему хранения и обработки информации о доменных зонах. Она необходима, в первую очередь, для соотнесения IP-адресов устройств в сети и более адаптированных для человеческого восприятия символьных имен. Предоставление информации об IP-адресах хостов по символьному адресу - не единственная задача DNS. Система работает с разными типами ресурсных записей, позволяющими реализовывать весьма широкий круг задач: переадресация между доменными именами, балансировка нагрузки между хостами, привязка специфических сервисов (напр., эл. почты) к домену.

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

DNS обеспечивает преобразование запрашиваемого клиентом символьного имени домена в IP-адрес (адреса) обслуживающего эту доменную зону сервера (серверов). Изначально, до разрастания сети интернет, адреса преобразовывались согласно содержимому файла "hosts", составлявшегося централизованно и автоматически рассылавшегося на каждую из машин в сети. По мере роста глобальной сети такой метод перестал оправдывать себя - появилась потребность в новом механизме, которым и стала DNS, разработанная в 1983 году Полом Мокапетрисом.

Ключевыми характеристиками DNS являются:

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

Иерархия и делегирование доменных имен

Домен представляет собой именованную ветвь в дереве имен, включающую в себя сам узел (напр., домен первого уровня ".com"), а также подчиненные ему узлы (напр., домен второго уровня "example.com", домен третьего уровня "mail.example.com" и т.д.). Для обозначения иерархической принадлежности доменных имен принято использовать понятие "уровень" - показатель положения узла в дереве доменов. Чем ниже значение уровня, тем выше иерархическое положение домена

• "." - домен нулевого уровня
• ".ru" - домен первого (верхнего) уровня
• "example.com" - домен второго уровня
• "mail.example.com" - домен третьего уровня
• Этот список можно продолжать

Обратите внимание на домен нулевого уровня "." (dot - точка) , также называемый корневым. На практике точку обычно не указывают ("example.com" вместо "example.com."), т.е. указание корневого домена не является обязательным условиям разрешения IP-адреса. Большинство клиентских программ (интернет-браузеров и т.д.) добавляют домен нулевого уровня автоматически и не отображают его пользователю. Доменное имя, не включающее обозначение домена нулевого уровня называется относительным, включающее же точку на конце - полностью определенным (FQDN - Fully Qualified Domain Name) .

Доменная зона - часть иерархического дерева доменных имен (напр. ".ru"), целиком переданная на обслуживание определенному DNS-серверу (чаще нескольким) с целью делегирования другому лицу ответственности за этот и все подчиненные домены ("anyaddress.ru", "any.anyaddress.ru").

Делегирование - передача ответственности за определенную ветвь дерева доменных имен другому физическому или юридическому лицу. Именно эта процедура практически реализует важный принцип работы DNS - распределенность хранения записей и обработки запросов. Сам процесс делегирования представляет собой добавление в ресурсные записи родительской зоны (".ru"), так называемых "склеивающих" ("glue") NS-записей для делегируемой дочерней зоны ("example.com"), указывающих на DNS-сервера принимающей домен стороны (например, DNS-сервера нашей компании). С этого момента все ресурсные записи домена второго уровня "example.com" и всех его дочерних доменов (например, "mail.example.com" и т.д.) хранятся на DNS-серверах этой компании, а родительская зона ".ru" хранит только указывающие на эти сервера NS-записи.

DNS-сервер - хост, хранящий ресурсные записи и обрабатывающий DNS-запросы. DNS-сервер может самостоятельно разрешать адреса, относящиеся к зоне его ответственности (в примере выше это зона example.com), или передавать запросы по зонам, которые он не обслуживает, вышестоящим серверам.

DNS-клиент - набор программных средств для работы с DNS. Сам DNS-сервер периодически также выступает в качестве клиента.

Основные типы ресурсных записей

Ресурсная запись (RR - Resource Record) - единица хранения и передачи информации в DNS, включающая в себя следующие элементы (поля):

• Имя (Name) - имя домена, к которому относится запись
• TTL (Time To Live) - допустимое время хранения записи неответственным сервером
• Тип (Type) - параметр, определяющий назначение и формат записи в поле данных (Rdata)
• Класс (Class) - тип сети передачи данных (подразумевается возможность DNS работать с типами сетей, отличных от TCP/IP)
• Длина поля данных (Rdlen)
• Поле данных (Rdata) - содержание и формат поля зависят от типа записи

Ниже представлены типы ресурсных записей, используемые чаще всего:

• A (IPv4 Address Record - адресная запись) - связывает доменное имя с IPv4-адресом хоста
• AAAA (IPv6 Address Record) - связывает доменное имя с IPv6-адресом хоста (аналогично А-записи)
• CNAME (Canonical Name Record - каноническая запись имени) - используется для перенаправления на другое доменное имя
• MX (Mail Exchange - почтовый обменник) - ссылается на почтовый сервер, обслуживающий домен
• NS (Name Server - сервер имен) - ссылается на DNS-сервер, ответственный за домен
• TXT - текстовое описание домена. Зачастую требуется для выполнения специфических задач (например, подтверждения права собственности на домен при привязке его к почтовому сервису)
• PTR (Point to Reverse - запись указателя) - связывает ip-адрес машины с доменом, используется преимущественно для проверки сторонними почтовыми сервисами отправляемых через эту машину электронных писем на отношение к домену, указанному в параметрах почтового сервера. При несоответствии этих параметров письмо проверяется более тщательно по другим критериям.

Рекурсивные и нерекурсивные DNS-запросы

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

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

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

Служба Доменных Имен предназначена для того, чтобы машины, работающие в Internet, могли по доменному имени узнать IP-адрес нужной им машины, а также некоторую другую информацию; а по IP-номеру могли узнать доменное имя машины.

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

Каждый клиент знает своего сервера; обычно указывается не один, а несколько серверов - если первый не отвечает, клиент обращается ко второму и так далее до исчерпания списка. В принципе неважно, к какому серверу обращаться - они дают (должны давать при правильном функционировании) одинаковые ответы на любой запрос. Поэтому для ускорения работы обычно указывают ближайший. Следует помнить, что на одной машине могут функционировать одновременно Name-сервер и программы-клиенты; поэтому если на машине запущен Name-сервер, то в качестве Name-сервера на ней должен быть прописан "я сам".

Имеется некий домен верхнего уровня, обозначаемый точкой: ".". Имеется девять серверов (по крайней мере на моем Name-сервере записано столько), которые отвечают за эту зону. Они не знают ни одного доменного имени - они только авторизуют серверы верхних зон. Серверы верхних зон тоже гнушаются хранить информацию о конкретных машинах и передают это право нижележащим серверам. Тут уже появляются первые упоминания о конкретных машинах, равно как и происходит авторизация нижележащих серверов.

Мне неизвестна ни одна машина с доменным именем из одного сегмента; очень редко используются доменные имена из двух сегментов; имена из трех и четырех сегментов составляют подавляющую долю всех имен Internet; имена из пяти сегментов встречаются довольно редко, а из шести и более мне неизвестны.

Допустим, клиент запросил адрес "www.организация.город.страна". Поиск информации по доменному имени происходит следующим образом:

1. Клиент спрашивает своего сервера.
2. Если тот является сервером данной зоны, то ответит, на чем все заканчивается.
3. Сервер спрашивает корневой сервер.
4. Тот не может ответить, потому что не знает; зато знает, какой сервер отвечают за зону "страна".
5. Сервер зоны "страна" тоже не может ответить, но знает, что нужно спросить сервер зоны "город.страна".
6. Тот в свою очередь отсылает запрос серверу зоны "организация.город.страна", который сообщит нужную информацию.

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

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

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

Хочу обратить особое внимание на сходство, различие и взаимодействие систем DNS и IP-маршрутизации. Как и IP-маршрутизация, DNS работает по принципу делегирования полномочий, но выделение доменных имен совершенно не зависит от выделения IP-адресов. Для примера рассмотрим домен freebsd.org. Это - домен организации, занимающейся распространением операционной системы FreeBSD Unix. FTP-сервер, содержащий дистрибутив операционной системы и множества утилит для нее, имеет копии в нескольких десятках стран. Имена серверов выглядят так:

Ftp.freebsd.org первичный сервер в США ftp.страна.freebsd.org основной сервер в стране ftpчисло.страна.freebsd.org дополнительный сервер в стране

• ftp.ru.freebsd.org соответствует ftp.ru
• ftp2.ru.freebsd.org соответствует ftp.gamma.ru
• ftp3.ru.freebsd.org соответствует ftp.chg.ru

Таким образом, машины, находящиеся в России оказались произвольно (по воле DNS-мастера из университета Bercley) включенными в домен freebsd.org; однако, они также состоят в своих зонах. Система DNS позволяет любому DNS-мастеру включить любой сервер в свою зону, хотя это включение никого ни к чему не обязывает.

Однако, некоторым сервисам этого недостаточно - так E-mail требует, чтобы машина, принимающая письмо, признала своим адрес, указанный в качестве пункта назначения. Протокол HTTP 1.1 (в 1.0 этого не было) требует, чтобы в HTTP-запросе указывался не путь к файлу, отсчитанный от корня сервера (хотя такие запросы тоже признаются), но и имя сервера; при этом сам сервер знает, какие имена - его, а остальные обрезает и обслуживает в соответствии с HTTP 1.0.

Делегирование зоны...in-addr.arpa дается только от провайдера вместе с IP-адресами. Собственно, это связано с предназначением ReverceDNS - сообщать доменное имя по IP-адресу. Наверняка мастер зоны freebsd.org держит Reverce-зону для IP-номеров, выделенных университету Bercley; но все эти серверы (кроме сервера, расположенного в университете) не входят в эту Reverce-зону, а значит, ему неподконтрольны.

Одна из проблем состит в том, что Reverce-зону можно выделить только на сеть класса A, B или C (на 16777216, 65536 или 256 адресов) и никак иначе. Можно получить правА на несколько зон одного или разных классов, но что делать тем, кому выделили меньше 256 адресов? А ведь в условиях исчерпания адресного пространства не редкость выделения пула уже на 16 адресов!

DNS-услуги Internet-провайдера

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

• делегирование зоны...in-addr.arpa клиентам, имеющим пул адресов, кратный 256.
• регистрация доменного имени клиента у держателя той зоны, в которой клиент хочет зарегистрироваться;
• поддержание вторичного сервера прямой и обратной DNS-зон клиента;
• поддержание первичного сервера этих зон, если клиент по какой-либо причине не поддерживает их сам (особенно это относится к случаю виртуальных зон и к случаю выделения малого пула адресов);

Если провайдер будет отказываться - сошлитесь на меня. :-)

Политика и стратегия назначения имен

Имена зон условно можно разделить на "организационные" и "географические". В высшей зоне зарегестрированы следующие "организационные" зоны:

Com commercial (коммерческие) edu educational (образовательные) gov goverment (правительственные) mil military (военные) net network (организации, обеспечивающие работу сети) org organization (некоммерческие организации)

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

Каждая страна (государство) имеет свой географический домен из двух букв:

Ae United Arab Emirates (Объединенные Арабские Эмираты) au Australia (Австралия) be Belgium (Бельгия) br Brazil (Бразилия) by Belarus (Белоруссия) ca Canada (Канада) ch Switzerland (Швейцария) cz Czech Republic (Чехия) de Germany (Германия) dk Denmark do Dominican Republic (Доминиканская республика) ee Estonia (Эстония) eo ??? es Spain (Испания) fi Finland (Финляндия) fr France (Франция) hu Hungary (Венгрия) il Israel (Израиль) in India (Индия) iz ??? jp Japan (Япония) kg Kyrgyzstan (Кыргызстан) kr South Korea (Южная Корея) kz Kazakhstan (Казахстан) lt Lithuania (Литва) lv Latvia (Латвия) mx Mexico (Мексика) nl Netherlands (Нидерланды) no Norway (Норвегия) nz New Zealand (Новая Зеландия) pl Poland (Польша) ro Romania (Румыния) ru Russia (Россия) si Slovenia (Словения) sk Slovak Republic (Словакия) su Soviet Union (Советский Союз - поддерживается, но не распределяется) ua Ukraine (Украина) uk United Kingdom (Соединенное Королевство ВеликоБритания / Англия) yu Yugoslavia (Югославия) za South Africa (Южная Африка)

Я перечислил отнюдь не все страны - кто хочет, может прислать мне другие названия.

В зонах государств опять же имеются "организационные" и "географические" зоны. "Организационные" в большинстве своем повторяют структуру "организационных" зон верхнего уровня, разве что вместо "com" используется "co". "Географические" выделяются городам, областям и т.п. территориальным образованиям. Непосредственно в тех и других размещаются домены организаций или домены персональных пользователей.

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

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

Имена "функциональные" вытекают из функций, выполняемых машиной:

Www HTTP (WWW) сервер ftp FTP сервер ns, nss, dns DNS (Name) сервер mail Mail сервер relay Mail Exchanger *proxy соответствующий Proxy сервер

Я считаю нежелательным присваивать какой-либо машине функциональное имя - в любой момент может потребоваться перенести соответствующую функцию на другую машину. Для этого лучше всего использовать псевдонимы, которые перенаправляют запросы к данному имени на записи, относящиеся к другому имени. Но вот ссылаться на псевдонимы при обьявлении Mail Exchanger"ов и вообще использовать их в правой части записей считается нежелательным, а зачастую является недопустимым

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

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

При рассмотрении различных протоколов и служб TCP/IP Прикладного уровня, мы будем ссылаться на стандартные номера портов TCP и UDP, которые обычно связаны с этими службами. Некоторые из этих служб:

• Система Доменных Имен ( DNS) - TCP/UDP Порт 53
• Протокол Передачи Гипертекста (HTTP) - TCP Порт 80
• Простой Протокол Передачи Почты (SMTP) - TCP Порт 25
• Протокол Почты ( POP) - TCP Порт 110
• Telnet - TCP Порт 23
• Протокол Динамической Конфигурации Хостов - UDP Порты 67 и 68
• Протокол Передачи Файлов (FTP) - TCP Порты 20 и 21

DNS

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

В Интернете эти доменные имена, такие как yandex.ru, людям гораздо легче запомнить, нежели 213.180.193.11, что является фактическим числовым адресом для этого сервера . Кроме того, если адрес сайта google.ru вдруг поменяется, это произойдет незаметно для пользователя, поскольку доменное имя по прежнему останется yandex.ru. Новый адрес просто будет привязан к существующему доменному имени и возможность захода на сайт не пострадает. Когда сети были небольшими, поддержка соответствия между доменными именами и адресами, которые они представляют, была простой задачей. Однако, как только сети начали расти, а количество устройств увеличиваться, эта ручная система стала неработоспособной.

DNS (Domain Name System ) – служба имен, предназначена для автоматического поиска IP-адреса по известному символьному имени узла. Спецификация DNS определяется стандартами RFC 819, 1034 и 1035.

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

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

Все DNS-серверы соединены иерархически, в соответствии с иерархией доменов сети Internet. Клиент опрашивает эти серверы имен, пока не найдет нужные отображения.

База данных DNS имеет структуру дерева, называемого доменным пространством имен, в котором каждый домен (узел дерева) имеет имя и может содержать поддомены. Имя домена идентифицирует его положение в этой базе данных по отношению к родительскому домену, причем точки в имени отделяют части, соответствующие узлам домена.

Корень базы данных DNS управляется центром Internet Network Information Center.

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

com – коммерческие организации (например, microsoft.com);

edu – образовательные (например, mit.edu);

gov – правительственные организации (например, nsf.gov);

org – некоммерческие организации (например, fidonet.org);

net – организации, поддерживающие сети (например, nsf.net).

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

Для преобразования имен в IP-адреса также можно использовать файл hosts . В файле hosts содержится список всех имен хостов и соответствующих им адресов, например,

102.54.94.45 rhimo.acme.com

127.0.0.1 localhost

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

Для разрешения имени DNS-клиент сначала обращается к файлу hosts, затем формирует запрос к своему DNS-серверу. DNS-сервер пытается разрешить полученный запрос, в случае невозможности разрешения обращается к DNS-серверу более высокого уровня, который, в свою очередь, обращается далее и т.д. Если IP-адрес найден, то он возвращается клиенту, иначе происходит тайм-аут (признак ошибки).