Учебник по FreeBSD, OpenBSD, NetBSD, DragonFly: 6.5. Запрос к серверу DNS

6.5. Запрос к серверу DNS

Описание. Кандидат BSDA должен понимать основы теории DNS, включая типы DNS записей обратное преобразование имён и перенос зон. Кандидат должен уметь посылать запросы серверу DNS о записях нужного типа, понимать какой сервер авторитетен за зону и понимать готов ли сервер к пересылке зоны.

Практика. dig(1), host(1), nslookup(1), ping(8), telnet(1)

Комментарий

6.5.1. Теория вопроса

Литература по настройке серверов DNS чрезвычайно обильна. Я пройдусь по теме насколько это возможно кратко.

Итак, протоколы IP и IPv6 устроены таким образом, что адресация происходит при помощи числовых адресов. Нельзя сказать, что человека это должно как-то напрягать, ведь никто не протестует против применения семизначных, десятизначных и даже более длинных телефонных номеров. Однако иметь более мнемоничные адреса несомненно удобнее. Почти сразу, как только появился интернет, появились таблицы соответствия IP адресов и символьных имён машин. Эти таблицы и по сей день хранятся в файле /etc/hosts. Однако задача синхронизации данного файла между машинами очень скоро стала непомерно сложной. В настоящий момент можно с уверенностью сказать, что она вообще нереальна. Для решения этой проблемы возникла система DNS — распределённая база данных.

Распределённая, значит ни один сервер не содержит в себе сведений обо всём пространстве имён Интернета. Каждый сервер ответственен за свой участок этого пространства. Говорят, что данный сервер авторитетен для данной зоны.

Таким образом, пространство имён Интернета поделено на зоны. Каждый сервер может отвечать за ноль и более зон. Рассмотрим, что происходит когда некоторой машине надо узнать IP адрес машины www.dragonflybsd.org.

Первым делом будет осуществлён поиск в файле /etc/hosts, затем, в случае неудачи, будет изучен файл /etc/resolv.conf. Дополнительную информацию об этих этапах можно узнать из Раздел 6.1.4, «/etc/resolv.conf(5)» и Раздел 6.7, «Изменение порядка разрешения имён». Сейчас нам важно, что в итоге мы сделали запрос к некоторому серверу DNS.
Сервер DNS должен самостоятельно узнать адрес машины www.dragonflybsd.org. и сообщить его клиенту даже если он не является авторитетным для зоны в которой находится данная машина (т.е. зоны dragonflybsd.org.). Сервер, который в состоянии выполнить всю работу по розыску адреса, задав все вопросы другим серверам DNS самостоятельно называется рекурсивным. В /etc/resolv.conf можно указывать только рекурсивные сервера DNS.
Первым делом наш сервер посылает запрос одному из корневых серверов DNS. Разумеется ни один из корневых серверов не знает ответа на этот вопрос. Больше того, ни один из них и не будет разбираться в вопросе, т.е. ни один из них не является рекурсивным. Зато они знают, какие сервера ответственны за зону org. И этой информацией делятся.
Наш сервер посылает запрос о машине www.dragonflybsd.org. на сервер отвечающий за зону org. Тот тоже не знает где эта машина и он тоже, с гарантией нерекурсивен, но он знает о том, какая машина отвечает за зону dragonflybsd.org.
Наш сервер посылает запрос на сервер ответственный за зону dragonflybsd.org. Тот располагает авторитетной информацией и сразу даёт ответ. Надо заметить, что этот сервер в принципе мог бы быть рекурсивным. Если это так, и если бы нас интересовал узел 4-го уровня вложенности (host.www.dragonflybsd.org.) то сервер ответственный за зону dragonflybsd.org. сам мог бы послать запрос серверу ответственному за зону www.dragonflybsd.org.

Вся информация полученная нашим сервером DNS надолго помещается в его кеш. Время хранения в кеше, зависит от настроек зоны, т.е. определяется не нашим DNS сервером, а теми серверами, которые ответственны за зону (в самом деле, только они могут знать насколько надёжны предоставленные ими данные). Некоторые серверы DNS могут существовать исключительно ради своего кеша и не иметь ни одной зоны, за которую они бы отвечали (так называемы кеширующие серверы).

Заметьте, что есть чёткая иерархия зон, но нет иерархии серверов DNS. Сервер DNS первым делом осуществляет запрос к корневому серверу, а вовсе не к «своему начальнику». Понятие старшинства среди серверов отсутствует, оно есть только для зон. Конечно сервер должен задать кому-то самый первый вопрос. Этот вопрос он задаёт корневому серверу. Адреса корневых серверов он берёт из специальной зоны подсказок, которая распространяется с исходным кодом сервера. Ниже я покажу как получить эту информацию.

Замечание

Иерархию серверов DNS можно создать искуственно при помощи опции forwarders и зон типа forward. Это может быть полезно, если на предприятии поднимаеться свой локальный «национальный» домен типа local. и в нём поддомены типа finans.local., kb.local., где будут хосты типа glavbuh.finans.local., ingeneer.finans.local., причём на зоны втророго уровня ответственны свои DNS сервера, отличные от центрального сервера, ответственного за зону local..

В каждой зоне могут быть записи следующих типов:

Таблица 6.1. Типы записей в файле зоны DNS

Запись	Описание
SOA	Определение параметров зоны DNS (таймауты, адрес ответственного лица)
NS	Определение DNS-серверов ответственных (авторитетных) за зоны, делегирование полномочий поддоменам.
Записи типа SOA и NS обязательны, остальных записей может не быть вовсе.
A	Преобразование имени в IP адрес
AAAA или A6	Преобразование имени в IPv6 адрес
PTR	Преобразование IP адреса в имя
MX	Указание почтового сервера ответственного за зону
KEY	Открытый ключ шифрования для имени DNS
CNAME	Псевдоним, алиас, синоним.
SRV	Распределение нагрузки на сервис
TXT	Текстовая запись используется с самой разной целью
HINFO	Информация о машине, например архитектура и операционная система.

В каждой зоне обязательно должны присутствовать записи типа SOA и NS. Если для домена example.org. почту принимает машина mx.example.org., то для неё должна существовать специальная MX запись. Почтовых машин отвечающих за домен может быть несколько. В записи типа MX упоминается их приоритет. Почту принимает машина с наименьшим значением приоритета, а если она недоступна, то следующая. Если запись MX для домена example.org. отсутствует, то эту почту принимает машина example.org.

6.5.1.1. Настройка прямой и обратной зон

Полное описание работы с сервером BIND выходит за рамки данного раздела. Мы лишь опишем настройку файла зоны, с тем, чтобы администратор мог сознательно применять утилиты host(1), dig(1) и nslookup(1).

6.5.1.1.1. `named.conf(5)`

Сначала зона должна быть объявлена в конфигурационном файле сервиса named(8) — named.conf(5). Этот конфигурационный файл может находиться в файле /etc/namedb/named.conf, а может в /var/named/etc/namedb/named.conf. Сервис named(8) часто запускается в окружении chroot(8) в каталоге /var/named/, однако для удобства администрирования всё равно оставляют мягкую ссылку /etc/namedb/named.conf.

Зона, оъявленная в BIND, может иметь один из следующих типов: master, slave, hint или forward. Зона hint содержит в себе адреса корневых серверов DNS, с которых начинает опрос рекурсивный сервер DNS. Эта зона практически не подвержена никаким изменениям и обычно не должна редактироваться администратором.

Зона типа master должна быть описана в файле. Файл описания зоны мы рассмотрим ниже, а сейчас взглянем на объявление зоны типа master:

...skip...

options {
    directory "/etc/namedb";

...skip...

}

...skip...

zone "example.org." {
    type master;
    file "master/example.zone";
};

...skip...

Здесь сказано, что зона example.org. описана в файле master/example.zone. Этот адрес дан относительно каталога /etc/namedb (см. опцию directory).

Зону типа master редактирует администратор, но за эту зону может отвечать несколько серверов DNS. Для того, чтобы все они обладали одинаковой согласованной информацией, на всех прочих серверах DNS поднимается зона типа slave, которая синхронизируется с зоной типа master. Зона типа slave объявляется следующим образом:

zone "example.org." {
    type slave;
    file "slave/example.zone";
    masters {
        192.168.1.1;
    };
};

Здесь сказано, что зона имеет тип slave, а сервер, с которого надо брать информацию о ней (master) имеет адрес 192.168.1.1. Информация о зоне (файл зоны) будет сохраняться в файле slave/example.zone. Последняя опция необязательна, если файл не указан, информация будет храниться в памяти и при перезагрузке сервера DNS пропадёт.

Зона типа forward применяется в редких случаях, когда надо заставить наш сервер DNS делать запрос о зоне для которой он не авторитетен не к одному из корневых серверов, перечисленных в зоне hint, а к некоторому конкретному серверу. Например, пусть DNS A, расположенный на некотором предприятии, описывает локальную зону local. и делегирует зону finans.local. серверу DNS B. Поскольку сервер A не авторитетен для зоны finans.local., при попытке разрешить имя major-buhg.finans.local., он обратится к корневому серверу DNS (несмотря на то, что он сам делегировал зону finans.local. серверу B) и потерпит неудачу, так как зоны local. с точки зрения корневых серверов не существует. Поэтому на сервере A мы должны описать зону finans.local. типа forward для того, чтобы он переадресовывал запросы к этой зоне на авторитетный для неё сервер B:

zone "local." {
    type master;
    file "master/local.zone";
};

zone "finans.local." {
    type forward;
    masters {
        192.168.1.2; // server B
    };
};

В свою очередь, на сервере B нам, вероятно, надо указать опцию forwarders, в которой указать сервер A, тогда опрос сервер B будет производить не с корневых серверов, а с сервера A и разрешение имён находящихся в зоне local. будет работать корректно. Кроме того, такое действие полезно, если на предприятии поднято несколько серверов DNS, а выход в Интернет на брандмауэре разрешён только серверу A.

...skip...

options {
    directory "/etc/namedb";
    forwarders {
      192.168.1.1; // server A
    };

...skip...

}

6.5.1.1.2. Синтаксис файла зоны

Файл зоны состоит из перечня записей различного типа. Типы записей в файле зоны были перечислены в Таблица 6.1, «Типы записей в файле зоны DNS». Как уже говорилось, обязательных записей в этом файле всего две: запись типа SOA и запись типа NS в которой указан сервер DNS ответственный за данную зону.

В каждой записи имеется необязательное поле, в котором указывается время жизни данной записи в кешах серверов DNS. Чтобы не указывать эту величину в каждой строке (как правило нет никакого смысла делать различные времена жизни для разных записей) её можно указать в самом начале файла, задав переменную $TTL.

Все адреса в файле зоны должны заканчиваться на точку (т.н. формат FQDN: fully qualified domain name — полностью описанное имя домена). Если имя не кончается на точку, к нему дописывается содержимое переменной $ORIGIN. Если данная переменная не задана явно, то в ней содержится имя зоны, т.е. то, что объявлено в файле named.conf(5).

Другая интересная переменная — $INCLUDE позволяет включить внутрь одного файла зоны другой файл.

Комментарии в файле зоны начинаются с символа ;.

Первая запись в файле зоны — запись типа SOA. помимо необязательного поля TTL в записи SOA имеется десять обязательных полей, поэтому записать её в одну строку весьма затруднительно. Для того, чтобы запись типа SOA можно было написать в несколько строк, применяются круглые скобки. запись не кончится, пока не закроется круглая скобка.

Вот пример файла зоны с описанием:

$TTL      36000

@         IN        SOA       ns.example.ru. root.example.ru.  (
                                        2006011700  ; Serial
                                        3600        ; Refresh
                                        900         ; Retry
                                        3600000     ; Expire
                                        3600 )      ; Minimum
          IN        NS        ns.example.ru.
          IN        NS        ns1.example.ru.
          IN        NS        ns2.otherplace.ru.
          IN        MX   5    smtp.example.ru.
          IN        MX   15   smtp.otherplace.ru.
ns        IN        A         192.168.0.1
ns1       IN        A         192.168.0.2
smtp      IN        A         192.168.0.1
www       IN        A         192.168.0.3
site1     IN        CNAME     www
site2     IN        CNAME     www

В приведённом примере сперва задана переменная $TTL, затем сделано двенадцать записей: первая запись типа SOA, три типа NS, две типа MX, четыре типа A и две типа CNAME.

SOA

Имя домена. Знак @ будет заменён на содержимое переменной $ORIGIN, но мы могли бы написать явно example.ru..
TTL — необязательное поле, в данном примере отсутствует.
Класс записи. Практически всегда IN. Теоретически возможны и другие варианты: IN — Internet, CH — ChaosNet, HS — Hesoid — информационная служба, являющаяся надстройкой BIND и используюемая крайне редко.
Тип записи (в данном случае SOA).
Имя мастер сервера DNS, отвечающего за данную зону. Ниже, в записи типа NS снова будет назван этот сервер, но записей типа NS может быть много, так как у зоны может быть много авторитетных серверов. При этом один из них master, а остальные slave. В данном поле записи SOA указано какой из этих серверов будет сервером master.
Электронный адрес человека ответственного за данную зону. Поскольку знак @ применяться в файле зоны не может (как уже было сказано, он заменяется на переменную $ORIGIN), вместо него используется точка. данная запись выглядит как доменное имя. Можно написать просто root, в этом случае имя будет достроено до FQDN из переменной $ORIGIN, и первая точка будет заменена на знак @. Таким образом, запись root в данном поле превратится в адрес root@example.ru.
Серийный номер зоны. Его формат не важен, важно, чтобы при каждом изменении зоны админимстратор увеличивал этот номер. Периодически сервер типа slave будет связываться с сервером master и сравнивать серийные номера зон. Если окажется, что серийный номер на сервере slave меньше, чем, на master, будет начата пересылка зоны с master на slave. Удобно в этом месте писать дату изменения. Длина поля не должна превышать десять знаков, однако этого достаточно, чтобы, как в приведённом случае хранить год, месяц, день и ещё две цифры. Такой формат даёт возможность указывать дату изменения и номер изменения в указанный день и номер будет всегда увеличиваться.
Интервал времени, через которое сервер slave сверяет серийный номер с сервером master.
Интервал повторных попыток сверки серийного номера. Если сервер slave по какой-то причине не смог сверить серийный номер, он будет повторять попытки через указанное здесь время.
В случае, если все попытки сверить зону окажутся неудачными, через данное время slave сервер будет считать, что данной зоны больше не существует и перестанет отвечать на запросы по данной зоне.
Время жизни в кешах серверов DNS отрицательных ответов. Для BIND 8.2 и более старых это поле так же определяло TTL по умолчанию. В новых версиях TTL по умолчанию находится в переменной $TTL.

NS

В записи типа NS, в данном примере, отсутствует первое поле. Это значит, что оно будет взято из предыдущей записи. Таким образом, все три записи NS относятся к зоне example.ru. и описывают три сервера авторитетных для данной зоны. Два из них будут slave, а один, упомянутый в записи SOA — master.

Поле с классом записи (IN) так же как и TTL необязательное, и тоже, как и TTL могло бы отсутствовать.

В остальном синтаксис достаточно прост, назначение данной записи — перечислить ответственные за зону сервера DNS, поэтому обязательных полей здесь два: тип записи и имя сервера.

Разумеется сервер DNS не обязан находиться в описываемой зоне. В данном случае упомянут один сервер DNS из другой зоны otherplace.ru. Если сервер находится в нашей зоне, мы должны ниже, в записи типа A указать его адрес, если он в другой зоне, то его адрес должны указать там. Тем не менее нет никаких причин не включить этот сервер ещё и в нашу зону. Это удобнее, так как мы, в этом случае можем сами указать соответствующий IP.

	Замечание
	Не следует в данной записи указывать IP или имена заданные в записях типа CNAME. Указанные здесь имена должны быть описаны ниже в записи типа A или AAAA.

Важно

Хотя согласно правилам построения системы DNS для зоны достаточно иметь один сервер DNS (поэтому запись типа NS обязательна, но может быть единственной), если вы описываете домен второго уровня внутри зоны ru., то по правилам RIPE вы обязаны иметь не менее двух серверов DNS в различных сетях класса C. Т.е. у этих двух серверов обязан отличаться как минимум третий байт в адресе IPv4.

Запись типа MX

Здесь описано какие хосты ответственны за приём почты направляющейся в домен example.ru. Если такой записи нет вообще, то почту будет принимать машина с именем example.ru. Если таких записей много, то сперва будет предпринята попытка доставить почту на машину с самым низким значением поля с приоритетом, затем, в случае неуспеха, на машину со следующим приоритетом и так далее.

Итак, данная запись отличается только тем, что в ней добавлено поле с приоритетом записи, сразу после типа записи MX.

	Важно
	Не следует в данной записи указывать IP или имена заданные в записях типа CNAME. Указанные здесь имена должны быть описаны ниже в записи типа A или AAAA.

Запись типа A

Данная запись указывает соответствие между именем и адресом IP. В случае, если в файле зоны имеется несколько записей с одинаковым именем, но разными адресами, например:

www       IN        A         192.168.0.1
www       IN        A         192.168.0.2
www       IN        A         192.168.0.3

...адреса будут выдаваться сервером DNS циклически: в ответ на первый запрос о имени www.example.ru сервер DNS даст адрес 192.168.0.1, следующему клиенту дадут адрес 192.168.0.2 и дальше по кругу. Это один из способов распределения нагрузки между различными серверами. К сожалению, это не самый удачный способ распределения нагрузки: при аварии на одном из серверов, даже если принять оперативные меры по редактированию файла зоны, в многочисленных кешах ещё долго будет сидеть информация о неработающем сервере и треть клиентов продолжит получать неправильную информацию. Снижение TTL на данные записи приведёт к увеличению нагрузки на систему DNS и в конечном итоге приведёт к замедлению обслуживания клиентов.

CNAME

Запись типа CNAME указывает на то, что данные имена это имена одной и той же машины. Такие записи удобны, например, при создании виртуальных веб-серверов.

SRV

Запись этого типа нужна для того, чтобы клиентское програмное обеспечение могло самостоятельно разыскивать машину, на которой поднят нужный сервис и осуществлять распределение нагрузки. К сожалению, немногие браузеры могут похвастать поддержкой этого типа записи в файле зоны. И всё же:

;; _служба._протокол.имя   [ttl]   IN SRV приоритет  вес   порт   сервер 
_http._tcp.www                     IN SRV     0       1    80     www.server.ru.
                                   IN SRV     0       3    8080   old.server.ru.

В приведённом примере браузер должен осуществить запрос с целью определить на каком сервере и на каком порту обслуживают злужбу http по протоколу tcp. Как результат он получает информацию о том, что эти запросы обслуживают две машины: www.server.ru и old.server.ru. Причём первая обслуживает 25% запросов и работает на порту 80, а вторая обслуживает 75% запросов и работает на порту 8080. Распределение нагрузки осуществляется на основе поля «вес» на добровольной основе, т.е. дано на откуп клиенту.

Поле «приоритет» имеет то же значение, что и для записи MX. Клиент должен обращаться к записи с наименьшим числом в поле «приоритет», и переходить к записи с большим приоритетом, только если сервера из записей с меньшим недоступны.

Имя службы и протокола должно начинаться с подчерка, чтобы не перепутать их с обычными именами. Имена служб и протоколов описаны в [RFC-1700].

TXT

Текстовая запись. В ней может находиться самая разнообразная информация. Например стихи:

poem    IN      TXT     ( "The Road goes ever on and on"
                        "Down from the door where it began."
                        "Now far ahead the Road has gone,"
                        "And I must follow, if I can,"
                        "Purshuing it with eager feet,"
                        "Until it joins some larger way"
                        "Where many paths and errands meet."
                        "And whither then? I cannot say." )

Ёмкость этой записи — пара килобайт. Мы вполне можем использовать её для хранения коротких стихотворений, создав доменные имена для разных поэтов... Однако у этой записи есть множество других, более полезных применений. В некоторых случаях в ней хранят публичные ключи. Старые версии BIND хранили в записях TXT информацию о том, кому можно отвечать на запросы к зоне (в новых версиях это делается при помощи директивы allow-query).

Итак, администратор должен уметь не только определять IP адрес машины, но и запрашивать записи о зоне определённого типа. Для осуществления этих запросов существует три команды: host(1), dig(1), nslookup(1).

