Какой порт прослушивает веб сервер для получения dns запросов
В этой статье объясняется, почему некоторые службы используют протоколы TCP и UDP.
Применяется к: Windows Server 2003
Исходный номер КБ: 556000
СВОДКА
DNS и некоторые другие службы работают в обоих протоколах. Возьмем пример службы DNS. Два протокола отличаются друг от друга. TCP — это протокол, ориентированный на подключение, который требует, чтобы данные были последовательными в пункте назначения, а UDP — протоколом без подключения и не требовал последовательности данных или не требовало подключения к хосту для обеспечения согласованности данных.
В базе данных DNS Zone должна быть согласованность. Чтобы сделать это, DNS всегда передает данные зоны с помощью TCP, так как TCP является надежным и убедитесь, что данные зоны соответствуют, передав полную зону другим DNS-серверам, запрашивающим данные.
Проблема возникает, когда Windows 2000 серверов и продуктов Advanced Server использует динамические порты для всех выше 1023. В этом случае DNS-сервер не должен быть интернет-лицом, то есть делать все стандартные запросы для клиентских машин в сети. Маршрутизатор (ACL) должен разрешить всем входящий трафик UDP для доступа к любым высоким портам UDP, чтобы он работал.
LDAP всегда использует TCP — это верно и почему бы не UDP, так как между клиентом и сервером установлено безопасное подключение для отправки данных, и это можно сделать только с помощью TCP, а не UDP. UDP используется только при поиске контроллера домена (Kerberos) для проверки подлинности. Например, клиент домена находит контроллер домена с помощью DNS.
Community Отказ от контента решений
Корпорация Майкрософт и/или соответствующие поставщики не делают представлений о пригодности, надежности или точности сведений и связанных с ними графических данных, содержащихся в этой записи. Вся такая информация и связанная графика предоставляются "как есть" без какой-либо гарантии. Корпорация Майкрософт и/или соответствующие поставщики тем самым отключили все гарантии и условия в отношении этой информации и связанной графики, включая все подразумеваемые гарантии и условия торговой доступности, пригодность для определенной цели, рабочий труд, название и неущемление. Вы соглашаетесь, что ни в каких событиях корпорация Майкрософт и/или ее поставщики не несут ответственности за любые прямые, косвенные, штрафные, случайные, специальные, сопутствующие повреждения или любые повреждения, включая без ограничений убытки за потерю использования, данных или прибыли, возникающие из-за использования или невозможности использования сведений и связанных с ними графических элементов, содержащихся в этом деле, независимо от того, были ли они связаны с контрактом, тортом, халатностью, строгой ответственностью или иным образом, даже если корпорации Майкрософт или любому из ее поставщиков было рекомендовано о возможности ущерба.
Термины Редактор: Дмитрий Сокол 9864 10 мин АудиоТранспортный протокол TCP/IP - это сетевая модель для передачи данных (набор правил обмена информацией) от одного источника к другому, является основой Интернета. Термин “порт”, который часто встречается в описаниях интернет-сервисов, связан с особенностями работы этого протокола.
Сервисы и порты
Каждая приходящая на сервер порция данных предназначена для обработки определенным сервисом.
Для того, чтобы сетевая подсистема сервера различала данные, адресованные определенным сервисам, и правильно распределяла их, в протокол TCP/IP было введено понятие номера порта.
Пакеты данных и их заголовки
Протокол TCP/IP передает данные отдельными порциями - “пакетами данных”.
Каждый пакет данных имеет специальный заголовок, содержащий служебную информацию.
Технически номер порта - это просто цифры в определенном месте заголовка пакета данных, приходящего на сервер.
Сетевая подсистема сервера анализирует заголовок пакета, находит номер порта и, согласно его значению, направляет данные той или иной работающей на сервере программе-сервису.
Каждая принимающая сетевые данные программа на сервере при запуске сообщает операционной системе, что готова получать и обрабатывать данные, адресованные на определенный порт.
Специалисты используют выражение “программа слушает конкретный порт на сервере”. Например, входящие пакеты данных с номером порта 80 передаются на обработку web-серверу, с номером порта 25 - почтовому серверу, номер 22 адресуется серверу SSH и так далее.
Распределение пакета данных IP по сервисам в соответствии с номером порта
TCP- и UDP-порты
Порты используются протоколами TCP или UDP.
TCP - это основной транспортный протокол интернета, который обеспечивает доставку данных через соединение, предварительно установленное между двумя компьютерами. Соединение работает на протяжении всего сеанса связи.
Протокол UDP предназначен для быстрой передачи порции данных без гарантии доставки и без предварительной установки соединения.
Оба протокола в заголовке пакета данных указывают порт получателя, а также исходящий номер порта. Протокол TCP устанавливает соединение, при котором данные между сервером и клиентом обмениваются между исходящим портом клиента и входящим портом сервера.
Диапазоны портов
Номер порта может находиться в диапазоне от 0 до 65535. Как и другие используемые в сети Интернет ресурсы, номера портов стандартизированы. Все порты в диапазоне 1-1023 называются “системными портами” и распределены, согласно списку, от координационного центра Internet организации IANA.
Порты в диапазоне 1024-49151 называются “пользовательскими”, и они предназначены для настройки дополнительных сервисов по выбору пользователя.
Оставшиеся порты из диапазона 49152-65535 называются “динамическими” и предназначены для использования операционной системой для установки соединений в рамках протокола TCP/IP.
Список портов и протоколов
Технически администратор сервера может гибко настраивать используемые порты для каждого из запускаемых на сервере сетевых сервисов. Например, при желании он может изменить номер порта, на котором работает web-сервер, с 80 на 8080. Но при этом, если пользователи не знают, что номер порта изменен, то они не смогут присоединиться к web-серверу. Поэтому для публичных сетевых сервисов принято применять стандартные номера портов.
Таблица наиболее важных и распространенных номеров портов выглядит так:
Номер порта | Протокол | Название сервиса |
20 | TCP | FTP - данные |
21 | TCP | FTP - контрольное соединение |
22 | TCP | SSH-сервер |
23 | TCP | Telnet-сервер |
25 | TCP | SMTP - отправка почты |
53 | TCP, UPD | DNS - сервер доменных имен |
69 | UPD | TFTP-сервер |
80 | TCP | HTTP - web-сервер |
110 | TCP | POP3 - прием почты |
145 | TCP | IMAP - прием почты |
161 | UPD | SNMP - протокол управления сетевыми устройствами |
443 | TCP | HTTPS - защищенный шифрованием протокол HTTP |
587 | TCP | Защищенный шифрованием протокол SMTP |
993 | TCP | Защищенный шифрованием протокол IMAP |
995 | TCP | Защищенный шифрованием протокол POP3 |
1500 | TCP | Панель ISPManager |
2083 | TCP | Панель cPanel |
3306 | TCP | Сервер базы данных MySQL |
8083 | TCP | Панель Vesta |
Порты и URL
Как просмотреть список используемых портов на сервере
Для пользователей виртуальных и выделенных серверов может понадобиться просмотреть список применяемых на сервере портов TCP и UDP. Для этой задачи в операционной системе Linux имеется утилита Netstat.
Утилита Netstat работает из командной строки. Чтобы просмотреть список используемых для входящих соединений портов, прослушиваемых запущенными на сервере сетевыми сервисами, примените следующую команду:
Netstat выводит информацию в несколько колонок. Номер порта, на который принимаются соединения, можно увидеть в колонке “Local address”. Также в колонке “PID/Program name” можно увидеть, какая программа на сервере слушает конкретный порт.
Порты и безопасность сервера
Порты TCP и UDP используются для соединения с сервером, а значит, могут подвергаться атакам. Например, протокол SSH работает по умолчанию на порте 22, и злоумышленники часто ведут атаку на этот порт, пытаясь подобрать пароль от сервера.
Для повышения уровня безопасности вы можете изменить номер порта для SSH. Например, замените порт 22 на 2222.
Конкретно в случае с SSH, смена номера порта - хорошее решение. В случае, если вы измените номер порта, для злоумышленников не будет даже выводиться окно, в котором нужно вводить пароль. Соединение с сервером будем прервано, так как номер порта будет изменен.
1. Отредактируйте на сервере файл /etc/ssh/sshd_config.
2. Найдите в файле строку “Port 22” и измените ее на “Port 2222”.
3. Перезагрузите программу-сервис sshd командой:
Теперь сервер будет принимать SSH-соединения по нестандартному порту 2222, который не известен злоумышленникам.
В других случаях порты менять не нужно, так как большинство плагинов, модулей, почтовых программ и другого стороннего ПО для работы с сайтами и серверами настроено по умолчанию для работы по стандартным портам.
Выводы
1. TCP и UPD- протоколы транспортного уровня:
- обеспечивают доставку данных от одного адресата другому;
- сохраняют правильную последовательность передачи данных.
2. Для просмотра списка используемых на сервере портов TCP и UDP используйте утилиту Netstst в операционной системе Linux.
Система доменных имен (DNS, Domain Name System) представляет собой механизм, а именно распределенную БД, предназначенный для поиска по имени хоста его IP адреса и некоторой другой информации (например, имени почтового сервера). В статье описываются:
Пространство доменных имен
Поддерево вместе со своим корневым узлом называется доменом (поддоменом). Имя домена определяется полным именем его корневого узла. Группировка узлов в домены является чисто логической, т.е. не определяется ни месторасположением, ни IP-адресом, ни маршрутизацией. Узел входит в состав нескольких вложенных доменов (поддеревьев) по пути от узла к корню. Домен первого (высшего) уровня в качестве непосредственного предка имеет корневой узел. Домен второго уровня в качестве непосредственного предка имеет домен первого уровня.
Дерево доменых имен делится на независимо администрируемые части, называемые зонами (здесь имеются в виду права на администрирование части БД пространства доменных имен, а не на администрирование самих хостов). Зона включает в себя домен, делегированный данной организации, за вычетом поддоменов, право администрирования которыми было делегировано ею другим организациям.
Кроме пространства доменных имен Интернет допустимы частные пространства имен.
Архитектура системы доменных имен
Клиенты обычно реализуются в виде библиотеки подпрограмм, присоединяемых к каждой программе (статически или динамически), которой требуется сервис доменных имен. Простой (stub) клиент обращается к указанному при настройке DNS серверу (серверам), интерпретирует ответ и возвращает результат запросившей программе. Если используется протокол UDP, то клиент должен уметь обрабатывать ошибки. Если сервер не отвечает, клиент должен уметь использовать запасной(ые). Реализация клиента в Solaris и Linux позволяет также получить информацию из других источников (локальный файл, NIS, NIS+ и т.д.) в зависимости от настройки Name Service Switch. Некоторые клиенты позволяют кешировать информацию самостоятельно, либо с помощью nscd.
Сервер DNS может не только отвечать на запросы о своей зоне, но и производить поиск в пространстве доменных имен по запросу клиентов, тем более, что большинство клиентов неспособны делать это самостоятельно. Сервер может ограничить список клиентов, на запросы которых подобного типа он будет отвечать (например, IP адресами из локальной сети).
Еще существуют (существовали, RFC 3425?) инверсные запросы (inverse queries), при котором DNS сервер производит поиск в локальных данных доменного имени, имеющего требуемое значение RR.
При выборе одного из уполномоченных серверов зоны используется время отклика (RTT, roundtrip time). При первых запросах уполномоченные сервера опрашиваются по очереди в случайном порядке. В дальнейшем используется уполномоченный сервер зоны, имеющий минимальное RTT.
Пространство доменных имен Интернет
gTLD управляет GNSO ICANN, общий список регистраторов. Хотя права на администрирование каждого конкретного домена высшего уровня делегированы одной конкретной организации (оператору регистра), но зарегистрировать свой домен второго уровня в большинстве из них можно у одного из многочисленных регистраторов (коммерческие организации, имеющие доступ к общей базе данных оператора регистра). На сайте регистратора имеется whois-сервис для соответствующего домена. Такая двухуровневая система была разработана для обеспечения конкуренции между регистраторами. Более того, так как в таких странах как Россия нет действующих местных регистраторов gTLD, то для оплаты услуг в местной валюте придется прибегнуть к услугам агентов, посредников или провайдера (это уже третий уровень). Список gTLD:
Список ccTLD базируется на стандарте двухбуквенных кодов государств и зависимых територрий ISO 3166. В каждой стране свои правила регистрации доменов второго уровня.Поиск информации можно начать со списков регистраторов и whois-сервисов:
Отображение адресов в имена
Зоны верхнего уровня в домене in-addr.arpa. делегированы IANA региональным регистраторам (RIR, Regional Internet Registrator) вместе с блоками IP-адресов.
Записи о ресурсах (RR, Resource Records)
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
Расширение протокола TSIG
Данный механизм требует меньшей нагрузки на процессор и меньших затрат на создание инфраструктуры при небольшом количестве узлов по сравнению с DNSSEC с его механизмами ассиметричного шифрования и публичных ключей (RFC 2535, RFC 2137). С другой стороны DNSSEC позволяет легко масштабировать установленную инфраструктуру распределения ключей и обеспечивать цифровую подпись (TSIG несмотря на название не позволяет производить подтверждение авторства запросов из-за симметричности ключа).
Динамические изменения зоны
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 от времени обновления зоны.
Клиент может получить список потенциальных серверов из записей SOA, NS или внешними средствами.
Сервер может проверять право клиента на изменение зоны по его IP адресу (не рекомендуется) или при помощи механизма TSIG.
DNS клиент (resolver)
Настройка работы клиента DNS производится с помощью файла /etc/resolv.conf или переменных окружения при запуске процесса.
Переменная окружения 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?):
Глава 14 DNS: система имен доменов
С точки зрения приложения, доступ к DNS осуществляется посредством разборщика (resolver) (разборщик (resolver) - подпрограммы, которые используются для создания, отправки и интерпретации пакетов, используемых серверами имен Internet). В Unix системах, к разборщику можно получить доступ через две библиотечные функции, gethostbyname(3) и gethostbyaddr(3), которые линкуются с приложением, когда оно строится. Первая воспринимает в качестве аргумента имя хоста и возвращает IP адрес, а вторая воспринимает в качестве аргумента IP адрес и возвращает имя хоста. Разборщик устанавливает контакты с одним или несколькими серверами DNS (name servers), чтобы установить это соответствие.
На рисунке 4.2 показано, что разборщик - это часть приложения. Он не является частью ядра операционной системы как протоколы TCP/IP. Приложение должно конвертировать имя хоста в IP адрес, перед тем как оно попросит TCP открыть соединение или послать датаграмму с использованием UDP. Протоколы TCP/IP внутри ядра ничего не знают о DNS.
В этой главе мы рассмотрим, как разборщики общаются с DNS серверами с использованием протоколов TCP/IP (в основном UDP). Однако мы не будем рассматривать установку и администрирование DNS серверов или все опции, существующие у разборщиков и серверов. Это может составить еще одну книгу. (В публикации [Albitz and Liu 1992] приведены подробности функционирования стандартных Unix разборщиков и серверов DNS.)
RFC 1034 [ Mockapetris 1987a] описывает концепции, лежащие в основе DNS, а RFC 1035 [Mockapetris 1987b] содержит подробности разработки и спецификации DNS. Наиболее широкоиспользуемая реализация DNS, как разборщика, так и сервера - BIND (Berkeley Internet Name Domain). Процесс сервера называется named. Анализ траффика, генерируемого DNS в глобальных сетях, приводится в [Danzig, Obraczka, and Kumar 1992].
Пространство имен DNS имеет иерархическую структуру, которая внешне напоминает файловую систему Unix. На рисунке 14.1 показана иерархическая организация DNS.
Рисунок 14.1 Иерархическая организация DNS.
Каждый узел (кружочки на рисунке 14.1) имеет метку длиной до 63 символов. Корень дерева это специальный узел без метки. Метки могут содержать заглавные буквы или маленькие. Имя домена (domain name) для любого узла в дереве - это последовательность меток, которая начинается с узла выступающего в роли корня, при этом метки разделяются точками. (Здесь видно отличие от файловой системы Unix, где полный путь всегда начинается с вершины (корня) и опускается вниз по дереву.) Каждый узел дерева должен иметь уникальное имя домена, однако одинаковые метки могут быть использованы в различных точках дерева.
Имя домена, которое заканчивается точкой, называется абсолютным именем домена (absolute domain name) или полным именем домена ( FQDN - fully qualified domain name). Например, sun.tuc.noao.edu.. Если имя домена не заканчивается на точку, подразумевается, что имя должно быть завершено. Как будет закончено имя, зависит от используемого программного обеспечения DNS. Если незаконченное имя состоит из двух или более меток, его можно воспринимать как законченное или полное; иначе справа от имени должен быть добавлен локальный суффикс. Например, имя sun может быть завершено локальным суффиксом .tuc.noao.edu..
- arpa это специальный домен, используемый для сопоставления адрес - имя (раздел "Запросы указателя" этой главы).
- Семь 3-символьных доменов называются общими (generic) доменами. В некоторых публикациях они называются организационными (organizational) доменами.
- Все 2-символьные домены, основанные на кодах стран, можно найти в ISO 3166. Они называются доменами стран (country), или географическими (geographical) доменами.
На рисунке 14.2 приведен список обычной классификации семи основных доменов.
Рисунок 14.2 3-символьные общие домены.
Одна важная характеристика DNS, не показанная на рисунке 14.1, это передача ответственности внутри DNS. Не существует организации, которая бы управляла и обслуживала все дерево в целом и каждую метку в отдельности. Вместо этого, одна организация (NIC) обслуживает только часть дерева (домены верхнего уровня), а ответственность за определенные зоны передает другим организациям.
Зона (zone) это отдельно администрируемая часть дерева DNS. Например, домен второго уровня noao.edu это отдельная зона. Многие домены второго уровня поделены на меньшие зоны. Например, университет может поделить свою зону на подзоны по факультетам, а компания может поделить себя на зоны по принципу деления на филиалы или отделы.
Если Вы знакомы с файловой системой Unix, то обратите внимание, что деление дерева DNS на зоны очень напоминает деление на логические файловые системы физических дисковых разделов. Однако мы не можем сказать, основываясь на рисунке 14.1, под чьим руководством находятся зоны, также как мы не можем по подобному рисунку сказать, какие директории в файловой системе находятся в определенном дисковом разделе.
С того момента, как выбрана организация или персона, которая несет ответственность за управление зоной, эта организация или персона должна организовать несколько серверов DNS (name servers) для этой зоны. Как только в зоне появляется новая система, администратор этой зоны помещает имя и IP адрес нового хоста в базу данных сервера DNS. В небольших университетах, например, один человек может делать это каждый раз при появлении новой системы, однако в больших университетах ответственность должна быть распределена (например, по департаментам), так как один человек не может осуществлять эту работу в целом.
Сервер DNS, скажем, обслуживает одну зону или несколько зон. Человек, который несет ответственность за зону, администрирует основной сервер DNS (primary name server) для этой зоны и один или несколько вторичных серверов DNS (secondary name servers). Первичный и вторичный сервера должны быть независимы и избыточны таким образом, чтобы система DNS не вышла из строя при отказе одного из серверов.
Основное отличие между первичными и вторичными серверами заключается в том, что первичные загружают всю необходимую информацию из дисковых файлов, тогда как вторичные получают информацию от первичного. Процесс передачи информации от первичного сервера вторичному называется передачей зоны (zone transfer). Когда в зоне появляется новый хост, администратор добавляет соответствующую информацию (минимум, имя и IP адрес) в дисковый файл на первичном сервере. После чего первичный сервер DNS уведомляется о необходимости повторно считать свои конфигурационные файлы. Вторичные сервера регулярно опрашивают первичные (обычно каждые 3 часа), и если первичные содержат новую информацию, вторичный получает ее с использованием передачи зоны.
Что произойдет, если сервер DNS не содержит необходимой информации? Он должен установить контакт с другим сервером DNS. (В этом заключается распределенная природа DNS.) Однако не каждый сервер DNS знает, как обратиться к другому серверу. Вместо этого каждый сервер DNS должен знать, как установить контакт с корневыми серверами DNS (root name servers). В апреле 1993 года существовало восемь корневых серверов, все первичные сервера должны знать IP адреса каждого корневого сервера. (Эти IP адреса находятся в конфигурационных файлах первичного сервера. Первичные сервера должны знать именно IP адреса корневых серверов, а не их DNS имена.) Корневой сервер, в свою очередь, знает имена и положения (IP адрес) каждого официального сервера DNS для всех доменов второго уровня. При этом возникает последовательный процесс: запрашивающий сервер должен установить контакт с корневым сервером. Корневой сервер сообщает запрашивающему серверу о необходимости обратиться к другому серверу и так далее. Мы рассмотрим эту процедуру и соответствующие примеры позже в этой главе.
Фундаментальная характеристика DNS - это кэширование (caching). Когда DNS сервер получает информацию о соответствии (скажем, IP адресов именам хостов), он кэширует эту информацию таким образом, что в случае следующего запроса может быть использована информация из кэша, дополнительный запрос на другие сервера не делается. В разделе "Кэширование" этой главы мы рассмотрим кэширование более подробно.
Рисунок 14.3 Общий формат DNS запроса и ответа.
Значение в поле идентификации (identification) устанавливается клиентом и возвращается сервером. Это поле позволяет клиенту определить, на какой запрос пришел отклик.
16-битовое поле флагов (flags) поделено на несколько частей, как показано на рисунке 14.4.
Рисунок 14.4 Поле флагов (flags) в заголовке DNS.
Раздел вопросов в DNS запросе
Формат каждого вопроса в разделе вопросов (question) показан на рисунке 14.5. Обычно присутствует только один вопрос.
Имя запроса (query name) это искомое имя. Оно выглядит как последовательность из одной или нескольких меток. Каждая метка начинается с 1-байтового счетчика, который содержит количество следующих за ним байт. Имя заканчивается байтом равным 0, который является меткой с нулевой длиной. И является, в свою очередь, меткой корня. Каждый счетчик байтов должен быть в диапазоне от 0 до 63, так как длина метки ограничена 63 байтами.
Рисунок 14.5 Формат раздела вопроса (question) в запросе DNS.
На рисунке 14.6 показано, как хранится имя домена gemini.tuc.noao.edu.
Рисунок 14.6 Представление имени домена gemini.tuc.noao.edu.
У каждого вопроса есть тип запроса (query type), а каждый отклик (называемый записью ресурса, о чем мы поговорим ниже) имеет тип (type). Существует около 20 различных значений, некоторые из которых в настоящее время уже устарели. На рисунке 14.7 показаны некоторые из этих значений. Тип запроса это надмножество (множество, подмножеством которого является данное множество) типов: два из показанных значений, могут быть использованы только в вопросах.
Читайте также: