|
Bog BOS: DNS (Domain Name System) |
|
Последние изменения: |
Последнее изменение файла: 2019.12.05
Скопировано с www.bog.pp.ru: 2024.11.23
Система доменных имен (DNS, Domain Name System) представляет собой механизм, а именно распределенную БД, предназначенный для поиска по имени хоста его IP адреса и некоторой другой информации (например, имени почтового сервера). В статье описываются
Пространство доменных имен имеет вид дерева (иерархии) узлов. Каждый узел дерева помечен простым именем. Простое имя начинается на букву Latin-1 (в процессе эволюции стандарта было разрешено начинать простое имя с цифры), кончается на букву или цифру, в промежутке буквы или цифры или минус (RFC 952). Протокол DNS допускает использование любых значений октетов в простом имени, но традиции нарушать не стоит - последствия вам не понравятся. Прописные и строчные буквы не различаются. Длина простого имени - не более 63 символов. Простые имена узлов, имеющих общего предка, должны быть уникальны. Полное имя узла записывается как последовательность простых имен самого узла и всех его предков до корня включительно, записываемых слева направо и разделяемых точками. Имя корня - пустая строка, т.е. полное имя обязательно завершается точкой (заметьте, что в некоторых случаях, например, при записи почтовых адресов, заключительная точка должна быть опущена). Максимальная длина полного имени - 255 символов, включая точки. Максимальное число уровней дерева - 127. Кроме полного (абсолютного) имени узла (FQDN, fully qualified domain name) некоторые программы позволяют использовать относительные (относительно некоторого опорного узла) имена. Относительные имена отличаются отсутствием завершающей точки (и путаются при этом с именами почтовых доменов также не имеющими завершающей точки!).
Полное (доменное) имя узла (не обязательно листового) используется как индекс для доступа к БД, содержащей информацию об узлах. Если узлу соответствует некоторый хост, то таким образом можно получить информацию об этом хосте.
Поддерево вместе со своим корневым узлом называется доменом (поддоменом). Имя домена определяется полным именем его корневого узла. Группировка узлов в домены является чисто логической, т.е. не определяется ни месторасположением, ни IP-адресом, ни маршрутизацией. Узел входит в состав нескольких вложенных доменов (поддеревьев) по пути от узла к корню. Домен первого (высшего) уровня в качестве непосредственного предка имеет корневой узел. Домен второго уровня в качестве непосредственного предка имеет домен первого уровня.
Дерево доменых имен делится на независимо администрируемые части, называемые зонами (здесь имеются в виду права на администрирование части БД пространства доменных имен, а не на администрирование самих хостов). Зона включает в себя домен, делегированный данной организации, за вычетом поддоменов, право администрирования которыми было делегировано ею другим организациям.
Кроме пространства доменных имен Интернет допустимы частные пространства имен.
Пространство доменных имен реализовано в виде распределенной БД, включающей в себя серверы DNS, клиенты DNS (resolver), объединенные общим протоколом запросов к БД и обмена информацией между серверами. Информация, индексированная доменным именем, хранится в записях ресурсов (RR, resource records). Запись ресурса имеет класс (в настоящее время используются записи класса интернет - IN), тип записи (определяет характер хранимой информации) и саму информацию. В частности, для каждого ресурса хранится максимально допустимое время кеширования полученной информации (TTL, time to live). Совокупность записей ресурсов, имеющих совпадающее доменное имя, класс и тип, называется набором записей ресурсов (RRset). Основным типом хранимой информации являются IP адреса. Доменному имени может соответствовать несколько IP-адресов (несколько сетевых интерфейсов на компьютере), одному адресу может соответствовать несколько имен (синонимы). Порядок выдачи записей при запросе не обязан соответствовать порядку записей при описании зоны.
Уполномоченный (авторитативный, authoritative) сервер обладает полной информацией об определенной зоне. Адреса уполномоченных серверов зоны (домена, объемлющего зону) указываются в информации о родительском домене. Уполномоченные сервера делятся на первичные (primary master) и вторичные (secondary master, slave). Первичный сервер загружает данные зоны из локального источника (обычно из файла). Вторичный сервер получает данные зоны от другого уполномоченного сервера (обычно, но не обязательно от первичного сервера). Этот процесс называется передачей зоны (zone transfer). При недоступности исходного уполномоченного сервера вторичный сервер может загружать зону из резервной копии, предусмотрительно сохраненной в файле. Наличие нескольких уполномоченных серверов позволяет разделить нагрузку и обеспечить защиту от сбоев. DNS сервер (процесс) может быть уполномоченным сразу для нескольких зон или ни для одной (кеширующий сервер), причем для одних зон он может быть первичным, а для других - вторичным. Уполномоченный сервер, указанный в родительском домене (при делегировании зоны), но не описанный в записи самой зоны, называется скрытым (stealth) уполномоченным сервером. Скрытым может быть и первичный сервер (hidden primary). Используется в ситуации, когда первичный сервер находится за сетевым экраном. Неверная настройка, при которой уполномоченный сервер, указанный в родительском домене (при делегировании зоны), отказывается признавать себя уполномоченным, называется ламерским делегированием (lame delegation, lame servers).
Клиенты обычно реализуются в виде библиотеки подпрограмм, присоединяемых к каждой программе (статически или динамически), которой требуется сервис доменных имен. Простой (stub) клиент обращается к указанному при настройке DNS серверу (серверам), интерпретирует ответ и возвращает результат запросившей программе. Если используется протокол UDP, то клиент должен уметь обрабатывать ошибки. Если сервер не отвечает, клиент должен уметь использовать запасной(ые). Реализация клиента в Solaris и Linux позволяет также получить информацию из других источников (локальный файл, NIS, NIS+ и т.д.) в зависимости от настройки Name Service Switch. Некоторые клиенты позволяют кешировать информацию самостоятельно, либо с помощью nscd.
Сервер DNS может не только отвечать на запросы о своей зоне, но и производить поиск в пространстве доменных имен по запросу клиентов, тем более, что большинство клиентов неспособны делать это самостоятельно. Сервер может ограничить список клиентов, на запросы которых подобного типа он будет отвечать (например, IP адресами из локальной сети).
Для начала поиска информации о любом доменном имени серверу (или продвинутому клиенту) необходимо знать лишь адреса корневых серверов DNS. Корневые сервера (их 13 штук, от a.root-servers.net. до m.root-servers.net.; список адресов можно узнать командой host -t NS .; зеркало f.root-servers.net расположено на M9-IX) являются уполномоченными для корневой зоны и содержат ссылки на уполномоченные сервера зон первого уровня или сами являются уполномоченными серверами некоторых зон первого уровня (например, com. или net.). Число 13 определяется максимальным размером пакета UDP, который не будет фрагментирован в любой реализации (576 байт), в такой пакет как раз помещается ответ о 13 адресах. Список корневых серверов в формате зоны можно скопировать отсюда. Он используется при запуске сервера, чтобы обратиться к одному из корневых серверов из этого списка для получения текущего состояния корневой зоны. По истечении TTL запрос текущего состояния корневой зоны повторяется с использованием первоначального списка (root hints). На запрос о домене корневой сервер возвращает как минимум имя и адрес уполномоченного сервера домена первого уровня, в который входит указанный в запросе домен. Обратившись по полученному адресу можно получить имя и адрес уполномоченного сервера домена второго уровня и т.д.
Запросы клиентов (или серверов) могут быть рекурсивными или итеративными. Рекурсивный запрос подразумевает, что запрашиваемый сервер должен самостоятельно пробежаться по всей цепочке до получения конечного ответа (в т.ч. отрицательного) и вернуть его клиенту. При этом сам сервер может пользоваться итеративными или рекурсивными запросами. Сервер может отказаться выполнять рекурсивные запросы "чужих" клиентов. При итеративном запросе сервер делает только один шаг поиска и возвращает ссылку на "более подходящий" сервер (или конечный ответ, если он сам является авторитативным для данного домена). Цикл поиска производится самим клиентом. Вся полученная информация как о запрашиваемом домене, так и о "промежуточных" уполномоченных серверах кешируется. Кешироваться могут и отрицательные ответы. При кешировании используется значение TTL.
Еще существуют (существовали, RFC 3425?) инверсные запросы (inverse queries), при котором DNS сервер производит поиск в локальных данных доменного имени, имеющего требуемое значение RR.
При выборе одного из уполномоченных серверов зоны используется время отклика (RTT, roundtrip time). При первых запросах уполномоченные сервера опрашиваются по очереди в случайном порядке. В дальнейшем используется уполномоченный сервер зоны, имеющий минимальное RTT.
Корневой зоной Интернет и системой корневых серверов управляет ICANN (Internet Corporation for Assigned Names and Numbers, неприбыльная частная организация с неясными юридическими правами относительно Интернет, ее "власть" основана на всеобщем добровольном доверии, организована по решению Министерства Торговли США). Ранее этим занималась IANA (Internet Assigned Numbers Authority), за которой и сейчас остались административные функции. В частности, ICANN делегирует права управления зонами первого уровня gTLD (generic top-level domains) и ccTLD (country code top-level domains).
gTLD управляет GNSO ICANN, общий список регистраторов). Хотя права на администрирование каждого конкретного домена высшего уровня делегированы одной конкретной организации (оператору регистра), но зарегистрировать свой домен второго уровня в большинстве из них можно у одного из многочисленных регистраторов (коммерческие организации, имеющие доступ к общей базе данных оператора регистра). На сайте регистратора имеется whois-сервис для соответствующего домена. Такая двухуровневая система была разработана для обеспечения конкуренции между регистраторами. Более того, так как в таких странах как Россия нет действующих местных регистраторов gTLD, то для оплаты услуг в местной валюте придется прибегнуть к услугам агентов, посредников или провайдера (это уже третий уровень). Список gTLD:
Список ccTLD базируется на стандарте двухбуквенных кодов государств и зависимых територрий ISO 3166. В каждой стране свои правила регистрации доменов второго уровня. Поиск информации можно начать со списков регистраторов и whois-сервисов:
Администатор зоны .ru - РосНИИРОС (RIPN), whois-сервер - whois.ripn.net, список регистраторов зон .ru и .su, статистика по регистраторам и серверам зоны .ru.
ICANN вводит RDAP вместо WHOIS (nicinfo).
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 195.161.72.0@whois.ripe.net), так и зона (whois 72.161.195.in-addr.arpa@whois.ripe.net)
Отображение адресов в имена может быть обязательным для работы некоторых сервисов Интернет: нет отображения - нет обслуживания.
Записи ресурсов могут быть представлены в текстовом формате в файле данных зоны и в двоичном формате при обмене сообщениями протокола 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:
Типы записей, в скобках - код для сообщений протокола 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 обычно используют протокол UDP (порт 53, domain), однако могут использовать и протокол TCP (порт 53, domain). Каждое сообщение полностью помещается в один UDP пакет, стало быть не может быть более 64 KB. В реальности, многие реализации имеют ограничение на размер нефрагментируемого UDP пакета в 576 байт. В такой пакет помещается информация о 10 записях типа NS в общем случае. Доменные имена корневых серверов Интернет были помещены в один домен, что позволило упаковать информацию с помощью ссылок (см. ниже) о 13 серверах. Если ответ не поместился в один фрагмент UDP, то в заголовке устанавливается бит TC (truncated), что приводит к повторному запросу с использованием протокола TCP. При использовании протокола TCP к каждому сообщению добавляется префикс (2 байта), содержащий длину сообщения без учета префикса. Первым передается левый бит (нулевой) - старший по значению.
Формат запросов и ответов одинаков (подробнее см. RFC 1035):
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) редактировать текстовый файл с описанием зоны и перезапускать сервер. С помощью данного расширения можно одним пакетом внести несколько изменений в зону, управляемую данным первичным уполномоченным сервером (все доменные имена должны быть внутри зоны):
Набор изменений может быть предварён набором условий следующих типов (все доменные имена должны быть внутри зоны):
Весь пакет условий и изменений является атомарным, т.е. обрабатывается как единое неделимое целое (как транзакция в СУБД). При этом сервер обязан записать изменения на диск до ответа клиенту. bind временно записывает изменения в журнал и сливает его с файлом зоны позднее. Если изменения не затронули SOA, то сервер должен увеличить серийный номер автоматически. Метод стандартом не задаётся. Если автоувеличение серийного номера производится с задержкой, но она не должна быть более 300 секунд или 1/3 от времени обновления зоны.
RFC 2136 вводит новый класс NONE (254) и несколько новых кодов ответа. Формат запросов и ответов совпадает с форматом обычных запросов и ответов, но имеет код запроса - UPDATE (5). Секция запроса содержит имя изменяемой зоны (ровно одна запись ресурса типа SOA), секция ответа - набор условий, секция ссылок на уполномоченные сервера - добавляемые или удаляемые записи, секция дополнительной информации - связующие записи доменных имён вне зоны (может игнорироваться сервером).
Клиент может получить список потенциальных серверов из записей SOA, NS или внешними средствами.
Сервер может проверять право клиента на изменение зоны по его IP адресу (не рекомендуется) или при помощи механизма TSIG.
Вторичный уполномоченный сервер, получивший запрос на динамическое изменение зоны, может перенаправить его первичному серверу от своего имени (изменив идентификатор запроса) и получив ответ вернуть его клиенту. Тот в свою очередь может переправить его дальше и т.д.. Список используемых серверов совпадает со списком серверов, к которым выдаются запросы на передачу зоны. Если клиент использовал для запроса TCP (рекомендуется, если имеется обработка результата), то вторичный сервер должен использовать для перенаправления запроса также TCP.
Обеспечение правильного порядка применения изменений (так чтобы "задержавшиеся в пути" старые изменения не перекрывали более новые) является нетривиальной задачей в среде TCP/IP, особенно при наличии нескольких делающих запросы клиентов и нескольких перенаправляющих вторичных серверов. Ответ сервера также может задержаться или затеряться. Авторы RFC рекомендуют пользоваться "маркерными" записями ресурсов для обеспечения синхронизации (такой маркер может, например, содержать время выдачи запроса).
Клиенты 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 содержит одну инструкцию, комментарии начинаются с точки с запятой или символа # (осторожно! клиент может не сообщать об ошибках в этом файле!):
Конкретная реализация 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/hosts (рекомендуется указывать как полное, так и краткое имя; обязательно иметь соответствие 127.0.0.1 - localhost.localdomain и localhost):
Формат локального файла /etc/networks (задаёт соответствие между именем сети и адресом сети; устарел, так как не позволяет задавать маску):
Ещё имеется загадочный файл /etc/ppp/resolv.conf.
Настройка DNS в MS Windows производится с помощью графического интерфейса. Изготовитель уверяет, что это очень просто ;). Вот только отличаются реализации клиента DNS в различных версиях MS Windows больше, чем Unix от Linux (в частности, TCP/IP стек в W2000 и XP взят из FreeBSD (NetBSD?):
Вместе с сервером BIND поставляются утилиты dig, host и nslookup для исследования доменного пространства.
Утилита host позволяет получать значения RR указанного типа для указанного доменного имени. Формат вызова:
host [-управляющие-ключи] [-ключи-запроса] доменное-имя-или-адрес [опрашиваемый-сервер].
По умолчанию, используется сервер, описанный при настройке клиентской библиотеки. Доменные имена считаются абсолютными и список поиска не используется. Управляющие ключи модифицируют поведение утилиты:
Ключи запроса указывают тип требуемой информации
Утилита dig позволяет получать значения RR указанного типа для указанного доменного имени в формате файла зоны. В виде комментариев выдается масса вспомогательной информации, в т.ч. интерпретация пакета, полученного в ответ на запрос (см. описание утилиты host). Формат вызова:
dig [@опрашиваемый-сервер] [-опции-dig] доменное-имя [тип-записи] [класс-записи] [+опции-запроса]
По умолчанию, используется сервер, описанный при настройке клиентской библиотеки. Доменные имена считаются абсолютными и список поиска не используется. В качестве требуемого типа записи можно использовать также псевдотипы AXFR (зона передается только от уполномоченного сервера), ixfr=опорный-номер-версии и ANY, по умолчанию: A. В одной командной строке можно сделать несколько запросов.
Опции dig:
Опции запроса:
Значение опций можно установить в файле настройки ~/.digrc.
Полезный пример использования dig для отладки зоны, dig имитирует поведения сервера, выдавая нерекурсивные запросы с трассировкой:
dig +trace company.ru mx
Утилита nslookup объявлена устаревшей и навязчиво напоминает об этом при каждом запуске (даже документация не поставляется, отсутствует команда help и некоторые другие). Формат вызова:
nslookup [-ключи] доменное-имя [опрашиваемый-сервер]
Если доменное имя и имя сервера опущены или используется символ минус вместо доменного имени, то утилита переходит в интерактивный режим работы. Выход из интерактивного режима происходит по команде exit или по нажатию ^D (конец ввода). По нажатию ^С (прерывание программы) утилита прерывает выполнение текущей операции и возвращается в интерактивный режим. Предусмотрены следующие команды (имена параметров можно сокращать):
Значение параметра или переключателя можно установить ключом командной строки (символ минус перед именем параметра) или в файле настройки ~/.nslookuprc (может содержать команды set по одной в строке).
|
Bog BOS: DNS (Domain Name System) |
|
Последние изменения: |