Главная › Настройки › Какой сетевой протокол использует dns. DNS-сервер: назначение и основные принципы работы. Как работает DNS и причем тут файл Hosts

Какой сетевой протокол использует dns. DNS-сервер: назначение и основные принципы работы. Как работает DNS и причем тут файл Hosts

DNS использует протокол транспортного уровня UDP. При этом для DNS запроса и для DNS отклика используется одинаковый формат:

Структура пакета запроса DNS.

Поля запроса имеют следующее назначение.

Значение в поле идентификации (identification) устанавливается клиентом и возвращается сервером. Это поле позволяет клиенту определить, на какой запрос пришел отклик.

Поле флагов предназначено для настройки типа запроса. Назначение битовых полей, начиная с левого, следующее.

QR (тип сообщения), 1-битовое поле: 0 обозначает - запрос, 1 обозначает - отклик.

opcode (код операции), 4-битовое поле со следующими значениями:

0 (стандартный запрос).

1 (инверсный запрос)

AA - 1-битовый флаг, который означает "авторитетный ответ" (authoritative answer). Сервер DNS имеет полномочия для этого домена в разделе вопросов.

TC - 1-битовое поле, которое означает "обрезано" (truncated). В случае UDP это означает, что полный размер отклика превысил 512 байт, однако были возвращены только первые 512 байт отклика.

RD - 1-битовое поле, которое означает "требуется рекурсия" (recursion desired). Бит может быть установлен в запросе и затем возвращен в отклике. Этот флаг требует от DNS сервера обработать этот запрос самому (т.е. сервер должен сам определить требуемый IP адрес, а не возвращать адрес другого DNS сервера), что называется рекурсивным запросом (recursive query). Если этот бит не установлен и запрашиваемый сервер DNS не имеет авторитетного ответа, запрашиваемый сервер возвратит список других серверов DNS, к которым необходимо обратиться, чтобы получить ответ. Это называется повторяющимся запросом (iterative query) .

RA - 1-битовое поле, которое означает "рекурсия возможна" (recursion available). Этот бит устанавливается в 1 в отклике, если сервер поддерживает рекурсию.

Это 3-битовое поле должно быть равно 0.

rcode это 4-битовое поле кода возврата. Обычные значения: 0 (нет ошибок) и 3 (ошибка имени- имени не существует на сервер домена).

Формат каждого вопроса в разделе вопросов (question) следующий: имя вопроса, тип вопроса/отклика, класс вопроса:

Имя запроса (query name) - это искомое имя. Оно выглядит как последовательность из одного или нескольких слов. Каждое слово начинается с 1-байтового счетчика, который содержит количество следующих за ним букв слова. Имя заканчивается байтом равным 0, который является словом с нулевой длиной и обозначает корень. Каждый счетчик байтов должен быть в диапазоне от 0 до 63, так как длина слова ограничена 63 байтами.

Каждый вопрос имеет тип запроса, каждый отклик содержит запись ресурса определенного типа.

Протокол работает с вопросами нескольких классов. Вопрос о IP адресе только один из вариантов:

Типы запросов
	Цифровое значение	Описание

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

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

Структура базы данных DNS.

Записи ресурсов, из которых составлена база DNS, разделяются по функциональным типам. Приведем некоторые из типов.

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

Протокол SMTP

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

Для обеспечения этих потребностей был разработан SMTP (Simple Mail Transfer Protocol) - простой почтовый протокол, описанный в RFC 821 . Формат сообщения электронной почты, которое передается между двумя MTA в соответствии с RFC 821 определяется в RFC 822 .

SMTP обеспечивает передачу почтовых сообщений между системами и уведомления о входящей почте. Обмен почтой с использованием TCP осуществляется посредством агентов передачи сообщений (MTA - message transfer agent). Пользователи обычно не общаются с MTA. Протокол определяет, как два MTA обмениваются сообщениями по TCP соединению.

При общении между двумя MTA используется NVT ASCII. Клиент подключается на порт 25 сервера, используя протокол telnet. Команды посылаются клиентом серверу, а сервер отвечает с помощью цифровых кодов и опциональных текстовых строк.

Команды SMTP представляют собой сообщения ASCII, передаваемые между хостами SMTP. Ниже приведен список поддерживаемых команд:

Команда	Описание
	Начинает сборку (composition) сообщения.
EXPN	Возвращает имена из указанного списка рассылок.
HELO	Возвращает идентификацию почтового сервера.
HELP	Возвращает информацию об указанной команду.
MAIL FROM	Инициирует почтовый сеанс с хоста.
	Нет операций кроме подтверждений от сервера.
	Прерывает почтовую сессию.
RCPT TO	Обозначает получателя почты.
	Сбрасывает (Reset) почтовое соединение.
SAML FROM	Передает почту на терминал пользователя и в почтовый ящик.
SEND FROM	Передает почту на терминал пользователя.
SOML FROM	Передает почту на терминал пользователя или в почтовый ящик.
	Меняет ролями отправителя и получателя.
VRFY	Проверяет идентификацию пользователя.

Электронное сообщение состоит из трех частей.

Конверт используется MTA для доставки. Конверт может быть определен двумя SMTP командами:

MAIL From [email protected] отправитель

RCPT To nil @ mail . ru - получатель

Заголовки используются пользовательскими агентами. Могут использоваться заголовки полей: Received, Message-Id, From, Date, Reply-To, To, Subject. Каждое поле заголовка содержит имя, после которого следует двоеточие, а затем следует значение этого поля. RFC 822 определяет формат и интерпретацию полей заголовка. Длинные поля заголовков могут быть разбиты на несколько строк, причем дополнительные строки начинаются с пробела.

Тело - это содержимое сообщения от отправителя к получателю. RFC 822 определяет тело сообщения как текстовые строки в формате NVT ASCII. Когда происходит передача содержимого с использованием команды DATA, заголовки передаются первыми, за ними следует пустая строка и затем следует тело сообщения. Каждая строка, передаваемая с использованием команды DATA, ограничена в длину 1000 байт.

Доставка сообщений происходит по следующей схеме. Пользовательский агент передает сообщение своему MTA. Агент по доменному имени в адресе получателя должен найти почтовый сервер MTA получателя. Для этого используются DNS-запросы типа MX, возвращающие для MTA отправителя доменное имя и адрес сервера, уполномоченного получать сообщения для домена получателя. RFC 974 описывает, как MTA обрабатывает записи MX. После этого MTA отправителя, выступая в качестве клиента, устанавливает telnet - соединение на 25 порт найденного сервера и передает ему сообщение. Если сервер, получивший сообщение, является сервером получателя, в этом случае получатель содержится в его базе абонентов. Сообщение записывается в почтовый файл абонента. Если сервер является сервером пересылки, процедура MX-запроса повторяется и сообщение передается по цепочке, пока не будет доставлено.

Для чтения сообщений в почтовом файле сервера абонент может использовать локальную утилиту почтового клиента или пользоваться удаленным доступом к почтовым файлам по протоколам POP3 или IMAP.

Добавить коротко про ARP/RARP

Помимо основных протоколов стек протоколов TCP/IP содержит большое количество вспомогательных и сопутствующих. Среди них: Dynamic Host Configuration Protocol (DHCP) - сервис, используемый для автоматического назначения IP-адресов хостам.

Windows Internet Name Service (WINS) - сервис, поддерживающий распределенную, динамически обновляемую базу имен хостов и соответствующих им IP-адресов

Domain Name System (DNS) - служба разрешения доменных имен, базовая для Интернета. В традиционной реализации DNS требует указывать статическое соответствие между именем хоста и его адресом. Так как служба DNS не динамична, изменения в базе данных DNS (например, при добавлении нового хоста или перемещении его в другую подсеть) необходимо делать вручную. В Windows NT Server 4.0 реализован полный сервер DNS, который интегрирован со службой WINS и снабжен графической утилитой администрирования. Объединение DNS и WINS позволяет создать некоторую форму динамического DNS. Это объединение поддерживается сервисом DNS, выполняемым на Windows NT Server 4.0. Теперь можно, обратившись к DNS, запросить у WINS имя нижнего уровня в дереве DNS.

DNS преобразует символические имена машин в IP-номера (IP-адреса), которые являются адресами машин и из IP-номеров (IP-адресов) в имена. Преобразование, в данном случае, это создание ассоциации между доменным именем и IP-номером. Так, например, имени www.gu.net соответствует IP-адрес 194.93.190.121. За эти преобразования несут ответственность name servers (сервера имен).

DNS-сервер (или сервер имен) - это программа (одна или несколько), обрабатывающая запросы типа:

"определить IP-адрес по имени",

"определить имя по IP-адресу",

"определить имя сервера, на который должна направлятся электронная почта для заданного домена",

"определить имя другого сервера имен, ответственного за заданный домен".

На одном компьютере может находится одновременно несколько серверов имен.

DNS имеет иерархическую древовидную структуру, "корнями" которой являются так называемые root-сервера . На root-серверах хранится информация о том, какие есть домены первого уровня (com, org, net, gov, ua, ru и другие) и ссылки на DNS-сервера отвечающие за эти домены.

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

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

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

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

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

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

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

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

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

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

Каждый домен DNS администрируется отдельной организацией, которая обычно разбивает свой домен на поддомены и передает функции администрирования этих поддоменов другим организациям. Каждый домен имеет уникальное имя, а каждый из поддоменов имеет уникальное имя внутри своего домена. Имя домена может содержать до 63 символов. Каждый хост в сети Internet однозначно определяется своим полным доменным именем (fully qualified domain name, FQDN) , которое включает имена всех доменов по направлению от хоста к корню. Пример полного DNS-имени: citint.dol.ru. Чтобы дать возможность шлюзам в интернете сообщать об ошибках или предоставлять информацию о нестандартных условиях работы, разработчики добавили механизм сообщений специального назначения в протоколы TCP/IP. Этот механизм, известный как Межсетевой Протокол Управляющих Сообщений(ICMP), считается необходимой частью IP и должен включаться в каждую реализацию IP.

Протокол обмена управляющими сообщениями ICMP (Internet Control Message Protocol) позволяет маршрутизатору сообщить конечному узлу об ошибках, с которыми машрутизатор столкнулся при передаче какого-либо IP-пакета от данного конечного узла.

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

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

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

Как и весь другой траффик, сообщения ICMP передаются по интернету в поле данных IP-дейтаграмм. Конечным назначением сообщений ICMP, тем не менее, является не прикладная программа или пользователь на машине назначения, а программное обеспечение IP на этой машине. То есть, когда прибывает сообщение ICMP об ошибке, его обрабатывает модуль программного обеспечения ICMP. Конечно, если ICMP определит, что ошибка была вызвана конкретным протоколом более высокого уровня или прикладной программой, он сообщит об этом соответствующему модулю. Т.о., Межсетевой Протокол Управляющих Сообщений позволяет шлюзам посылать управляющие сообщения или сообщения об ошибках на другие шлюзы или ГВМ; ICMP обеспечивает взаимодействие между программным обеспечением Межсетевого Протокола разных машин.

Являясь провайдером виртуальной инфраструктуры, компания 1cloud интересуется сетевыми технологиями, о которых мы регулярно рассказываем в своем блоге. Сегодня мы подготовили материал, затрагивающий тему доменных имен. В нем мы рассмотрим базовые аспекты функционирования DNS и вопросы безопасности DNS-серверов.

Также стоит пару слов сказать про процедуру обратного сопоставления – получение имени по предоставленному IP-адресу. Это происходит, например, при проверках сервера электронной почты. Существует специальный домен in-addr.arpa, записи в котором используются для преобразования IP-адресов в символьные имена. Например, для получения DNS-имени для адреса 11.22.33.44 можно запросить у DNS-сервера запись 44.33.22.11.in-addr.arpa, и тот вернёт соответствующее символьное имя.

Кто управляет и поддерживает DNS-сервера?

Когда вы вводите адрес интернет-ресурса в строку браузера, он отправляет запрос на DNS-сервер отвечающий за корневую зону. Таких серверов 13 и они управляются различными операторами и организациями. Например, сервер a.root-servers.net имеет IP-адрес 198.41.0.4 и находится в ведении компании Verisign, а e.root-servers.net (192.203.230.10) обслуживает НАСА.

