 | Запросы доменной системы имен
Топология DNS
DNS представляет из себя иерархическую систему доменных зон. Каждая зона предоставляет ограниченный набор отображений в доменные имена, входящие в ее поддомен. Запрошенный сервер пошлет запрос более высокому в иерархии серверу в случае, если он не в состоянии найти требуемое отображение и, в случае необходимости, будет следовать указаниям о перенаправлении, пока не найдет правильного соответствия (или не определит, что данный запрос не может быть разрешен, выдав ошибку). Когда локальный сервер named получает ответ на посланный DNS запрос, он кэширует его на период времени, указанный в конфигурации (это скорее часы, чем секунды или дни). Вследствие кэширования DNS запросов совокупная сетевая загрузка значительно снижается, особенно для серверов верхнего уровня домена (top-level-domain -- TLD). Статья о DNS в Wikipedia (см. ссылку в разделе Ресурсы) -- отличная стартовая точка для понимания архитектуры в целом. В этом руководстве мы приводим диаграмму из этого источника, предоставленную в свободный доступ (см. рис. 1 далее).
Диаграмма прохождения гипотетического DNS запроса позволит взглянуть на процесс его обслуживания в целом. Положим, ваша локальная машина хочет получить доступ к машине с доменным именем www.wikipedia.org. Для поиска соответствующего IP адреса ваша машина должна обратиться к локальному серверу имен, указанному в конфигурации клиентской машины. Этот сервер может работать на той же самой машине, может располагаться на DNS сервере вашей локальной сети (LAN) или же предоставляться вашим интернет-провайдером (ISP). Во всех этих случаях это будет какой-то экземпляр BIND named. Этот локальный сервер имен в первую очередь проверит свой кэш и в случае, если там такой информации нет, выполнит следующие шаги, отображенные на диаграмме:
Рисунок 1. Пример рекурсии DNS
Следует понимать, что "DNS Recurser" -- это текущий DNS сервер (named), а не клиентское приложение, которое с ним общается.
DNS использует TCP и UDP на порту 53 для обслуживания запросов. Практически все DNS запросы представляют из себя одиночные UDP запросы от клиента, порождающие одиночные UDP ответы от сервера.
Откуда приложение знает, где найти DNS сервер
Конфигурирование клиентского приложения для доступа к DNS серверу (серверам) достаточно просто. Вся конфигурация содержится в файле /etc/resolve.conf, в котором указаны один или более "локальных" DNS серверов. Вы можете вручную сконфигурировать /etc/resolve.conf на подключение к известным вам DNS серверам; однако, если вы используете DHCP для конфигурирования клиента, в ходе DHCP handshaking'а эта информация добавляется в /etc/resolve.conf автоматически (вы по-прежнему можете читать его и даже модифицировать установки, сделанные DHCP, но они будут вновь восстановлены после перезагрузки). Код библиотеки с установками, сделанными /etc/resolv.conf, называется "DNS resolver."
Если в /etc/resolv.conf указано более одного DNS сервера, вторичный и третичный DNS сервера будут использоваться в случае, если ответ от первичного сервера не поступает в течение указанного периода времени. Максимальное количество серверов, которое можно указать в конфигурации -- три.
Прежде всего, файл /etc/resolv.conf содержит записи следующего вида nameserver <IP-addr>. Некоторые другие записи могут изменять ответы на посланные запросы. Например, директивы domain и search расширяют имена, не содержащие точек (машины в локальной сети). Директива options позволяет вам изменять время ожидания ответа от DNS сервера, включать режим отладки при расширении до полного доменного имени и изменять другие аспекты работы DNS resolver'а. Например, на одной из моих машин конфигурация такова:
Листинг 1. Модификация опций в файле конфигурации доступа к DNS серверам
# cat /etc/resolv.conf
search gnosis.lan
nameserver 0.0.0.0
nameserver 192.168.2.1
nameserver 151.203.0.84
options timeout:3
|
Первая директива указывает, что машины в локальной сети входят во внутренний домен gnosis.lan, таким образом, короткое имя bacchus может быть расширено в bacchus.gnosis.lan. Несколько доменов, разделенных пробелами могут быть перечислены в директиве search.
Затем я перечислил несколько DNS серверов. Первый из них -- локальная машина, на которую можно ссылаться как на 0.0.0.0 или через официальный IP адрес, но не loopback-адрес. Следующая директива, nameserver, указывает на мой домашний роутер, соединяющий мою локальную сеть с Интернет (и поддерживает DHCP и DNS серверы). Третий nameserver предоставляется мне сервис-провайдером. Кроме того, я установил 3-х секундное время ожидания (timeout) для каждого сервера имен, вместо 5 секунд, установленных по умолчанию.
Клиентские утилиты DNS
BIND 9 поставляется с четырьмя основными клиентскими утилитами. Три из них -- dig, nslookup и host -- выполняют сходные функции, более или менее отличающиеся деталями. Все три утилиты представляют из себя приложения, выполняемые в командной строке и посылающие запросы в DNS resolver. В сущности они делают то, что другие клиентские приложения делают на внутреннем уровне, но выводя результаты своей деятельности на STDOUT. Наиболее мощным средством из описанных выше является dig, поскольку предоставляет наиболее широкий набор опций для задания запросов и конфигурирования формата вывода полученной информации.
Эти утилиты чаще всего используются для определения IP адреса из символьного доменного имени, но вы также можете сделать и обратный запрос или запросить другие типы записей, кроме записей типа "A". Например, команда host -t MX gnosis.cx покажет вам почтовые сервера домена gnosis.cx. Несколько полезных примеров:
Листинг 2. Запрос при помощи host о google.com
$ host google.com
google.com has address 72.14.207.99
google.com has address 64.233.187.99
|
Листинг 3. Запрос при помощи host о записи MX для gnosis.cx
$ host -t MX gnosis.cx
gnosis.cx mail is handled by 10 mail.gnosis.cx.
|
Для утилиты nslookup:
Листинг 4. nslookup использует сервер, установленный по умолчанию (на локальной машине)
$ nslookup gnosis.cx
Server: 0.0.0.0
Address: 0.0.0.0#53
Non-authoritative answer:
Name: gnosis.cx
Address: 64.41.64.172
|
Обратный запрос с использованием утилиты dig и с указанием другого сервера имен:
Листинг 5. Обратный запрос через dig на иной сервер, чем установленный по умолчанию
$ dig @192.168.2.2 -x 64.233.187.99
; <<>> DiG 9.2.4 <<>> @192.168.2.2 -x 64.233.187.99
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 3950
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;99.187.233.64.in-addr.arpa. IN PTR
;; AUTHORITY SECTION:
187.233.64.in-addr.arpa. 2613 IN SOA ns1.google.com. dns-admin.google.com.
2004041601 21600 3600 1038800 86400
;; Query time: 1 msec
;; SERVER: 192.168.2.2#53(192.168.2.2)
;; WHEN: Thu Nov 10 02:00:27 2005
;; MSG SIZE rcvd: 104
|
Последняя утилита BIND 9, о которой надо иметь представление, -- это rndc, утилита для управления сервером имен. Она является расширением утилиты ndc, поставлявшейся с предыдущими версиями BIND. Если rndc вызывается из командной строки без опций и аргументов, она выводит короткую справку о поддерживаемых командах. См. страницы системного руководства man для получения полной информации об использовании rndc.
| |