Замечание

Имейте ввиду, все три утилиты работают с системой DNS и ни одна из них не проверяет файл /etc/hosts. Таким образом, информация полученная при помощи данных утилит не обязательно даёт ответ на вопрос «почему мой веб-браузер идёт на адрес XYZ, когда я ввожу URL http://xyz.org/?».

6.5.2. host(1)

Программа host(1) существует во многих вариантах. В FreeBSD она умеет сообщать практически ту же информацию, что и dig(1), но в других системах это может быть не так. Здесь мы приведём примеры на базе FreeBSD, как наиболее полные.

Запрос IP по адресу:

$ host mail.ru
mail.ru has address 194.67.57.26
mail.ru mail is handled (pri=10) by mxs.mail.ru

Как видно, нам сообщили не только IP машины mail.ru, но и некоторую дополнительную информацию (имя почтовой машины и её приоритет). Эта информация приходит от сервера DNS в том же UDP пакете и её получение не требует со стороны программы host(1) никаких специальных действий. И всё же, некоторые варианты этой программы могут не сообщать всей информации.

Программе можно явно указать сервер DNS, в этом случае запрос будет сделан к нему:

$ host mail.ru 194.67.23.130
Using domain server 194.67.23.130:

mail.ru has address 194.67.57.26
mail.ru mail is handled (pri=10) by mxs.mail.ru

И наконец, можно запросить конкретный тип записи:

$ host -t NS mail.ru
mail.ru name server ns2.mail.ru
mail.ru name server ns3.mail.ru
mail.ru name server ns4.mail.ru
mail.ru name server ns5.mail.ru
mail.ru name server ns.mail.ru
mail.ru name server ns1.mail.ru
$ host -t SOA mail.ru
mail.ru start of authority      ns.mail.ru hostmaster.mail.ru (
                        3209013119      ;serial (version)
                        300     ;refresh period
                        900     ;retry refresh this often
                        172800  ;expiration period
                        300     ;minimum TTL
                        )

Опция -v включает режим verbose.

$ host -t NS -v mail.ru
Trying null domain
rcode = 0 (Success), ancount=6
The following answer is not authoritative:
The following answer is not verified as authentic by the server:
mail.ru 16141 IN        NS      ns4.mail.ru
mail.ru 16141 IN        NS      ns5.mail.ru
mail.ru 16141 IN        NS      ns.mail.ru
mail.ru 16141 IN        NS      ns1.mail.ru
mail.ru 16141 IN        NS      ns2.mail.ru
mail.ru 16141 IN        NS      ns3.mail.ru
Additional information:
ns.mail.ru      153899 IN       A       194.67.23.130
ns1.mail.ru     299802 IN       A       194.67.57.103
ns2.mail.ru     167593 IN       A       194.67.57.104
ns3.mail.ru     278118 IN       A       194.67.23.17
ns4.mail.ru     278118 IN       A       194.67.57.4
ns5.mail.ru     278118 IN       A       194.67.23.232
$ host -t SOA -v mail.ru
Trying null domain
rcode = 0 (Success), ancount=1
The following answer is not authoritative:
The following answer is not verified as authentic by the server:
mail.ru 21455 IN        SOA     ns.mail.ru hostmaster.mail.ru (
                        3209013119      ;serial (version)
                        300     ;refresh period
                        900     ;retry refresh this often
                        172800  ;expiration period
                        300     ;minimum TTL
                        )
For authoritative answers, see:
mail.ru 15127 IN        NS      ns.mail.ru
mail.ru 15127 IN        NS      ns1.mail.ru
mail.ru 15127 IN        NS      ns2.mail.ru
mail.ru 15127 IN        NS      ns3.mail.ru
mail.ru 15127 IN        NS      ns4.mail.ru
mail.ru 15127 IN        NS      ns5.mail.ru
Additional information:
ns.mail.ru      152885 IN       A       194.67.23.130
ns1.mail.ru     298788 IN       A       194.67.57.103
ns2.mail.ru     166579 IN       A       194.67.57.104
ns3.mail.ru     277104 IN       A       194.67.23.17
ns4.mail.ru     277104 IN       A       194.67.57.4
ns5.mail.ru     277104 IN       A       194.67.23.232

В последнем случае нам даже явно рекомендуют обращаться за информацией на авторитетные серверы и указывают их адреса. С опцией -v отчёт программы host(1) становится похож на отчёт dig(1) (см. ниже) и начинает повтрять синтаксис файла зоны.

6.5.3. dig(1)

Утилита dig(1) более «разговорчива». Одна из особенностей её отчётов состоит в том, что они даются сразу в формате файла зоны:

$ dig mail.ru

; <<>> DiG 8.3 <<>> mail.ru 
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9099
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 6
;; QUERY SECTION:
;;      mail.ru, type = A, class = IN

;; ANSWER SECTION:
mail.ru.                1h56m42s IN A   194.67.57.26

;; AUTHORITY SECTION:
mail.ru.                4h21m12s IN NS  ns2.mail.ru.
mail.ru.                4h21m12s IN NS  ns3.mail.ru.
mail.ru.                4h21m12s IN NS  ns4.mail.ru.
mail.ru.                4h21m12s IN NS  ns5.mail.ru.
mail.ru.                4h21m12s IN NS  ns.mail.ru.
mail.ru.                4h21m12s IN NS  ns1.mail.ru.