Каждый из этих операторов предоставляет данную услугу бесплатно, а также обеспечивает бесперебойную работу, поскольку при отказе любого из этих серверов станут недоступны целые зоны интернета. Ранее корневые DNS-серверы, являющиеся основой для обработки всех запросов о доменных именах в интернете, располагались в Северной Америке. Однако с внедрением технологии альтернативной адресации они «распространились» по всему миру, и фактически их число увеличилось с 13 до 123, что позволило повысить надёжность фундамента DNS.

Еще один вариант – использование функции IP Source Guard. Она основывается на технологии uRPF и отслеживании DHCP-пакетов для фильтрации поддельного трафика на отдельных портах коммутатора. IP Source Guard проверяет DHCP-трафик в сети и определяет, какие IP-адреса были назначены сетевым устройствам.

После того как эта информация была собрана и сохранена в таблице объединения отслеживания DHCP-пакетов, IP Source Guard может использовать ее для фильтрации IP-пакетов, полученных сетевым устройством. Если пакет получен с IP-адресом источника, который не соответствует таблице объединения отслеживания DHCP-пакетов, то пакет отбрасывается.

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

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

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

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

Записи DNS бывают разных типов и содержат разную информацию. Основные записи, которые необходимо упомянуть, отображены в таблице 1.

Тип	Расшифровка	Описание
A	Address	Адресная запись, соответствие между именем и IP-адресом
CNAME	Canonical name	Каноническое имя для псевдонима (одноуровневая переадресация)
NS	Authoritative name server	Адрес узла, отвечающего за доменную зону. Критически важна для функционирования самой системы доменных имён
PTR	Domain name pointer	Реализует механизм переадресации
SOA	Start of authority	Указание на авторитетность информации, используется для указания на новую зону

Табл. 1. Основные ресурсные записи DNS

A запись содержит соответствие IP-адреса доменному имени. Используется при разрешении имени узла, например, когда браузеру требуется открыть веб-страницу (по доменному имени). В запросе указывается имя узла, а DNS-сервер в ответе отправляет IP-адрес этого узла, взятый из Aзаписи. В записи содержится IP-адрес.

CNAME записи позволяют задать «псевдоним» или «каноническое имя» для хоста, с целью привязать его не к конкретному IP-адресу, а сослаться на другой хост. Например, если узел имеет несколько доменных имён, достаточно указать одну Aзапись и ссылаться на неё. В записи содержится доменное имя.

NS записи служат для указания NS-серверов, обслуживающих данную зону и зоны следующего уровня. В записи содержится адрес ответственного DNS сервера.

PTR запись связывает IP хоста с его каноническим именем. Эта запись важна при пересылке почты. В целях уменьшения объема спама многие серверы-получатели электронной почты могут проверять наличие PTR записи для хоста, с которого происходит отправка. В этом случае PTR запись для IP адреса должна соответствовать имени отправляющего почтового сервера, которым он представляется в процессе SMTP сессии. Зачастую, провайдеры интернета создают для IP-адресов своих абонентов автоматически сгенерированные по определённому шаблону PTR-записи. Поэтому при настройке на одном из таких адресов почтового сервера наряду с регистрацией домена у регистратора доменных имён нужно изменять PTR запись на DNS сервере провайдера.

SOA запись содержит информацию о DNS-зоне (имя первичного DNS-сервера зоны, контактный адрес ответственного администратора файла зоны, настройки различных временных интервалов).

Доменное имя состоит, по меньшей мере, из двух частей (меток), разделенных точками. Нумерация меток ведется справа налево.. Все последующие метки - поддомены, т.е. 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, то выделяют несколько категорий:

Address record (запись А) служит для связи адреса IP и хоста.
Canonical name record (сокращенно CNAME, каноническая запись имени) – инструмент переадресации на альтернативное имя.
Mail exchange (МХ, почтовый обменник) ссылается на сервер обмена почтой для представленного домена.
PTR (pointer, или запись указателя) соединяет имя хоста с его установленным (каноническим) именем.
NS (name server) называет DNS-сервер представленного доменного имени.
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-адресов и доменов. Ныне доменное имя признается незарегистрированным на определенное имя, пока нельзя найти общедоступные сведения о нем в этом сервисе.