Система доменных имен

Материалы книги П.Б. Храмцова
iнфоцентр

Resolver. Типовые настройки

В данном материале разбираются настройки и принципы функционирования resolver в различных версиях BIND. Обсуждаются также особенности resolver, поставляемого в дистрибутиве клонов Unix.

Как уже говорилось выше, система разрешения доменных имен IP-адресами и обратная процедура построены по схеме "клиент-сервер". Функции из библиотеки libc.a (или libc.so) выступают в качестве клиентов, а вся их совокупность носит название resolver. Для того, чтобы клиент мог обратиться к серверу, он должен знать следующее:

• Установлен ли вообще сервер доменных имен,
• Если сервер установлен, то где (IP-адрес сервера доменных имен).
• Если сервер установлен, то к какому домену относится машина.

Иногда название BIND (Berkeley Internet Name Domain) вводит новичков в заблуждение. Им кажется, что речь идет не о программе, а некой альтернативе другой системе доменных имен. Для того чтобы этого избежать, иногда вместо слова "domain" используют слово "daemon", обычно употребляющиеся для обозначения программ-демонов в системах Unix, которые находятся в памяти компьютера и выполняют служебные операции. Для того чтобы потом не повторяться, сразу поясним различия между DNS и BIND.

Знать это нужно для того, чтобы правильно формировать запросы к серверу/ам доменных имен и не перегружать систему лишними или некорректными запросами.

Главная задача resolver - принять запрос от прикладного программного обеспечения, провзаимодействовать с серверами DNS и вернуть в зависимости от запроса либо IP-адрес, либо доменное имя.

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

Рис.1. Типовая схема взаимодействия Resolver с локальным сервером доменных имен.

На практике второй способ является наиболее распространенным. При этом согласно RFC-1034 речь идет о так называемом "усеченном" resolver (stub resolver).

В RFC-1034 указано также, что основной задачей resolver является обеспечение максимально быстрого обслуживания запросов прикладных программ к системе DNS. Основное место здесь отводится кэширующим resolver-ам. Однако, stub resolver таковым не является. Это значит, что каждый раз, когда прикладная программа запрашивает систему DNS resolver посылает запрос локальному серверу доменных имен.

