Описание протокола DNS (Domain Name System). Как работает DNS (domain name system)

Что такое DNS

DNS (domain name system) - это система, обеспечивающая работу привычных нам доменных имен сайтов. Связь между устройствами в сети Интернет осуществляется по IP адресам, например: "192.64.147.209". Однако, запомнить IP адреса сложно, поэтому были придуманы удобные для человека доменные имена, например: "google.com".

Компьютер / сервер не хранит таблицу соответствия доменов и их IP адресов. Точнее, не хранит всю таблицу, а временно запоминает данные для часто используемых доменов. Когда в браузере вводится домен сайта, компьютер автоматически узнает его IP адрес, и отправляет по нему запрос. Этот процесс называется «разрешение адреса домена» (domain resolving).

Разберемся, из чего состоит система DNS, и как она работает.

Как работает DNS

Система доменных имен состоит из следующих компонентов:

Иерархическая структура доменных имен:

Доменные зоны верхнего уровня (первого уровня ) – например: "ru", "com", или "org". Они включают в себя все доменные имена, входящие в эту зону. В любую доменную зону может входить неограниченное количество доменов.
Доменные имена (доменные зоны второго уровня) – например: "google.com" или "yandex.ru". Т.к. система доменных имен является иерархичной, то "yandex.ru" можно также назвать поддоменом вышестоящей зоны "ru". Поэтому, правильнее указывать именно уровень домена. Однако, на практике, доменную зону любого уровня называют просто «доменом».
Поддомены (доменные зоны третьего уровня) – например: "api.google.com" или "mail.yandex.ru". Могут быть доменные зоны 4, 5 уровней и так далее.

Обратите внимание, что "www.gооgle.com" и "google.com" - это, фактически, разные домены. Надо не забывать указывать А-записи для каждого из них.

DNS сервер или NS (name server) сервер – поддерживает (обслуживает) доменные зоны, которые ему делегированы. Он непосредственно хранит данные о ресурсных записях для зоны. Например, что сервер, на котором находится сайт "example.ru", имеет IP адрес "1.1.1.1". DNS сервер отвечает на все запросы, касательной этих доменных зон. Если ему приходит запрос о домене, который ему не делегирован, то он спрашивает ответ у других DNS серверов.

DNS записи (ресурсные записи) – это набор записей о доменной зоне на NS сервере, которые хранят данные необходимые для работы DNS. На основании данных в этих записях, DNS сервер отвечает на запросы по домену. Список записей, и их значение, вы можете найти ниже.

Корневые DNS сервера (на данный момент их 13 во всем мире) хранят данные о том, какие DNS сервера обслуживают зоны верхнего уровня.

DNS сервера доменных зон верхнего уровня - хранят информацию, какие NS сервера обслуживают тот или иной домен.

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

Кэширование данных используется на всех устройствах (компьютерах, северах, DNS серверах). То есть, они запоминают ответы на последние пришедшие к ним запросы. И когда приходит аналогичный запрос, они просто отвечают то же самое, что и в предыдущий раз. Например, если вы в браузере открыли сайт google.com первый раз после включения, то компьютер сделает DNS запрос, а при последующих запросах будет брать данные, которые ему были присланы DNS сервером в первый раз. Таким образом, для популярных запросов не надо каждый раз проходить всю цепочку и генерировать запросы к NS серверам. Это значительно снижает нагрузку на них, и увеличивает скорость работы. Однако, как результат, обновление данных в системе DNS происходит не сразу. При изменении IP адреса домена, информацию об этом будет расходиться по сети Интернет от 1 до 24 часов.

Регистрация/выделение доменов

У каждой доменной зоны первого уровня есть своя организация, которая устанавливает правила выделения доменов и обеспечивает работу этой зоны. Например, для доменных зон RU, SU и РФ – это Координационный центр национального домена сети Интернет https://cctld.ru . Эти организации устанавливают правила работы и технические требования к регистраторам доменов.

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

Администратор домена (владелец) – лицо, которому непосредственно принадлежат права на доменное имя. Он может управлять доменом, от него регистратор принимает заявки на внесение изменений.

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

Основные DNS записи

Существуют следующие основные DNS (ресурсные) записи:

А – содержит информацию об IPv4 адресе хоста (сервера) для домена. Например, 1.1.1.1.

ААА – содержит информацию об IPv6 адресе хоста (сервера) для домена. Например, 2001:0db8:11a3:09d7:1f34:8a2e:07a0:765d.

MX – содержит данные о почтовом сервере домена. При этом указывается именно имя почтового сервера, например mail.example.com. Т.к. у домена может быть несколько почтовых серверов, то для каждого из них указывает приоритет. Приоритет задается числом от 0 до 65535. При этом «0» - это самый высокий приоритет. Принято по умолчанию для первого почтового сервера указывать приоритет «10».

TXT – дополнительная информация о домене в виде произвольного текста. Максимальная длина 255 символов.

SRV – содержит информацию об имени хоста и номере порта, для определенных служб / протоколов в соответствии с RFC 2782 http://www.rfc-editor.org/rfc/rfc2782.txt . Содержит следующие поля:

_Service._Proto.Name (Пример: _jabber._tcp.jabber), где:
- Service: название службы (пример: ldap, kerberos, gc и другие).
- Proto: протокол, при помощи которого клиенты могут подключиться к данной службе (пример: tcp, udp).
- Name: имя домена, в котором размещена данная служба.
Приоритет – также как для MX записи указывает приоритет для данного сервера. Задается числом от 0 до 65535. При этом «0» - это самый высокий приоритет.
Вес – Относительный вес для распределения нагрузки между серверами с одинаковым приоритетом. Задается целым числом.
Порт – номер порта, на котором располагается служба на данном сервере.
Назначение - доменное имя сервера, предоставляющего данную службу.

NS – имя DNS сервера, поддерживающего данный домен.

CNAME (каноническое имя хоста / canonical name) – используется для перенаправления на другое доменное имя. Например, имя сервера изменилось с example.com на new.com. В таком случае в поле «Alies» для записи cname надо указать - example.com, а в поле «Canonical name» - new.com. Таким образом, все запросы на example.com автоматически будут перенаправлены на new.com.

SOA – базовая запись о домене. В ней хранится само имя домена и время жизни данных о домене - TTL. TTL (time-to-live) определяет какой период времени DNS сервер получив информацию о зоне будет хранить ее у себя в памяти (кэшировать). Рекомендуемое значение 86400 – 1 день. Значение указывается в секундах.

Отображение адресов в имена

IP адрес записывается в десятично-точечной нотации . Для поиска доменных имен по IP адресам используется домен in-addr.arpa. Его поддоменами являются домены с простыми именами от 0 до 255, соответствующими старшему октету IP адреса. Их поддоменами явлются домены с простыми именами от 0 до 255, соответствующие второму октету IP адреса и т.д. до 4-го октета. Таким образом, IP адрес оказывается записанным в доменном имени в обратном порядке. Например, адресу 195.161.72.28 соответствует доменное имя 28.72.161.195.in-addr.arpa. (и значение PTR – deol.deol.ru). Обратная запись необходима для более легкого делегирования зон в соответствии с выделением IP адресов.

Зоны верхнего уровня в домене in-addr.arpa. делегированы IANA региональным регистраторам (RIR, Regional Internet Registrator) вместе с блоками IP-адресов.

RIPE для делегирования подзоны требует от LIR внесения информации в БД RIPE. Если вы представляете LIR, то должны были закончить специальные курсы, а если нет, то прав на внесение информации в БД RIPE вам не дадут и придется просить свой LIR. В БД должны быть как сеть (whois [email protected]), так и зона (whois [email protected])

Отображение адресов в имена может быть обязательным для работы некоторых сервисов Интернет: нет отображения – нет обслуживания.

Записи о ресурсах (RR, Resource Records)

Записи ресурсов могут быть представлены в текстовом формате в файле данных зоны и в двоичном формате при обмене сообщениями протокола DNS. Текстовый формат зоны может отличаться для различных реализаций DNS сервера, здесь описывается формат, упомянутый в стандарте (RFC 1035) и используемый в BIND 4/8/9. Файл зоны должен содержать записи только одного класса.

Каждая запись расположена на отдельной строке. Пустые строки игнорируются. Границы строк не распознаются внутри круглых скобок и текстовых литералов в кавычках. Разделителями полей являются пробелы и табуляции. Комментарии начинаются с символа точки с запятой в любом месте строки и продолжаются до конца строки. Кроме записей ресурсов файл зоны может содержать директивы $ORIGIN, $INCLUDE и $TTL (начиная с BIND 8.2). Символ “@” используется для обозначения текущего суффикса по умолчанию для относительных доменных имен. Обратная косая черта маскирует специальный смысл следующего символа. Возможно задание произвольных октетов в виде восьмеричных чисел (\012). Регистр букв не учитывается при поиске, но возвращается в ответе.

Директива $ORIGIN задает текущий суффикс по умолчанию для относительных доменных имен. Директива $INCLUDE вставляет указанный файл в файл зоны и задает (только для записей из вставляемого файла) текущий суффикс для относительных доменных имен (суффикс может быть опущен). В старых версиях BIND и его производных (например, in.named в Solaris 2.5) изменение суффикса не срабатывает (хотя и сообщения об ошибке не выдается!) и приходится “обрамлять” директиву $INCLUDE директивами изменения $ORIGIN и его восстановления. Директива $TTL задает TTL по умолчанию (RFC 2308).

Запись ресурса состоит из доменного имени (если опущено, то подразумевается значение из предыдущей записи ресурса), имени класса (может быть опущено и браться из предыдущей записи), TTL (число секунд, может быть опущено и браться из директивы $TTL для BIND 8.2 и новее или из поля MINIMUMTTL в SOA для старых версий; рекомендуемое значение – одни сутки; разумное – от 1 часа до недели; TTL всех записей с одинаковым ключом должны быть одинаковы), типа записи и данных записи (формат определяется классом и типом). В новых версиях (BIND ?) времена могут задаваться как в секундах, так и минутах (суффикс m), часах (суффикс h), днях (суффикс d), неделях (суффикс w). Только имена узлов обязаны соответствовать синтаксису доменных имен (буквы, цифры и минус), остальные (например, первая метка почтового адреса в записи SOA) могут состоять из произвольных символов ASCII.

Классы записей (в тяжелой эволюционной борьбе выжил только IN), в скобках – код для сообщений протокола DNS:

IN (1) – Интернет
CS (2) – CSNET
CH (3) – CHAOS
HS (4) – Hesiod

Типы записей, в скобках – код для сообщений протокола DNS:

BIND версии? позволяет дополнительно использовать директиву $GENERATE для создания последовательности RR, отличающихся лишь параметром:

$GENERATE интервал левая-часть тип-записи правая-часть

Интервал чисел задается либо в виде начало-конец, либо в виде начало-конец/шаг. По умолчанию, шаг равен 1. Левая часть задает правило формирования доменных имен для последовательности записей, у которых индекс пробегает от начало до конец с шагом шаг. Правая часть задает правило формирования данных записи (пока разрешены только типы PTR, CNAME, DNAME, A, AAAA и NS). В правилах одинокий символ $ заменяется текущим значением индекса. Значение индекса может быть модифицировано заданием смещения (вычитается из индекса), ширины поля (используется для форматирования результата) и системы счисления (d, o, x, X) в фигурных скобках через запятую. Если получилось относительное имя, то оно дополняется текущим суффиксом. Используется в основном для автоматической генерации обратных зон:

$ORIGIN 0.0.192.IN-ADDR.ARPA.
$GENERATE 1-127 $ CNAME $.0

преобразуется в

1.0.0.192.IN-ADDR.ARPA CNAME 1.0.0.0.192.IN-ADDR.ARPA
2.0.0.192.IN-ADDR.ARPA CNAME 2.0.0.0.192.IN-ADDR.ARPA
...
127.0.0.192.IN-ADDR.ARPA CNAME 127.0.0.0.192.IN-ADDR.ARPA

Протокол DNS