;; ADDITIONAL SECTION:
ns.mail.ru.             1d18h37m10s IN A  194.67.23.130
ns1.mail.ru.            3d11h8m53s IN A  194.67.57.103
ns2.mail.ru.            1d22h25m24s IN A  194.67.57.104
ns3.mail.ru.            3d5h7m29s IN A  194.67.23.17
ns4.mail.ru.            3d5h7m29s IN A  194.67.57.4
ns5.mail.ru.            3d5h7m29s IN A  194.67.23.232

;; Total query time: 9 msec
;; FROM: aluminum.mccme.ru to SERVER: 62.117.108.2
;; WHEN: Wed Apr  5 14:37:57 2006
;; MSG SIZE  sent: 25  rcvd: 244

Символ ; в файле зоны является комментарием. Заметим, что мы не требовали от программы dig(1) информацию о серверах NS, и всё же он запросил её у сервера DNS. Разумеется, это не вся информация о зоне.

Попробуем запросить информацию о записях SOA и MX.

$ dig MX mail.ru

; <<>> DiG 8.3 <<>> MX mail.ru 
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28695
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 7
;; QUERY SECTION:
;;      mail.ru, type = MX, class = IN

;; ANSWER SECTION:
mail.ru.                4h6m37s IN MX   10 mxs.mail.ru.

;; AUTHORITY SECTION:
mail.ru.                4h6m37s IN NS   ns2.mail.ru.
mail.ru.                4h6m37s IN NS   ns3.mail.ru.
mail.ru.                4h6m37s IN NS   ns4.mail.ru.
mail.ru.                4h6m37s IN NS   ns5.mail.ru.
mail.ru.                4h6m37s IN NS   ns.mail.ru.
mail.ru.                4h6m37s IN NS   ns1.mail.ru.

;; ADDITIONAL SECTION:
mxs.mail.ru.            2h4m39s IN A    194.67.23.20
ns.mail.ru.             1d18h22m35s IN A  194.67.23.130
ns1.mail.ru.            3d10h54m18s IN A  194.67.57.103
ns2.mail.ru.            1d22h10m49s IN A  194.67.57.104
ns3.mail.ru.            3d4h52m54s IN A  194.67.23.17
ns4.mail.ru.            3d4h52m54s IN A  194.67.57.4
ns5.mail.ru.            3d4h52m54s IN A  194.67.23.232

;; Total query time: 2 msec
;; FROM: aluminum.mccme.ru to SERVER: 62.117.108.2
;; WHEN: Wed Apr  5 14:52:31 2006
;; MSG SIZE  sent: 25  rcvd: 264

$ dig SOA mail.ru

; <<>> DiG 8.3 <<>> SOA mail.ru 
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59976
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 6
;; QUERY SECTION:
;;      mail.ru, type = SOA, class = IN

;; ANSWER SECTION:
mail.ru.                5h51m47s IN SOA  ns.mail.ru. hostmaster.mail.ru. (
                                        3209013119      ; serial
                                        5M              ; refresh
                                        15M             ; retry
                                        2D              ; expiry
                                        5M )            ; minimum


;; AUTHORITY SECTION:
mail.ru.                4h6m19s IN NS   ns5.mail.ru.
mail.ru.                4h6m19s IN NS   ns.mail.ru.
mail.ru.                4h6m19s IN NS   ns1.mail.ru.
mail.ru.                4h6m19s IN NS   ns2.mail.ru.
mail.ru.                4h6m19s IN NS   ns3.mail.ru.
mail.ru.                4h6m19s IN NS   ns4.mail.ru.

;; ADDITIONAL SECTION:
ns.mail.ru.             1d18h22m17s IN A  194.67.23.130
ns1.mail.ru.            3d10h54m IN A   194.67.57.103
ns2.mail.ru.            1d22h10m31s IN A  194.67.57.104
ns3.mail.ru.            3d4h52m36s IN A  194.67.23.17
ns4.mail.ru.            3d4h52m36s IN A  194.67.57.4
ns5.mail.ru.            3d4h52m36s IN A  194.67.23.232

;; Total query time: 6 msec
;; FROM: aluminum.mccme.ru to SERVER: 62.117.108.2
;; WHEN: Wed Apr  5 14:52:50 2006
;; MSG SIZE  sent: 25  rcvd: 275

Для запроса к конкретному серверу DNS его адрес необходимо предварять символом at:

$ dig mail.ru @194.67.23.130

; <<>> DiG 8.3 <<>> mail.ru @194.67.23.130 
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62910
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 6
;; QUERY SECTION:
;;      mail.ru, type = A, class = IN

;; ANSWER SECTION:
mail.ru.                6H IN A         194.67.57.26

;; AUTHORITY SECTION:
mail.ru.                6H IN NS        ns.mail.ru.
mail.ru.                6H IN NS        ns1.mail.ru.
mail.ru.                6H IN NS        ns2.mail.ru.
mail.ru.                6H IN NS        ns4.mail.ru.
mail.ru.                6H IN NS        ns5.mail.ru.
mail.ru.                6H IN NS        ns3.mail.ru.