Любопытно, что в стандартном resolver (см. man resolver - http://ddb.kharkov.ua/cgi-bin/bsdi-man?proto=1.1&query=resolver&msection=3&apropos=0, например) предусмотрена возможность итеративного опроса серверов доменных имен, но не предусмотрена возможность кэширования.

В Windows 2000 предусмотрен кэширующий resolver, который запускается в системе в качестве сервиса по умолчанию. Существует возможность остановки и повторного пуска этого сервиса, а также просмотра результатов его работы. Важно отметить, что данный resolver умеет осуществлять "отрицательное" кэширование (negative caching). Это значит что, если на какой-либо запрос поступает отрицательный ответ, например, отсутствие данного доменного имени, то этот ответ запоминается, и в следующий раз прикладная программа получит "отлуп" прямо из кэша resolver, а не после процедуры безуспешного поиска по серверам доменных имен. Естественно, что "отрицательный" ответ хранится в кэше resolver ограниченное время (Windows 2000 TCP/IP. DNS Resolver Cache Service.).

На самом деле, появление нового resolver в Windows 2000 позволило решить некоторые проблемы, которые windows-системы доставляли системе доменных имен (см. "Полезные ссылки" [2]). Впрочем всех проблем новый resolver Microsoft так и не решил.

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

Рассуждения о настройке resolver мы будем вести в терминах Unix системы, если речь пойдет о другом операционном окружении, то это будет оговорено отдельно.

Традиционно вся совокупность параметров настройки resolver задается в файле /etc/resolv.conf. Приведем примера этого файла и разберем назначение каждой из команд, которая может быть использована в файле настройки resolver.

#
# Resolver config for paul.
#
domain polyn.kiae.su
nameserver 144.206.130.137

Строки, начинающиеся с символа "#" - это комментарии. Среди них следует выделить строку "nonameserver". В нашем примере она не влияет на работу системы разрешения доменных имен, но если в сети нет сервера доменных имен, то следует с этой строки снять символ комментария, а прочие команды напротив превратить в комментарии. При отсутствии сервера доменных имен система будет использовать файл /etc/hosts (см. "История и правила именования хостов").

По директиве domain resolver определяет, в каком домене он функционирует. Это локальное доменное имя. Локальным доменным именем называют имя домена, в который входит хост, где выполняется прикладная программа, использующая библиотеку resolver-а. Например, если хост имеет имя host.kuku.ru, то локальным доменным именем будет kuku.ru.

Узанать локальное доменное имя просто - нужно выполнить команду Hostname: > hostname generate.polyn.kiae.su >

В данном случае локальное доменное имя - polyn.kiae.su.

Обычно, локальным доменным именем, которое указано после директивы domain, расширяются неполные имена хостов. Например, если обратиться к какой-либо машине с компьютера из предыдущего примера только по имени машины:

/usr/paul> telnet radleg

то система расширит имя radleg именем домена, и будет искать машину с именем radleg.polyn.kiae.su.

Указанный выше пример - это только частный случай процедуры расширения неполного имени, которая используется функциями resolver. В литературе этот процесс называется применением списка поиска.

Различают два алгоритма применения списка поиска. Ниже представлен алгоритм, который использует resolver стандартной библиотеки libc.a. Большинство клонов Unix (различные версии этой операционной системы) поставляются именно с таким алгоритмом. Обычно именно он применялся в 4-ых версиях пакета BIND.

В общем виде он выглядит следующим образом:

• Если в прикладной программе указано имя хоста с точкой на конце, то расширение имени не производится:
  

  /usr/paul>ping polyn.
  

  
  В данном случае имя "polyn." завершено точкой.
• Если имя указано без точки, расширение производится по следующим правилам: либо происходит добавление локального домена, либо происходит обращение к файлу синонимов. Вообще говоря, в различных системах это расширение может быть организовано различными способами. Например, HP-UX имя файла синонимов указывается в переменной окружения HOSTALIASES. Пример расширения доменным именем был приведен выше.
• Если в качестве имени указывается составное имя, то производится серия подстановок, при помощи которых пытаются получить IP-адрес хоста. Например, для выполнения команды Ping из ниже приведенного примера:
  

  /usr/paul> ping paul.polyn
  

  Будет выполнена подстановка по следующим правилам: если в качестве домена в resolv.conf указан домен polyn.kiae.su, то будет проверена следующая последовательность имен: paul.polyn; paul.polyn.polyn.kiae.su; paul.polyn.kiae.su. Последнее имя будет разрешено сервером доменных имен. Ниже приведен пример поиска IP-адреса по списку поиска для неполного имени paul.polyn:

  > paul.polyn
  Server:  IRIS.polyn.kiae.su
  Address:  144.206.192.10
  
  
  ;; res_nmkquery(QUERY, paul.polyn, IN, A)
  ------------
  Got answer:
      HEADER:
          opcode = QUERY, id = 53781, rcode = NXDOMAIN
          header flags:  response, auth. answer, want recursion, recursion avail.
          questions = 1,  answers = 0,  authority records = 1,  additional = 0
  
  
      QUESTIONS:
          paul.polyn, type = A, class = IN
      AUTHORITY RECORDS:
      ->  (root)
          ttl = 325 (5m25s)
          origin = A.ROOT-SERVERS.NET
          mail addr = NSTLD.VERISIGN-GRS.COM
          serial = 2002091600
          refresh = 1800 (30M)
          retry   = 900 (15M)
          expire  = 604800 (1W)
          minimum ttl = 86400 (1D)
  
  
  ------------
  ;; res_nmkquery(QUERY, paul.polyn.polyn.kiae.su, IN, A)
  ------------
  Got answer:
      HEADER:
          opcode = QUERY, id = 53782, rcode = NXDOMAIN
          header flags:  response, auth. answer, want recursion, recursion avail.
          questions = 1,  answers = 0,  authority records = 1,  additional = 0
  
  
      QUESTIONS:
          paul.polyn.polyn.kiae.su, type = A, class = IN
      AUTHORITY RECORDS:
      ->  polyn.kiae.su
          ttl = 3600 (1H)
          origin = polyn.net.kiae.su
          mail addr = paul.kiae.su
          serial = 231
          refresh = 3600 (1H)
          retry   = 300 (5M)
          expire  = 9999999 (16w3d17h46m39s)
          minimum ttl = 3600 (1H)
  
  
  ------------
  ;; res_nmkquery(QUERY, paul.polyn.kiae.su, IN, A)
  ------------
  Got answer:
      HEADER:
          opcode = QUERY, id = 53783, rcode = NOERROR
          header flags:  response, auth. answer, want recursion, recursion avail.
          questions = 1,  answers = 1,  authority records = 3,  additional = 3
  
  
      QUESTIONS:
          paul.polyn.kiae.su, type = A, class = IN
      ANSWERS:
      ->  paul.polyn.kiae.su
          internet address = 144.206.192.34
          ttl = 3600 (1H)
      AUTHORITY RECORDS:
      ->  polyn.kiae.su
          nameserver = polyn.net.kiae.su
          ttl = 3600 (1H)
      ->  polyn.kiae.su
          nameserver = ns.spb.su
          ttl = 3600 (1H)
      ->  polyn.kiae.su
          nameserver = ns.ussr.eu.net
          ttl = 3600 (1H)
      ADDITIONAL RECORDS:
      ->  polyn.net.kiae.su
          internet address = 144.206.160.32
          ttl = 85775 (23h49m35s)
      ->  ns.spb.su
          internet address = 193.124.83.69
          ttl = 159806 (1d20h23m26s)
      ->  ns.ussr.eu.net
          internet address = 193.124.22.65
          ttl = 170465 (1d23h21m5s)
  
  
  ------------
  Name:    paul.polyn.kiae.su
  Address:  144.206.192.34
  
  
  >
  

  В этом примере адрес был успешно найден. А вот пример, в котором адрес не был найден:

  > paul.polyn.kiae
  Server:  IRIS.polyn.kiae.su
  Address:  144.206.192.10
  
  
  ;; res_nmkquery(QUERY, paul.polyn.kiae, IN, A)
  ------------
  Got answer:
      HEADER:
          opcode = QUERY, id = 53784, rcode = NXDOMAIN
          header flags:  response, auth. answer, want recursion, recursion avail.
          questions = 1,  answers = 0,  authority records = 1,  additional = 0
  
  
      QUESTIONS:
          paul.polyn.kiae, type = A, class = IN
      AUTHORITY RECORDS:
      ->  (root)
          ttl = 86400 (1D)
          origin = A.ROOT-SERVERS.NET
          mail addr = NSTLD.VERISIGN-GRS.COM
          serial = 2002091600
          refresh = 1800 (30M)
          retry   = 900 (15M)
          expire  = 604800 (1W)
          minimum ttl = 86400 (1D)
  
  
  ------------
  ;; res_nmkquery(QUERY, paul.polyn.kiae.polyn.kiae.su, IN, A)
  ------------
  Got answer:
      HEADER:
          opcode = QUERY, id = 53785, rcode = NXDOMAIN
          header flags:  response, auth. answer, want recursion, recursion avail.
          questions = 1,  answers = 0,  authority records = 1,  additional = 0
  
  
      QUESTIONS:
          paul.polyn.kiae.polyn.kiae.su, type = A, class = IN
      AUTHORITY RECORDS:
      ->  polyn.kiae.su
          ttl = 3600 (1H)
          origin = polyn.net.kiae.su
          mail addr = paul.kiae.su
          serial = 231
          refresh = 3600 (1H)
          retry   = 300 (5M)
          expire  = 9999999 (16w3d17h46m39s)
          minimum ttl = 3600 (1H)
  
  
  ------------
  ;; res_nmkquery(QUERY, paul.polyn.kiae.kiae.su, IN, A)
  ------------
  Got answer:
      HEADER:
          opcode = QUERY, id = 53786, rcode = NOERROR
          header flags:  response, auth. answer, want recursion, recursion avail.
          questions = 1,  answers = 0,  authority records = 1,  additional = 0
  
  
      QUESTIONS:
          paul.polyn.kiae.kiae.su, type = A, class = IN
      AUTHORITY RECORDS:
      ->  kiae.su
          ttl = 86400 (1D)
          origin = ns.kiae.ru
          mail addr = noc-dns.relarn.ru
          serial = 650127450
          refresh = 28800 (8H)
          retry   = 3600 (1H)
          expire  = 604800 (1W)
          minimum ttl = 86400 (1D)
  
  
  ------------
  Name:    paul.polyn.kiae.kiae.su
  
  
  >
  

  Запрашивался адрес для неполного имени paul.polyn.kiae, в resolv.conf в качестве локального имени домена было указано:

  domain polyn.kiae.su
  

  Почему же мы не нашли адреса для имени? Потому, что список поиска остановился на paul.polyn.kiae.kiae.su, т.е. при переборе имен локальное доменное имя можно усечь только до имени состоящего из меток двух доменов. В нашем случае - это kiae.su.

Если ваш resolver ведет себя приведенным выше способом, то следует проверить, что в директиве domain срока заканчивается не пробелом, а отображаемым символом. В противном случае возможны ошибки при разрешении имен.

Усечение до двухзвенного имени вызвано проблемой, которая описана в RFC-1535. Суть ее заключается в том, при полном поиске, т.е. при подстановке и однозвенного имени появлялась реальная возможность "улететь" совсем на другой хост.

Например, если зарегистрировать в com домен ru (ru.com), то для всех пользователей машин из домена com, которые хотят попасть в домен ru, появляется возможность попасть в приватный домен ru.com, т.к. обычно пользователи не указывают на конце символа ".". При этом у администратора домена ru.com появляется возможность по своему усмотрению накручивать, например, сайт www.ru.com.

К слову сказать, ru.com уже зарегистрирован. Вот отчет whois:

Registrant:
Central Nic Ltd (RU70-DOM)
   13 Bowerdean St Fulham
   London, SW6 3TU
   UK


   Domain Name: RU.COM


   Administrative Contact, Technical Contact:
      Hostmaster  (HO4073-ORG)		hostmaster@CENTRALNIC.NET
      CentralNic Ltd
      163 New Kings Road
      London
      UK
      +44 20 7384 3050Fax- +44 20 7736 9253
      Fax- - +44 20 7736 9253


   Record expires on 23-Jun-2010.
   Record created on 23-Jun-2000.
   Database last updated on 16-Sep-2002 10:56:25 EDT.


   Domain servers in listed order:


   NS0.CENTRALNIC.NET           195.82.125.70
   NS1.CENTRALNIC.NET           212.18.224.66
   LON-NS-2.CENTRALNIC.NET      195.149.39.141
   ESS-NS-0.CENTRALNIC.NET      194.221.62.8
   NS0.JML.NET                  195.149.39.76

Кроме того, www.ru.com тоже уже занят.

Новые (с BIND 4.9) версии resolver, которые входят в состав BIND работают иначе:

• Если введено имя хоста без точек, то оно расширяется локальным доменным именем
• Если пункт 1 не дал результата, то введенное имя используется в качестве имени TLD.
• Если введенное имя содержит составное, но не полное (fully qualified domain name - FQDN), имя, то в этом случае сначала проверяется введенное имя без расширения его локальным доменным именем.
• Если пункт 3 не дал результата, то введенное имя расширяется локальным доменным именем.

Усечений локального доменного имени в этом алгоритме не предусмотрено.

Если по каким-либо причинам стандартный алгоритм применения списка поиска не устраивает, то тогда вместо директивы damin в resolv.conf применяют директиву search:

search corp.ru .

После директивы search через пробел или табуляцию указывают доменные имена, которые будут расширять введенное пользователем имя, если оно не относится к FQDN.

Следует заметить, что размер списка не безграничен. Всего он может содержать 256 символов.

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

Директива nameserver определяет адрес сервера доменных имен, который будет выполнять рекурсивные запросы resolver. Возможно указание нескольких серверов. Обычно - это не более трех серверов доменных имен.

На самом деле, если собирать библиотеку resolver самостоятельно, то число сервер, которое можно указывать в resolv.conf может быть установлено произвольно Определяется переменной MAXNS в файле /usr/include/resolv.h.

Вообще говоря, многие ограничения resolver заданы переменными в этом файле. Например, максимальное число элементов списка поиска - MAXDNSRCH, минимальный уровень вложенности локального доменного имени - LOCALDOMAINPARTS и т.п..

Если нет указаний на сервер доменных имен, то предполагается, что существует локальный сервер доменных имен. В старых версиях предполагалось, что он размещен по адресу 127.0.01, в новых версиях предполагается, что локальный адрес 0.0.0.0. Изменение адреса связано с проблемами, которые возникали при работе хоста через коммутируемые соединения. Предполагалось, что адрес умолчания - это адрес полученный через ifconfig в момент начальной загрузки машины. В этом случае интерфейс должен быть поднят и активен. Все такого сорта адреса интерфейсов маршрутизировались через 127.0.0.1. Но если интерфейс не поднимался, то возникало "залипание" и машина висла на этапе начальной загрузки. Изменение адреса позволяет решить эту проблему в рамках самого пакета.

Общая рекомендация такова: всегда нужно создавать файл resolv.conf и указывать в нем адрес локального сервера доменных имен.

Если указано несколько серверов доменных имен, то адрес каждого сервера указывается отдельной строкой в файле resolv.conf:

# resolv.conf
search corp.ru .
nameserver 192.168.0.1
nameserver 192.168.0.2
nameserver 192.168.0.3

Опрос серверов осуществляется по порядку их указания в файле resolv.conf. Сначала будет опрашиваться 192.168.0.1, потом, если первый сервер не ответил, - 192.168.0.2, и последним, если не ответили первые два, - 192.168.0.3. Минимальный интервал времени между попытками по умолчанию (переменная RES_TIMEOUT в файле resolv.conf - 5 секунд). Обычно resolver делает 2 или 3 серии попыток (зависит от версии).

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

Обычно директивами domain, search, nameserer и ограничиваются при описании файла настройки resolv.conf. Более подробную информацию можно найти на страницах руководств системных администраторов операционных систем (ссылка на man Unix приведен в "полезных" ссылках).

И в заключении несколько слов об "умном" resolver пакета BIND 9. Он носит название lwresd и запускается в момент начальной загрузки системы как демон. Прикладные программы для работы с ним должны быть отредактированы с библиотекой вызовов этого resolver (BIND 9 lightweight resolver library).

Lwresd - это практически кеширующий локальный сервер доменных имен, который общается с клиентами не по протоколу DNS, а по своему собственному, посылая в сеть запросы. Если в resolv.conf указан сервер доменных имен, который может обрабатывать рекурсивные запросы, то lwresd будет пересылать ему запросы клиентов, если нет, то он может, используя встроенный список корневых серверов сам выполнять запросы клиентов.

Рекомендованная литература:

1. Альбитц П., Ли К.. DNS и BIND. - Пер. с англ. - СПб: Символ-Плюс, 2002. - 696 с.
2. BIND 9 Administrator Reference Manual. (http://www.nominum.com/resources/documentation/Bv9ARM.pdf)

Полезные ссылки:

1. http://www.isc.org/products/BIND/bind9.html - страничка BIND 9.2.1
2. http://www.linuxsecurity.com/feature_stories/conrad_vixie-1.html - интервью авторов BIND сетевому изданию linuxsecurity.com. Наиболее интересна та часть ответов, которые дает Paul Vixie, автор BIND до версии 8 и руководитель работ над версией 9.
3. http://www.osp.ru/os/1998/06/34.htm - описание принципов контрактного проектирования. Всегда полезно прочитать о том, как правильно делать свою работу :)

Назад Оглавление Вперед