Запросы и ответы DNS обычно используют протокол UDP (порт 53, domain ), однако могут использовать и протокол TCP (порт 53, domain). Каждое сообщение полностью помещается в один UDP пакет, стало быть не может быть более 64 KB. В реальности, многие реализации имеют ограничение на размер нефрагментируемого UDP пакета в 576 байт. В такой пакет помещается информация о 10 записях типа NS в общем случае. Доменные имена корневых серверов Интернет были помещены в один домен, что позволило упаковать информацию с помощью ссылок (см. ниже) о 13 серверах. Если ответ не поместился в один фрагмент UDP, то в заголовке устанавливается бит TC (truncated), что приводит к повторному запросу с использованием протокола TCP. При использовании протокола TCP к каждому сообщению добавляется префикс (2 байта), содержащий длину сообщения без учета префикса. Первым передается левый бит (нулевой) – старший по значению.

Формат запросов и ответов одинаков (подробнее см. RFC 1035 )

Расширение протокола TSIG

RFC 2845 расширяет протокол DNS возможностью проверки целостности запросов и ответов (QUERY), передачу зон, а также аутентификацию динамических изменений (UPDATE, RFC 2136) с помощью криптографически стойких контрольных сумм – TSIG (transaction signatures). При генерации хеша используется алгоритм HMAC-MD5 и разделяемый между двумя участниками секрет (симметричный ключ). Механизм распределения ключей не определяется. Участники транзакции могут разделять несколько ключей, поэтому для идентификации конкретного ключа используется его имя в формате доменного имени. Для предотвращения атак повторного воспроизведения запись содержит время подписи (требуется синхронизация времени с помощью, например, NTP). Отвечая на защищенный запрос сервер посылает ответ, защищенный тем же алгоритмом и ключом. В качестве ключей рекомендуется использовать случайные последовательности длиной не менее 128 бит.

Данный механизм требует меньшей нагрузки на процессор и меньших затрат на создание инфраструктуры при небольшом количестве узлов по сравнению с DNSSEC с его механизмами ассиметричного шифрования и публичных ключей (RFC 2535, RFC 2137). С другой стороны DNSSEC позволяет легко масштабировать установленную инфраструктуру распределения ключей и обеспечивать цифровую подпись (TSIG несмотря на название не позволяет производить подтверждение авторства запросов из-за симметричности ключа).

RFC 2845 вводит новый тип записи TSIG (250) и несколько новых кодов ответа. Запись типа TSIG является виртуальной, т.е. вычисляется во время транзакции, не содержится в файле данных зоны и не кешируется. Запись добавляется в раздел дополнительных данных; включает имя разделяемого ключа, класс (ANY), TTL (0), имя алгоритма (сейчас всегда HMAC-MD5), время подписи, интервал отклонения времени, хеш, идентификатор исходного сообщения (используется при ретрансляции динамических изменений), код ошибки, дополнительный данные об ошибке (например, расхождение часов участников). Для генерации хеша используется исходное сообщение, имя ключа, класс, TTL, имя алгоритма, время подписи, интервал отклонения времени. При генерации хеша ответа в исходные данные включается также хеш запроса.

Динамические изменения зоны

RFC 2136 расширяет протокол DNS возможностью динамического изменения содержимого зоны по требованию клиента. Это избавляет от необходимости при частых изменениях (например, работа DHCP) редактировать текстовый файл с описанием зоны и перезапускать сервер. С помощью данного расширения можно одним пакетом внести несколько изменений в зону, управляемую данным первичным уполномоченным сервером (все доменные имена должны быть внутри зоны):

добавить запись ресурса (RR) в набор записей ресурсов (RRset); записи типа SOA и CNAME не добавляются, а замещаются; если SOA не было или её серийный номер был больше, то добавление игнорируется; попытка заменить нормальный набор записей на CNAME или CNAME на нормальный набор записей игнорируется; попытка добавить дублирующую запись игнорируется
удалить запись ресурса (RR) с заданным значением из набора записей ресурсов (RRset); не удаляются последняя запись NS и SOA самой зоны; попытка удалить несуществующую запись игнорируется
удалить набор записей ресурсов (RRset); не удаляются записи NS и SOA самой зоны; попытка удалить несуществующий набор игнорируется
удалить все наборы ресурсов, относящиеся к указанному доменному имени; не удаляются записи NS и SOA самой зоны; попытка удалить несуществующий набор игнорируется