;; ADDITIONAL SECTION:
ns.mail.ru.             6H IN A         194.67.23.130
ns1.mail.ru.            6H IN A         194.67.57.103
ns2.mail.ru.            6H IN A         194.67.57.104
ns4.mail.ru.            6H IN A         194.67.57.4
ns5.mail.ru.            6H IN A         194.67.23.232
ns3.mail.ru.            6H IN A         194.67.23.17

;; Total query time: 91 msec
;; FROM: aluminum.mccme.ru to SERVER: 194.67.23.130
;; WHEN: Wed Apr  5 15:05:16 2006
;; MSG SIZE  sent: 25  rcvd: 244

Заметьте, что в этом запросе размеры таймаутов стали более «круглыми» — ровно по 6 часов. Причина в том, что мы задали вопрос авторитетному за эту зону серверу. Ответы, которые мы получали до сих пор мы брали из кешей неавторитетных серверов, поэтому в качестве TTL мы получали время указывающее на то, сколько осталось жить в кеше той или иной записи.

Давайте попробуем узнать с помощью команды dig(1) адреса серверов отвечающих за корневую зону (.) и время жизни записей о корневых серверах.

$ dig NS .

; <<>> DiG 8.3 <<>> NS . 
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5359
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1
;; QUERY SECTION:
;;      ., type = NS, class = IN

;; ANSWER SECTION:
.                       5d1h8m12s IN NS  F.ROOT-SERVERS.NET.
.                       5d1h8m12s IN NS  G.ROOT-SERVERS.NET.
.                       5d1h8m12s IN NS  H.ROOT-SERVERS.NET.
.                       5d1h8m12s IN NS  I.ROOT-SERVERS.NET.
.                       5d1h8m12s IN NS  J.ROOT-SERVERS.NET.
.                       5d1h8m12s IN NS  K.ROOT-SERVERS.NET.
.                       5d1h8m12s IN NS  L.ROOT-SERVERS.NET.
.                       5d1h8m12s IN NS  M.ROOT-SERVERS.NET.
.                       5d1h8m12s IN NS  A.ROOT-SERVERS.NET.
.                       5d1h8m12s IN NS  B.ROOT-SERVERS.NET.
.                       5d1h8m12s IN NS  C.ROOT-SERVERS.NET.
.                       5d1h8m12s IN NS  D.ROOT-SERVERS.NET.
.                       5d1h8m12s IN NS  E.ROOT-SERVERS.NET.

;; ADDITIONAL SECTION:
J.ROOT-SERVERS.NET.     6d1h8m12s IN A  192.58.128.30

;; Total query time: 2 msec
;; FROM: aluminum.mccme.ru to SERVER: 62.117.108.2
;; WHEN: Thu Apr  6 11:37:56 2006
;; MSG SIZE  sent: 17  rcvd: 244

Очень хорошо, теперь мы знаем что думает о корневых серверах, в настоящий момент обслуживающий нас сервер DNS. Мы видим, что время жизни информации о корневых серверах истечёт через пять дней, один час, восемь минут, двенадцать секунд. Кстати нам, кроме имён корневых серверов, в разделе ADDITIONAL SECTION сказали ещё и адрес одного из серверов. Давайте зададим этот вопрос снова, но теперь не нашему серверу DNS, а сервру j.root-servers.net. с адресом IP 192.58.128.30. Он авторитетен за корневую зону и полученная от него информация будет истиной в последней инстанции.

$ dig NS . @192.58.128.30

; <<>> DiG 8.3 <<>> NS . @192.58.128.30 
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50893
;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 13
;; QUERY SECTION:
;;      ., type = NS, class = IN

;; ANSWER SECTION:
.                       6D IN NS        E.ROOT-SERVERS.NET.
.                       6D IN NS        D.ROOT-SERVERS.NET.
.                       6D IN NS        A.ROOT-SERVERS.NET.
.                       6D IN NS        H.ROOT-SERVERS.NET.
.                       6D IN NS        C.ROOT-SERVERS.NET.
.                       6D IN NS        G.ROOT-SERVERS.NET.
.                       6D IN NS        F.ROOT-SERVERS.NET.
.                       6D IN NS        B.ROOT-SERVERS.NET.
.                       6D IN NS        J.ROOT-SERVERS.NET.
.                       6D IN NS        K.ROOT-SERVERS.NET.
.                       6D IN NS        L.ROOT-SERVERS.NET.
.                       6D IN NS        M.ROOT-SERVERS.NET.
.                       6D IN NS        I.ROOT-SERVERS.NET.

;; ADDITIONAL SECTION:
E.ROOT-SERVERS.NET.     5w6d16h IN A    192.203.230.10
D.ROOT-SERVERS.NET.     5w6d16h IN A    128.8.10.90
A.ROOT-SERVERS.NET.     5w6d16h IN A    198.41.0.4
H.ROOT-SERVERS.NET.     5w6d16h IN A    128.63.2.53
C.ROOT-SERVERS.NET.     5w6d16h IN A    192.33.4.12
G.ROOT-SERVERS.NET.     5w6d16h IN A    192.112.36.4
F.ROOT-SERVERS.NET.     5w6d16h IN A    192.5.5.241
B.ROOT-SERVERS.NET.     5w6d16h IN A    192.228.79.201
J.ROOT-SERVERS.NET.     5w6d16h IN A    192.58.128.30
K.ROOT-SERVERS.NET.     5w6d16h IN A    193.0.14.129
L.ROOT-SERVERS.NET.     5w6d16h IN A    198.32.64.12
M.ROOT-SERVERS.NET.     5w6d16h IN A    202.12.27.33
I.ROOT-SERVERS.NET.     5w6d16h IN A    192.36.148.17

