Построение локальной вычислительной сети предприятия
Пусть у нас имеется три маршрута на сети 10.0.1.0/24, 10.0.2.0/24 и 10.0.3.0/24. Причем маршруты на первую и третью сети одинаковы. В этом случае можно уменьшить количество записей таблицы маршрутизации, ускорив этим процесс поиска наилучшего маршрута. Для этого мы объединим первый и третий маршруты, после чего остаются только два маршрута. Причем объединить мы можем любой покрывающей сетью, например, 10.0.0.0/8. Маршрутизация будет продолжать правильно работать, так как для сети 10.0.2.0/24 будет выбран маршрут с наибольшим совпадением (точнее полным) адреса сети, а для остальных адресов из 10.0.0.0/8 будет выбран обобщенный маршрут. Как вы уже заметили, маршрутизатор начинает отправлять пакеты на несуществующие сети (из-за сети 10.0.0.0/8), и, хотя такие пакеты выбросятся дальше, это займет ресурсы маршрутизатора, поэтому может являться плохим подходом. Объединение маршрутов называется префиксной агрегацией или суммаризацией маршрутов.
Различается всего два вида маршрутизации: статическая и динамическая.
Статическая маршрутизация
При статической маршрутизации маршруты вводятся администратором вручную на каждом маршрутизаторе и не изменяются во время работы. Также иногда к статической маршрутизации относят маршруты, изменение которых можно предугадать. Например, изменение маршрутов по расписанию или дню недели.
Также следует упомянуть об выходных интерфейсах. При поднятии сетевого интерфейса и настройке на нем протокола сетевого уровня, в таблицу маршрутизации автоматически заносится маршрут на сеть, в которой находится этот интерфейс. Такие сети, в которых находится маршрутизатор, называются напрямую соединенными. А маршруты на них задаются только выходным интерфейсом и являются наиболее приоритетными. Ведь зачем искать обходные пути, если мы и так в этой сети и можем напрямую отправить пакет получателю?
Остальные маршруты задаются адресом следующего маршрутизатора. Таким образом пакет будет проходить маршрутизаторы, пока не дойдет до того, у которого есть напрямую соединенная сеть назначения.
Динамическая маршрутизация
Динамическая маршрутизация совершается за счет динамических протоколов маршрутизации. При их помощи маршрутизатор строит и обновляет свою таблицу маршрутизации.
Говорят, что сеть сошлась, когда с любого маршрутизатора можно попасть в любую сеть. Иначе могут возникнуть неполадки в работе сети, такие как потеря пакетов и циклы маршрутизации. Асимметричной же маршрутизацией называют такую, в которой существует маршрут только в одну сторону.
Динамические протоколы маршрутизации делятся на внешние и внутренние. А внутренние в свою очередь на дистанционно-векторные протоколы и протоколы link state (состояния канала).
Внутренние протоколы используются в сетях разного объема для автоматизации и надежности процесса маршрутизации. Внешние протоколы используются для работы между автономными системами, т.е. в очень больших сетях, таких как Internet.
Разница между дистанционно-векторными протоколами и протоколами состояния канала довольно существенна. Link state протоколы появились позже, когда классовые сети отошли в прошлое. Их основным принципом является хранение состояния всех каналов сети. Они строят некую карту сети и самостоятельно определяют наилучшие маршруты. Отличительной чертой также есть отправка обновлений лишь при изменении топологии и лишь тем маршрутизаторам, которым будет актуальна информация.
Дистанционно-векторные протоколы требуют правильной и совместной работы всех маршрутизаторов, так как они оперируют с направлением и метрикой, которую получают от соседних маршрутизаторов. Таким образом, получив маршрут, маршрутизатор увеличивает его метрику и отправляет его другим соседям. Из этого и следует название протоколов - дистанция (метрика) и вектор (направление). Среди представителей можно выделить протокол EIGRP, который имеет ряд преимуществ и некоторые сходства с протоколами состояния канала.
На одном маршрутизаторе могут одновременно работать множество протоколов маршрутизации. Они также могут анонсировать одинаковые сети. Представим, что есть сеть, в которой каждый маршрутизатор соединен со всеми остальными (такая топология называется full mesh). Таким образом в одну сеть мы можем попасть разными способами. Но давайте запустим в такой сети разные протоколы маршрутизации, например RIP и EIGRP. Выберем для рассмотрения маршрутизатор, на котором работают оба эти протокола. Проблема состоит в том, что метрика в протоколе RIP может принимать значение от 1 до 15, в то время как в EIGRP она принимает довольно таки внушительные значения. Если сверять метрику, то сети анонсированные протоколом RIP, будут считаться более приоритетными. Выходит, что метрики разных протоколов нельзя сравнивать. И как известно, EIGRP строит более качественные маршруты, поэтому нужен какой-то промежуточный шаг в сравнении маршрутов. Компания Cisco использует для этого понятие административной дистанции. Каждому протоколу присвоено уникальное значение, которое задает степень доверия, и чем оно ниже, тем протокол считается предпочтительней. Поэтому перед сравнением метрики, мы выбираем только один протокол для каждой сети. Но значение административной дистанции для протокола можно и менять на маршрутизаторах Cisco, но это изменение остается в силах только в пределах маршрутизатора.
DHCP (англ. Dynamic Host Configuration Protocol — протокол динамической конфигурации узла) – это сетевой протокол, позволяющий компьютерам автоматически получать IP-адрес и другие параметры, необходимые для работы в сети TCP/IP. Данный протокол работает по модели «клиент-сервер». Для автоматической конфигурации компьютер-клиент на этапе конфигурации сетевого устройства обращается к т. н. серверу DHCP, и получает от него нужные параметры. Сетевой администратор может задать диапазон адресов, распределяемых сервером среди компьютеров. Это позволяет избежать ручной настройки компьютеров сети и уменьшает количество ошибок. Протокол DHCP используется в большинстве крупных (и не очень) сетей TCP/IP.
DHCP является расширением протокола BOOTP, использовавшегося ранее для обеспечения бездисковых рабочих станций IP-адресами при их загрузке. DHCP сохраняет обратную совместимость с BOOTP.
Стандарт протокола DHCP был принят в октябре 1993 года. Действующая версия протокола (март 1997 года) описана в RFC 2131. Новая версия DHCP, предназначенная для использования в среде IPv6, носит название DHCPv6.
Протокол DHCP предоставляет три способа распределения IP-адресов:
Ручное распределение. При этом способе сетевой администратор сопоставляет аппаратному адресу (обычно MAC-адресу) каждого клиентского компьютера определённый IP-адрес. Фактически, данный способ распределения адресов отличается от ручной настройки каждого компьютера лишь тем, что сведения об адресах хранятся централизованно (на сервере DHCP), и потому их проще изменять при необходимости.
Автоматическое распределение. При данном способе каждому компьютеру на постоянное использование выделяется произвольный свободный IP-адрес из определённого администратором диапазона.
Динамическое распределение. Этот способ аналогичен автоматическому распределению, за исключением того, что адрес выдаётся компьютеру не на постоянное пользование, а на определённый срок. Это называется арендой адреса. По истечении срока аренды IP-адрес вновь считается свободным, и клиент обязан запросить новый (он, впрочем, может оказаться тем же самым).
Некоторые реализации службы DHCP способны автоматически обновлять записи DNS, соответствующие клиентским компьютерам, при выделении им новых адресов. Это производится при помощи протокола обновления DNS.
Помимо IP-адреса, DHCP также может сообщать клиенту дополнительные параметры, необходимые для нормальной работы в сети. Эти параметры называются опциями DHCP.
Некоторыми из наиболее часто используемых опций являются:
IP-адрес маршрутизатора по умолчанию;
маска подсети;
адреса серверов DNS;
имя домена DNS.
Некоторые поставщики программного обеспечения могут определять собственные, дополнительные опции DHCP.
Протокол DHCP является клиент-серверным, то есть в его работе участвуют клиент DHCP и сервер DHCP. Передача данных производится при помощи протокола UDP, при этом сервер принимает сообщения от клиентов на порт 67 и отправляет сообщения клиентам на порт 68.
Все сообщения протокола DHCP разбиваются на поля, каждое из которых содержит определённую информацию. Все поля, кроме последнего (поля опций DHCP), имеют фиксированную длину.
| Поле | Описание | Длина (в байтах) |
| op | Тип сообщения. Может принимать два значения: BOOTREQUEST (1, запрос от клиента к серверу) и BOOTREPLY (2, ответ от сервера к клиенту). | 1 |
| htype | Тип аппаратного адреса. Например, для MAC-адреса Ethernet 10 Мбит/с это поле принимает значение 1. | 1 |
| hlen | Длина аппаратного адреса в байтах. Для MAC-адреса Ethernet – 6. | 1 |
| hops | Количество промежуточных маршрутизаторов (так называемых агентов ретрансляции DHCP), через которые прошло сообщение. Клиент устанавливает это поле в 0. | 1 |
| xid | Уникальный идентификатор транзакции, генерируемый клиентом в начале процесса получения адреса. | 4 |
| secs | Время в секундах с момента начала процесса получения адреса. Может не использоваться (в этом случае оно устанавливается в 0). | 2 |
| flags | Поле для флагов — специальных параметров протокола DHCP. | 2 |
| ciaddr | IP-адрес клиента. Заполняется только в том случае, если клиент уже имеет собственный IP-адрес и способен отвечать на запросы ARP (это возможно, если клиент выполняет процедуру обновления адреса по истечении срока аренды). | 4 |
| yiaddr | 'your' (client) IP address | 4 |
| siaddr | IP-адрес сервера. Возвращается в предложении DHCP (см. ниже). | 4 |
| giaddr | IP-адрес агента ретрансляции, если таковой участвовал в процессе доставки сообщения DHCP до сервера. | 4 |
| chaddr | Аппаратный адрес (обычно MAC-адрес) клиента. | 16 |
| sname | Необязательное имя сервера в виде нуль-терминированной строки. | 64 |
| file | Необязательное имя файла на сервере, используемое бездисковыми рабочими станциями при удалённой загрузке. Как и sname, представлено в виде нуль-терминированной строки. | 128 |
| options | Поле опций DHCP. Здесь указываются различные дополнительные параметры конфигурации. В начале этого поля указываются четыре особых байта со значениями 99, 130, 83, 99 («волшебные числа»), позволяющие серверу определить наличие этого поля. | переменная |
Рассмотрим пример процесса получения IP-адреса клиентом от сервера DHCP. Предположим, клиент ещё не имеет собственного IP-адреса, но ему известен его предыдущий адрес — 192.168.1.100. Процесс состоит из четырёх этапов.
Обнаружение DHCP. В начале клиент выполняет широковещательный запрос по всей физической сети с целью обнаружить доступные DHCP-серверы. Он отправляет сообщение типа DHCPDISCOVER, при этом в качестве IP-адреса источника указывается 0.0.0.0 (так как компьютер ещё не имеет собственного IP-адреса), а в качестве адреса назначения — широковещательный адрес 255.255.255.255.
Клиент заполняет несколько полей сообщения начальными значениями:
В поле xid помещается уникальный идентификатор транзакции, который позволяет отличать данный процесс получения IP-адреса от других, протекающих в то же время.
В поле chaddr помещается аппаратный адрес (MAC-адрес) клиента.
В поле опций указывается последний известный клиенту IP-адрес. В данном примере это 192.168.1.100. Это необязательно и может быть проигнорировано сервером.
Сообщение DHCPDISCOVER может быть распространено за пределы локальной физической сети при помощи специально настроенных агентов ретрансляции DHCP, перенаправляющих поступающие от клиентов сообщения DHCP серверам в других подсетях.
Предложение DHCP. Получив сообщение от клиента, сервер определяет требуемую конфигурацию клиента в соответствии с указанными сетевым администратором настройками. В данном случае DHCP-сервер согласен с запрошенным клиентом адресом 192.168.1.100. Сервер отправляет ему ответ (DHCPOFFER), в котором предлагает конфигурацию. Предлагаемый клиенту IP-адрес указывается в поле yiaddr. Прочие параметры (такие, как адреса маршрутизаторов и DNS-серверов) указываются в виде опций в соответствующем поле.
Это сообщение DHCP-сервер отправляет хосту пославшему (DHCPDISCOVER) на его MAC, при определенных обстоятельствах может распространяться, как широковещательная рассылка. Клиент может получить несколько различных предложений DHCP от разных серверов; из них он должен выбрать то, которое его «устраивает».
Запрос DHCP. Выбрав одну из конфигураций, предложенных DHCP-серверами, клиент отправляет запрос DHCP (DHCPREQUEST). Он рассылается широковещательно; при этом к опциям, указанным клиентом в сообщении DHCPDISCOVER, добавляется специальная опция — идентификатор сервера — указывающая адрес DHCP-сервера, выбранного клиентом (в данном случае — 192.168.1.1).
Подтверждение DHCP. Наконец, сервер подтверждает запрос и направляет это подтверждение (DHCPACK) клиенту. После этого клиент должен настроить свой сетевой интерфейс, используя предоставленные опции.
Помимо сообщений, необходимых для первоначального получения IP-адреса клиентом, DHCP предусматривает несколько дополнительных сообщений для выполнения иных задач.
Отказ DHCP. Если после получения подтверждения (DHCPACK) от сервера клиент обнаруживает, что указанный сервером адрес уже используется в сети, он рассылает широковещательное сообщение отказа DHCP (DHCPDECLINE), после чего процедура получения IP-адреса повторяется. Использование IP-адреса другим клиентом можно обнаружить, выполнив запрос ARP.
Отмена DHCP. Если по каким-то причинам сервер не может предоставить клиенту запрошенный IP-адрес, или если аренда адреса удаляется администратором, сервер рассылает широковещательное сообщение отмены DHCP (DHCPNAK). При получении такого сообщения соответствующий клиент должен повторить процедуру получения адреса.
Освобождение DHCP. Клиент может явным образом прекратить аренду IP-адреса. Для этого он отправляет сообщение освобождения DHCP (DHCPRELEASE) тому серверу, который предоставил ему адрес в аренду. В отличие от других сообщений DHCP, DHCPRELEASE не рассылается широковещательно.
Информация DHCP. Сообщение информации DHCP (DHCPINFORM) предназначено для определения дополнительных параметров TCP/IP (например, адреса маршрутизатора по умолчанию, DNS-серверов и т. п.) теми клиентами, которым не нужен динамический IP-адрес (то есть адрес которых настроен вручную). Серверы отвечают на такой запрос сообщением подтверждения (DHCPACK) без выделения IP-адреса.
7. Протокол TCP
Transmission Control Protocol (TCP) (протокол управления передачей) — один из основных сетевых протоколов Интернет, предназначенный для управления передачей данных в сетях и подсетях TCP/IP.
Выполняет функции протокола транспортного уровня модели OSI.
TCP — это транспортный механизм, предоставляющий поток данных, с предварительной установкой соединения, за счёт этого дающий уверенность в достоверности получаемых данных, осуществляет повторный запрос данных в случае потери данных и устраняет дублирование при получении двух копий одного пакета. В отличие от UDP, гарантирует, что приложение получит данные точно в такой же последовательности, в какой они были отправлены, и без потерь.
Реализация TCP, как правило, встроена в ядро системы, хотя есть и реализации TCP в контексте приложения.
Когда осуществляется передача от компьютера к компьютеру через Интернет, TCP работает на верхнем уровне между двумя конечными системами, например, Интернет-браузер и Интернет-сервер. Также TCP осуществляет надежную передачу потока байт от одной программы на некотором компьютере в другую программу на другом компьютере. Программы для электронной почты и обмена файлами используют TCP. TCP контролирует длину сообщения, скорость обмена сообщениями, сетевой трафик.
| Формат TCP-сегмента | ||||
| Бит | 0 — 3 | 4 — 9 | 10 — 15 | 16 — 31 |
| 0 | Порт источника | Порт назначения | ||
| 32 | Номер последовательности | |||
| 64 | Номер подтверждения | |||
| 96 | Смещение данных | Зарезервировано | Флаги | Окно |
| 128 | Контрольная сумма | Указатель важности | ||
| 160 | Опции (необязательное) | |||
| 160/192+ | Данные | |||
Порт источника. Порт источника идентифицирует порт, с которого отправлены пакеты.
Порт назначения. Порт назначения идентифицирует порт, на который отправлен пакет.
TCP-порты. Существует набор сервисов (использующих для передачи данных TCP), за которыми закреплены определенные порты:
21 — FTP
23 — Telnet
25 — SMTP
80 — HTTP
110 — POP3
194 — IRC (Internet Relay Chat)
443 — HTTPS (Secure HTTP)
1863 — MSN Messenger
2000 — Cisco SCCP (VoIP)
8008 — alternate HTTP
8080 — alternate HTTP
Номер последовательности. Номер последовательности выполняет две задачи:
1. Если установлен флаг SYN, то это начальное значение номера последовательности и первый байт данных — это номер последовательности плюс 1.
2. В противном случае, если SYN не установлен, первый байт данных — номер последовательности
Поскольку TCP-поток в общем случае может быть длиннее, чем число различных состояний этого поля, то все операции с номером последовательности должны выполняться по модулю 2^32. Это накладывает практическое ограничение на использование TCP. Если скорость передачи коммуникационной системы такова, чтобы в течение MSL (максимального времени жизни сегмента) произошло переполнение номера последовательности, то в сети может появиться два сегмента с одинаковым номером, относящихся к разным частям потока, и приёмник получит некорректные данные.
Номер подтверждения. Если установлен флаг ACK, то это поле содержит номер последовательности, ожидаемый получателем в следующий раз. Помечает этот сегмент как подтверждение получения.
Смещение данных. Это поле определяет размер заголовка пакета TCP в 32-битных словах. Минимальный размер составляет 5 слов, а максимальный — 15, что составляет 20 и 60 байт соответственно. Смещение считается от начала заголовка TCP.
Зарезервирован. Зарезервировано (6 бит) для будущего использования и должны устанавливаться в ноль. Из них два (7-й и 8-й) уже определены:
CWR (Congestion Window Reduced) — Поле «Окно перегрузки уменьшено» — флаг установлен отправителем, чтоб указать, что получен пакет с установленным флагом ECE.
ECE (ECN-Echo) — Поле «Эхо ECN» — указывает, что данный хост способен на ECN (явное уведомление перегрузки) и для указания отправителю о перегрузках в сети.
Флаги (управляющие биты). Это поле содержит 6 битовых флагов:
URG — Поле "Указатель важности" задействовано (англ. Urgent pointer field is significant)
ACK — Поле "Номер подтверждения" задействовано (англ. Acknowledgement field is significant)
PSH — (англ. Push function) инструктирует получателя протолкнуть данные, накопившиеся в приемном буфере, в приложение пользователя
RST — Оборвать соединения, сбросить буфер (очистка буфера) (англ. Reset the connection)
SYN — Синхронизация номеров последовательности (англ. Synchronize sequence numbers)
FIN (англ. final, бит) — флаг, будучи установлен, указывает на завершение соединения (англ. FIN bit used for connection termination).
Контрольная сумма. Поле контрольной суммы — это 16-битное дополнение суммы всех 16-битных слов заголовка и текста. Если сегмент содержит нечетное число октетов в заголовке или тексте, последние октеты дополняются справа 8 нулями для выравнивания по 16-битовой границе. Биты заполнения (0) не передаются в сегменте и служат только для расчёта контрольной суммы. При расчёте контрольной суммы значение самого поля контрольной суммы принимается равным 0.
Указатель важности. 16-битовое значение положительного смещения от порядкового номера в данном сегменте. Это поле указывает порядковый номер октета которым заканчиваются важные (urgent) данные. Поле принимается во внимание только для пакетов с установленным флагом URG.
В отличие от традиционной альтернативы — UDP, который может сразу же начать передачу пакетов, TCP устанавливает соединения, которые должны быть созданы перед передачей данных. TCP соединение можно разделить на 3 стадии:
Установка соединения
Передача данных
Завершение соединения
Состояния сеанса TCP
CLOSED Начальное состояние узла. Фактически фиктивное
LISTEN Сервер ожидает запросов установления соединения от клиента
SYN-SENT Клиент отправил запрос серверу на установление соединения и ожидает ответа
SYN-RECEIVED Сервер получил запрос на соединение, отправил ответный запрос и ожидает подтверждения
ESTABLISHED Соединение установлено, идёт передача данных
FIN-WAIT-1 Одна из сторон (назовём её узел-1) завершает соединение, отправив сегмент с флагом FIN
CLOSE-WAIT Другая сторона (узел-2) переходит в это состояние, отправив, в свою очередь сегмент ACK и продолжает одностороннюю передачу
FIN-WAIT-2 Узел-1 получает ACK, продолжает чтение и ждёт получения сегмента с флагом FIN
LAST-ACK Узел-2 заканчивает передачу и отправляет сегмент с флагом FIN
TIME-WAIT Узел-1 получил сегмент с флагом FIN, отправил сегмент с флагом ACK и ждёт 2*MSL секунд, перед окончательным закрытием соединения
CLOSING Обе стороны инициировали закрытие соединения одновременно: после отправки сегмента с флагом FIN узел-1 также получает сегмент FIN, отправляет ACK и находится в ожидании сегмента ACK (подтверждения на свой запрос о разъединении)
8. Система DNS
DNS (англ. Domain Name System – система доменных имён) - компьютерная распределённая система для получения информации о доменах. Чаще всего используется для получения IP-адреса по имени хоста (компьютера или устройства), получения информации о маршрутизации почты, обслуживающих узлах для протоколов в домене (SRV-запись).
Распределённая база данных DNS поддерживается с помощью иерархии DNS-серверов, взаимодействующих по определённому протоколу.
Основой DNS является представление об иерархической структуре доменного имени и зонах. Каждый сервер, отвечающий за имя, может делегировать ответственность за дальнейшую часть домена другому серверу (с административной точки зрения - другой организации или человеку), что позволяет возложить ответственность за актуальность информации на сервера различных организаций (людей), отвечающих только за "свою" часть доменного имени.
DNS обладает следующими характеристиками:
Распределённость хранения информации. Каждый узел сети в обязательном порядке должен хранить только те данные, которые входят в его зону ответственности и (возможно) адреса корневых DNS-серверов.
Кеширование информации. Узел может хранить некоторое количество данных не из своей зоны ответственности для уменьшения нагрузки на сеть.
Иерархическая структура, в которой все узлы объединены в дерево, и каждый узел может или самостоятельно определять работу нижестоящих узлов, или делегировать (передавать) их другим узлам.
Резервирование. За хранение и обслуживание своих узлов (зон) отвечают (обычно) несколько серверов, разделённые как физически, так и логически, что обеспечивает сохранность данных и продолжение работы даже в случае сбоя одного из узлов.
DNS важна для работы Интернета, ибо для соединения с узлом необходима информация о его IP-адресе, а для людей проще запоминать буквенные (обычно осмысленные) адреса, чем последовательность цифр IP-адреса. В некоторых случаях это позволяет использовать виртуальные серверы, например, HTTP-серверы, различая их по имени запроса. Первоначально преобразование между доменными и IP-адресами производилось с использованием специального текстового файла HOSTS, который составлялся централизованно и обновлялся на каждой из машин сети вручную. С ростом Сети возникла необходимость в эффективном, автоматизированном механизме, которым и стала DNS.
DNS была разработана Полом Мокапетрисом в 1983 году. В 1987 была изменена спецификация DNS, а также были добавлены дополнительные возможности в базовые протоколы.
Дополнительные возможности
поддержка динамических обновлений
безопасные соединения (DNSSEC)
поддержка различных типов информации (SRV-записи)
Ключевыми понятиями DNS являются:
Зона – логический узел в дереве имён. Право администрировать зону может быть передано третьим лицам, за счёт чего обеспечивается распределённость базы данных. При этом персона, передавшая право на управление в своей базе данных хранит информацию только о существовании зоны (но не подзон!), информацию о персоне (организации), управляющей зоной, и адрес серверов, которые отвечают за зону. Вся дальнейшая информация хранится уже на серверах, ответственных за зону.
Домен – название зоны в системе доменных имён (DNS) Интернета, выделенной какой-либо стране, организации или для иных целей. Структура доменного имени отражает порядок следования зон в иерархическом виде; доменное имя читается слева направо от младших доменов к доменам высшего уровня (в порядке повышения значимости), корневым доменом всей системы является точка ('.'), следом идут домены первого уровня (географические или тематические), затем – домены второго уровня, третьего и т. д. (например, для адреса ru. домен первого уровня – org, второго , третьего ru). На практике точку в конце имени часто опускают, но она бывает важна в случаях разделения между относительными доменами и FQDN (англ. Fully Qualifed Domain Name, полностью определённое имя домена).
Поддомен (англ. subdomain) – имя подчинённой зоны. (например, – поддомен домена org, а ru. – домена ). Теоретически такое деление может достигать глубины 127 уровней, а каждая метка может содержать до 63 символов, пока общая длина вместе с точками не достигнет 254 символов. Но на практике регистраторы доменных имён используют более строгие ограничения.
DNS-сервер – специализированное ПО для обслуживания DNS. DNS-сервер может быть ответственным за некоторые зоны и/или может перенаправлять запросы вышестоящим серверам.
DNS-клиент – специализированная библиотека (или программа) для работы с DNS. В ряде случаев DNS-сервер выступает в роли DNS-клиента.
Ответственность (англ. authoritative) – признак размещения зоны на DNS-сервере. Ответы DNS-сервера могут быть двух типов: ответственные (когда сервер заявляет, что сам отвечает за зону) и неответственные (англ. Non-authoritative), когда сервер обрабатывает запрос, и возвращает ответ других серверов. В некоторых случаях вместо передачи запроса дальше DNS-сервер может вернуть уже известное ему (по запросам ранее) значение (режим кеширования).
DNS-запрос (англ. DNS query) – запрос от клиента (или сервера) серверу. Запрос может быть рекурсивным или нерекурсивным. Нерекурсивный запрос либо возвращает данные о зоне, которая находится в зоне ответственности DNS-сервера (который получил запрос) или возвращает адреса корневых серверов (точнее, адрес любого сервера, который обладает большим объёмом информации о запрошенной зоне, чем отвечающий сервер). В случае рекурсивного запроса сервер опрашивает серверы (в порядке убывания уровня зон в имени), пока не найдёт ответ или не обнаружит, что домен не существует. На практике поиск начинается с наиболее близких к искомому DNS-серверов, если информация о них есть в кеше и не устарела, сервер может не запрашивать DNS-серверы). Рекурсивные запросы требуют больше ресурсов от сервера (и создают больше трафика), так что обычно принимаются от «известных» владельцу сервера узлов (например, провайдер предоставляет возможность делать рекурсивные запросы только своим клиентам, в корпоративной сети рекурсивные запросы принимаются только из локального сегмента). Нерекурсивные запросы обычно принимаются ото всех узлов сети (и осмысленный ответ даётся только на запросы о зоне, которая размещена на узле, на DNS-запрос о других зонах обычно возвращаются адреса корневых серверов).
Субдомен – дополнительное доменное имя 3-го уровня в основном домене. Может указывать как на документы корневого каталога, так и на любой подкаталог основного сервера. Например, если у вас есть домен вида mydomain, вы можете создать для него различные поддомены вида mysite1.mydomain, mysite2.mydomain и т. д.
Система DNS содержит иерархию серверов DNS. Каждый домен или поддомен поддерживается как минимум одним авторитетным сервером DNS (от англ. authoritative — авторитетный, заслуживающий доверия; в Рунете применительно к DNS и серверам имен часто употребляют и другие варианты перевода: авторизированный, авторитативный), на котором расположена информация о домене. Иерархия серверов DNS совпадает с иерархией доменов.
Имя и IP-адрес не тождественны – один IP-адрес может иметь множество имён, что позволяет поддерживать на одном компьютере множество веб-сайтов (это называется виртуальный хостинг). Обратное тоже справедливо – одному имени может быть сопоставлено множество IP-адресов: это позволяет создавать балансировку нагрузки.
Для повышения устойчивости системы используется множество серверов, содержащих идентичную информацию, а в протоколе есть средства, позволяющие поддерживать синхронность информации, расположенной на разных серверах. Существует 13 корневых серверов, их адреса практически не изменяются.
Протокол DNS использует для работы TCP- или UDP-порт 53 для ответов на запросы. Традиционно запросы и ответы отправляются в виде одной UDP датаграммы. TCP используется для AXFR-запросов.
Рассмотрим на примере работу всей системы.
Предположим, мы набрали в браузере адрес ru.. Браузер спрашивает у сервера DNS: «какой IP-адрес у ru.»? Однако, сервер DNS может ничего не знать не только о запрошенном имени, но даже обо всём домене . В этом случае имеет место рекурсия: сервер обращается к корневому серверу — например, 198.41.0.4. Этот сервер сообщает — «У меня нет информации о данном адресе, но я знаю, что 204.74.112.1 является авторитетным для зоны org.» Тогда сервер DNS направляет свой запрос к 204.74.112.1, но тот отвечает «У меня нет информации о данном сервере, но я знаю, что 207.142.131.234 является авторитетным для зоны .» Наконец, тот же запрос отправляется к третьему DNS-серверу и получает ответ – IP-адрес, который и передаётся клиенту – браузеру.
В данном случае при разрешении имени, то есть в процессе поиска IP по имени:
браузер отправил известному ему DNS-серверу т. н. рекурсивный запрос — в ответ на такой тип запроса сервер обязан вернуть «готовый результат», то есть IP-адрес, либо сообщить об ошибке;
DNS-сервер, получив запрос от клиента, последовательно отправлял итеративные запросы, на которые получал от других DNS-серверов ответы, пока не получил авторитетный ответ от сервера, ответственного за запрошенную зону.
В принципе, запрошенный сервер, мог бы передать рекурсивный запрос «вышестоящему» DNS-серверу и дождаться готового ответа.
Запрос на определение имени обычно не идёт дальше кэша DNS, который сохраняет ответы на запросы, проходившие через него ранее. Вместе с ответом приходит информация о том, сколько времени разрешается хранить эту запись в кэше.
DNS используется в первую очередь для преобразования символьных имён в IP-адреса, но он также может выполнять обратный процесс. Для этого используются уже имеющиеся средства DNS. Дело в том, что с записью DNS могут быть сопоставлены различные данные, в том числе и какое-либо символьное имя. Существует специальный домен in-addr.arpa, записи в котором используются для преобразования IP-адресов в символьные имена. Например, для получения DNS-имени для адреса 11.22.33.44 можно запросить у DNS-сервера запись 44.33.22.11.in-addr.arpa, и тот вернёт соответствующее символьное имя. Обратный порядок записи частей IP-адреса объясняется тем, что в IP-адресах старшие биты расположены в начале, а в символьных DNS-именах старшие (находящиеся ближе к корню) части расположены в конце.
Наиболее важные типы DNS-записей:
Запись A (address record) или запись адреса связывает имя хоста с адресом IP. Например, запрос A-записи на имя referrals.icann вернет его IP адрес — 192.0.34.164
Запись AAAA (IPv6 address record) связывает имя хоста с адресом протокола IPv6. Например, запрос