Набор изменений может быть предварён набором условий следующих типов (все доменные имена должны быть внутри зоны):

указанное доменное имя имеет хотя бы одну запись ресурса указанного типа
указанное доменное имя имеет записи ресурсов указанного типа с заданными значениями (значение TTL не учитывается, при сравнении имён прописные и строчные буквы не различаются, шаблоны не обрабатываются, синонимы (CNAME) не обрабатываются)
указанное доменное имя не имеет ни одной записи ресурса указанного типа
указанное доменное имя имеет хотя бы одну запись ресурса
указанное доменное имя не имеет ни одной записи ресурса

есь пакет условий и изменений является атомарным, т.е. обрабатывается как единое неделимое целое (как транзакция в СУБД). При этом сервер обязан записать изменения на диск до ответа клиенту. bind временно записывает изменения в журнал и сливает его с файлом зоны позднее. Если изменения не затронули SOA, то сервер должен увеличить серийный номер автоматически. Метод стандартом не задаётся. Если автоувеличение серийного номера производится с задержкой, но она не должна быть более 300 секунд или 1/3 от времени обновления зоны.

RFC 2136 вводит новый класс NONE (254) и несколько новых кодов ответа. Формат запросов и ответов совпадает с форматом обычных запросов и ответов, но имеет код запроса – UPDATE (5). Секция запроса содержит имя изменяемой зоны (ровно одна запись ресурса типа SOA), секция ответа – набор условий, секция ссылок на уполномоченные сервера – добавляемые или удаляемые записи, секция дополнительной информации – связующие записи доменных имён вне зоны (может игнорироваться сервером).

Клиент может получить список потенциальных серверов из записей SOA, NS или внешними средствами.

Сервер может проверять право клиента на изменение зоны по его IP адресу (не рекомендуется) или при помощи механизма TSIG.

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

Обеспечение правильного порядка применения изменений (так чтобы “задержавшиеся в пути” старые изменения не перекрывали более новые) является нетривиальной задачей в среде TCP/IP, особенно при наличии нескольких делающих запросы клиентов и нескольких перенаправляющих вторичных серверов. Ответ сервера также может задержаться или затеряться. Авторы RFC рекомендуют пользоваться “маркерными” записями ресурсов для обеспечения синхронизации (такой маркер может, например, содержать время выдачи запроса).

DNS клиент (resolver)

Клиенты DNS обычно реализуются в виде библиотеки подпрограмм, присоединяемых к каждой программе (статически или динамически), которой требуется сервис доменных имен. Простой (stub) клиент обращается к указанному при настройке DNS серверу (серверам), интерпретирует ответ и возвращает результат запросившей программе. Реализация клиента в Solaris (Solaris 2.5.1 и младше соответствует BIND 4.8.3; с заплатками – BIND 4.9.3; Solaris 2.6, 7 и 8 – BIND 4.9.4-P1) и Linux (клиент DNS входит в состав пакета glibc, а не bind) позволяет также получить информацию из других источников (локальный файл, NIS, NIS+ и т.д.) в зависимости от настройки Name Service Switch. Некоторые клиенты позволяют кешировать информацию самостоятельно, либо с помощью nscd.

Общий алгоритм запроса таков: прикладная программа, которой необходимо, например, получить адрес хоста по его имени, вызывает подпрограмму gethostbyname(3) или аналогичную ей. При сборке программы к ней прилинковываются подпрограммы из библиотеки libc (glibc), которые проверяют наличие требуемой информации в кеше nscd (если, конечно, запущен сервер nscd). Если информацию из кеша извлечь не удалось, то используется NSS для определения сервиса имен, который (которые) будет использован для поиска адреса по имени. В частности, в настройках NSS может быть указан dns в качестве сервиса имен для поиска доменных имен. В этом случае используются функции, указанные в resolver(3), которые и являются “настоящим” клиентом DNS (они формируют запрос к серверу в соответствии с DNS протоколом и обрабатывают ответ).

Настройка работы клиента DNS производится с помощью файла /etc/resolv.conf или переменных окружения при запуске процесса.