;; Total query time: 299 msec
;; FROM: aluminum.mccme.ru to SERVER: 192.58.128.30
;; WHEN: Thu Apr  6 11:44:56 2006
;; MSG SIZE  sent: 17  rcvd: 436

Как видим, истинное время жизни составляет без малого шесть недель (1000 часов). При помощи такого большого TTL сервера пытаются снизить нагрузку на себя.

Поскольку команда dig(1) выдаёт информацию в формате файла зоны, если мы вдруг почему-то потеряли файл с настройками зоны hint, мы можем сохранить вывод данной команды в файл и использовать его.

Наконец, мы можем сделать запрос записи типа TXT, содержащей короткое стихотворение. Это стихотворение мы записали в файл зоны раньше.

$ dig TXT poem.house.hcn-strela.ru

; <<>> DiG 9.3.2 <<>> TXT poem.house.hcn-strela.ru
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8468
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 1

;; QUESTION SECTION:
;poem.house.hcn-strela.ru.      IN      TXT

;; ANSWER SECTION:
poem.house.hcn-strela.ru. 36000 IN      TXT     "The Road goes ever on
        and on" "Down from the door where it began." "Now far ahead the
        Road has gone," "And I must follow, if I can," "Purshuing it
        with eager feet," "Until it joins some larger way" "Where many
        paths and errands meet." "And whither then? I cannot say."

;; AUTHORITY SECTION:
house.hcn-strela.ru.    36000   IN      NS      ns.hcn-strela.ru.
house.hcn-strela.ru.    36000   IN      NS      ns1.hcn-strela.ru.
house.hcn-strela.ru.    36000   IN      NS      ns.house.hcn-strela.ru.

;; ADDITIONAL SECTION:
ns.house.hcn-strela.ru. 36000   IN      A       83.102.236.196

;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Feb 17 12:05:09 2007
;; MSG SIZE  rcvd: 376

6.5.4. nslookup(1)

nslookup(1) самая древняя программа из этих трёх. Кроме всего прочего она интересна ещё и тем, что входит в стандартную поставку большинства операционных систем компании MicroSoft.

Её синтаксис несколько напоминает синтаксис команды host(1):

$ nslookup mail.ru
Server:  ns.mccme.ru
Address:  62.117.108.2

Non-authoritative answer:
Name:    mail.ru
Address:  194.67.57.26

$ nslookup mail.ru 194.67.23.130
Server:  ns.mail.ru
Address:  194.67.23.130

Name:    mail.ru
Address:  194.67.57.26

Но главная изюминка nslookup(1) состоит в том, что она умеет работать интерактивно:

$ nslookup
Default Server:  ns.mccme.ru
Address:  62.117.108.2

> server 194.67.23.130
Default Server:  ns.mail.ru
Address:  194.67.23.130

> set type=MX
> mail.ru
Server:  ns.mail.ru
Address:  194.67.23.130

mail.ru preference = 10, mail exchanger = mxs.mail.ru
mail.ru nameserver = ns.mail.ru
mail.ru nameserver = ns1.mail.ru
mail.ru nameserver = ns2.mail.ru
mail.ru nameserver = ns4.mail.ru
mail.ru nameserver = ns5.mail.ru
mail.ru nameserver = ns3.mail.ru
mxs.mail.ru     internet address = 194.67.23.20
ns.mail.ru      internet address = 194.67.23.130
ns1.mail.ru     internet address = 194.67.57.103
ns2.mail.ru     internet address = 194.67.57.104
ns4.mail.ru     internet address = 194.67.57.4
ns5.mail.ru     internet address = 194.67.23.232
ns3.mail.ru     internet address = 194.67.23.17
> set type=SOA
> mail.ru
Server:  ns.mail.ru
Address:  194.67.23.130

mail.ru
        origin = ns.mail.ru
        mail addr = hostmaster.mail.ru
        serial = 3209013119
        refresh = 300 (5M)
        retry   = 900 (15M)
        expire  = 172800 (2D)
        minimum ttl = 300 (5M)
mail.ru nameserver = ns.mail.ru
mail.ru nameserver = ns1.mail.ru
mail.ru nameserver = ns2.mail.ru
mail.ru nameserver = ns4.mail.ru
mail.ru nameserver = ns5.mail.ru
mail.ru nameserver = ns3.mail.ru
ns.mail.ru      internet address = 194.67.23.130
ns1.mail.ru     internet address = 194.67.57.103
ns2.mail.ru     internet address = 194.67.57.104
ns4.mail.ru     internet address = 194.67.57.4
ns5.mail.ru     internet address = 194.67.23.232
ns3.mail.ru     internet address = 194.67.23.17
> exit