Каждая строка /etc/resolv.conf содержит одну инструкцию, комментарии начинаются с точки с запятой или символа # (осторожно! клиент может не сообщать об ошибках в этом файле!):

nameserver IP-адрес-обслуживающего-сервера (можно указать до 3 строк с адресами серверов; по умолчанию используется сервер, расположенный на этом же хосте (его также можно указать с помощью его IP адреса или адреса 0.0.0.0 или loopback адреса 127.0.0.1); клиент опрашивает указанные сервера в порядке их перечисления, если не дождался ответа от предыдущего сервера из списка или получил сообщение об ошибке (недоступен порт на сервере, хост сервера или вся сеть); опрос по списку повторяется несколько раз в зависимости от версии клиента (от 2 до 4); интервал первоначального ожидания зависит от версии (от 2 до 5 секунд) и числа серверов в списке; при каждом следующем прохождении по списку интервал ожидания удваивается; суммарное время ожидания достигает 80 секунд для версии до 8.2 и 24 секунд для более новых версий)
domain имя-локального-домена (добавляется к относительным доменным именам перед поиском; точка в конце имени не нужна; по умолчанию извлекается из доменного имени хоста (см. hostname(1)); имя локального домена также задает список поиска по умолчанию (для bind 4.8.3: имя локального домена и список его предков, имеющих не менее 2 простых имен; для новых версий bind: только имя локального домена))
search список-имен-доменов-через-пробел (до 6 имен доменов в порядке предпочтения; первое имя в списке устанавливает имя локального домена; инструкции domain и search – взаимоисключающие (выполняется последняя из них); список поиска используется для разрешения относительных доменных имен; для bind 4.8.3 разрешение относительного имени делается сначала по списку поиска (имена доменов из списка поиска приписываются по очереди справа от относительного имени перед запросом к серверу DNS), при неудаче имя считается абсолютным и делается еще один запрос; для новых версий bind сначала разрешение для относительного имени, содержащего хотя бы одну точку, делается так как будто оно является абсолютным, при неудаче используется список поиска)
sortlist IP-адрес-сети/маска … (версия 4.9 и выше; позволяет клиенту отдавать предпочтение указанным сетям при получении ответов, содержащих несколько адресов – их он помещает в начало списка, остальные в конец; можно указывать до 10 сетей)
options опция … (версия 4.9 и выше; позволяет изменять настройки клиента
- debug (на stdout)
- ndots:число-точек (минимальное число точек в аргументе, при котором поиск по имени осуществляется до использования списка поиска; по умолчанию – 1)
- attempts:число-опросов-списка-серверов (по умолчанию – 2; максимум – 5)
- timeout:начальный-интервал-ожидания (по умолчанию – 5 секунд; максимум – 30 секунд)
- rotate (при каждом обращении использовать другой порядок серверов с целью распределения нагрузки; распределение осуществляется только в рамках одного процесса – при следующем запуске программы первый сервер в списке опять станет первым используемым)
- no-check-names (запретить лексическую проверку простых имен, которая включена в версии 4.9.4 и старше)

Конкретная реализация resolver(3) может иметь другие значения параметров по умолчанию – смотри /usr/include/resolv.h. Различные программы могут быть собраны с различными версиями клиента DNS. К счастью, клиент DNS пропускает непонятные ему строки из файла /etc/resolv.conf. Старые версии клиента DNS (resolv+) могут управляться файлом /etc/host.conf, в этом случае см. host.conf(5). Некоторые программы самостоятельно устанавливают нестандартные значения параметров клиента DNS при инициализации.

Переменная окружения LOCALDOMAIN перекрывает действие инструкций domain и search. Переменная окружения RES_OPTIONS перекрывает действие инструкции options. Переменная окружения HOSTALIASES позволяет задать имя файла (например, /etc/host.aliases), содержащего список синонимов доменных имен (по одному простому имени и его доменному синониму без завершающей точки на строке через пробел).

Если при загрузке компьютера требуется наличие работающего локального сервера DNS (обычно из-за указания доменных имен в ifconfig или route), то желательно обеспечить резервный метод разрешения доменных имен с помощью настройки NSS и заполнения /etc/hosts, иначе клиентские компьютеры будут вынуждены дожидаться загрузки одного из серверов DNS. Тем более важно обеспечить резервный метод для хостов, на которых работают серверы DNS. А лучше всего не использовать DNS во время загрузки. Ещё имеется загадочный файл /etc/ppp/resolv.conf.

Настройка DNS в MS Windows производится с помощью графического интерфейса. Изготовитель уверяет, что это очень просто;). Вот только отличаются реализации клиента DNS в различных версиях MS Windows больше, чем Unix от Linux (в частности, TCP/IP стек в W2000 и XP взят из FreeBSD (NetBSD?):

W95 – отдельные стеки для локальной сети (Control Panel -> Network -> TCP/IP -> DNS) и коммутируемых соединений (My Computer -> Dial-up Networking -> right click на нужном соединении -> Properties -> Server Types -> TCP/IP); при использовании коммутируемого доступа рекомендуется оставлять пустым список DNS серверов в основном стеке и выбирать вариант “Server assigned name server addresses” при настройке коммутируемых соединений
W98 – визуально настройка ничем не отличается; возвращаемые сервером адреса сортируются в соответствии с таблицей маршрутизации; клиент работает одновременно и с серверами, указанными для основного стека, и с серверами, указанными для данного коммутируемого соединения
NT – визуально очень похоже на W95; настройки для основного стека (Control Panel -> Network -> Protocols -> TCP/IP -> DNS) и коммутируемого соединения (My Computer -> Dial-up Networking -> выбрать нужное соединение из выпадающего меню -> More -> Edit Entry -> Modem Properies -> Server -> TCP/IP) используются в нужное время; клиент кеширует полученные результаты (в пределах процесса); в SP4 клиент после неудачи с первым сервером начинает рассылать запросы всем известным ему серверам параллельно
W2000 (Start -> Setting -> Network and Dial-up -> right click на Local Area Connection -> Properies -> TCP/IP); поведение клиента аналогично NT SP4

Сервера DNS

Немного позднее опубликую статью о Bind 9

Статья взята с сайта Bog BOS , автор Сергей Евгеньевич Богомолов.

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

Современную жизнь уже сложно представить без интернета. Он преследует нас повсюду. Даже в часах и микроволновках есть интернет. Большинство людей не особо интересует принцип работы и общее понимание устройства работы сети.

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

Базовые понятия

Domain Name System (ДНС) с английского буквально означает система доменных имён. Такая система призвана получать информацию о доменах, входит в семейство TCP / IP и имеет прикладной уровень по модели OSI .

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

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

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

Что в итоге дает домен? Он позволяет узнать многое о сайте. В названии сайта всегда присутствует: .com - это значит, что указанный сайт коммерческой направленности, .ru - сайт находится в сегменте русскоязычного интернета - тот самый «рунет». Давайте рассмотрим государственный портал закупок, находящийся по адресу: http://zakupki.gov.ru, где.gov означает, что сайт находится в ведении государства, а.ru обозначает принадлежность к российской зоне имен.

Теперь нужно понять, что представляет собой IP-адрес . Машина не понимает наших букв, так как работает исключительно в двоичной системе исчисления (в которую входят лишь два числа 0 и 1). IP-адрес выступает в виде цифр, служащих для удобства настройки сети адреса узлов сети (устройств, которые могут обмениваться данными и присваивать себе ip, например, смартфон, принтер, роутер и т. д.), используя десятичную систему, машина сама переводит цифры в двоичную, и таким образом понимает, куда ей обращаться с запросом о получении данных и обмена соответствующими пакетами.

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

Выглядит сложно на бумаге, но благодаря DNS мы вбиваем в адресной строке ya.ru и попадаем на сайт Яндекса. То есть первостепенная задача DNS - это упрощение поиска различных интернет-порталов и интерпретирует имя доменов в IP-адреса.

Структура DNS

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

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

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

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

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

Систематика DNS-серверов

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

Все серверы делятся на:

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

Информация для пользователя

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

Однако самые искушенные пользователи используют бесплатные альтернативы от крупных IT-компаний, таких как Google или Яндекс. Так, сервера Яндекса включают в себя больше 80 DNS.

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

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

Если DNS-сервер не отвечает

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

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.